I have been working with a coach recently to think about what I do. Odd as it might sound I have real trouble articulating what I do. This is particularly true when I’m employed to work on team performance and processes. In my mind I turn up, I talk to people and they then makes things better. Can I take the credit for that?
One of the reoccurring comments I get from clients is that I bring order from chaos. While I’m immensely proud of that it is a hard sell when trying to articulate the value companies can get from hiring me. That is because it implies you already have chaos, and who wants to admit that?
Whether chaos or not I’ve been running over my past engagements and a few things stand out. These are things that I have repeatedly done with teams, things which have made work better (and therefore more productive, efficient and fulfilling.)
Most of these suggestions are quick fixes: you can introduce them pretty quickly and see results. But they do not detract from long term improvement. Even if you have time these are a good place to start.
Triage processes
These come in various shapes and sizes. Typically this means appointing one or two people to quickly review work requests and decide if they need immediate action, can wait a little while or be pushed back.
In one case this mean that all urgent support requests or bug fixes were added to the teams work board in a special column. A few minutes before the daily “stand-up” the Product Owner and Team Lead would review these and decide if it was immediate action, push-back or hold for the next regular planning meeting.
(In the most urgent cases work might begin as soon as the request was made but that decision was reviewed just before the stand-up the next day.)
In another case I convened a weekly meeting to review all the urgent work requests which had some in in the last week (mostly things people called bugs.) Collectively we would agree the prioritisation (1, 2, … 5) and then, for just the priority 1s list them in priority order. Unless the customer service manager and myself (as Development Manager) agreed something new became more important during the week we stuck to this order.
There are plenty of other examples I can give but you get the idea. These triage processes work wonders at controlling task switching, confused priorities, decibel management and other sins. Consequently they boost productivity, work order and satisfaction.
Sacrifice one
Hand-in-hand with triage I often sacrifice one team member to urgent but unplanned work: bug reports, customer service requests, and so on. Even on a team of 3 or 4 having one person designated at the urgent work or fixer can payback both in addressing issues and allowing others to work uninterrupted. This designated person isn’t assigned to any other work, or at least nothing time critical.
There are a few engineer who relish this role and love nothing more than a stream of “small fixes.” Most engineers would rather work on bigger items and stick with them for a few days. So unless you are blessed with one of these people rotate the role between team members.
Routines
I’ve no claim to originality here, this is 101 in the agile processes playbook. Still it is effective. Choose the routines and ceremonies that make sense for your team: daily stand-up, regular planning/replenishment (I prefer weekly, most teams do it fortnightly, just please avoid 3-week sprints), retrospectives (not necessarily every iteration, perhaps monthly, at least quarterly) and regular releases. I’d love to work with a high performing team who do many releases a day but the only time I’ve seen teams doing such is with bug fixes. Again, weekly, fortnightly, monthly, these can all bring more structure than you have now.
And of course, if you are using OKRs create a cadence and put the dates in your calendar.
Create focus
Taken together those three suggestions: triage, sacrifice and routines all aim to create more team focus. Focus is one of the most powerful tools you can use. These three changes start to create focus.
Beyond them there is so much more that can be done to create focus: backlog structuring and prioritisation, OKRs, testing approaches, various graphs and measurements, …
Statistical forecasting
Even if a team is making effort estimates – in time, story points, tea bags or whatever – start collecting data. Actually, since most teams these days are using electronic tracking systems you probably have an archive of data which you can mine today.
Go and analyse the data.
How many “stories” do you do a week?
What is the cycle time for a story? What is the average? The longest? The shortest?
What is the average time a story spends in the backlog?
How many things are in flight at the same time?
What is the bug count? And what direction is it going in?
What is the team “velocity” ? More importantly, what is the backlog growth rate?
There are many more question you can ask your data. Not infrequently you find that the data you have is not good enough to answer these questions but that itself is information.
When you start to answer these questions you can start to forecast based on data not guesswork.
And by the way: I’m more than happy to help you analyse your data, just get in touch and we can work something out.
Quality
So far all my suggestions can be done relatively quickly. The next one is a longer burn: improve quality.
When you quality is low a defect – a bug – can raise a hand at any time and create chaos: disrupt a release, distract and engineer, panic a customer, etc. etc, Defects can be high profile, very disruptive and difficult to close. Defects can destroy any schedule or plan no matter how carefully constructed.
The solution is simple: improve initial quality.
To do this install test-first working, code reviews, frequent customer review, shorten feedback cycles, etc. The catch is these can take a little time before they pay back.
Two I haven’t mentioned
Now there are two things I haven’t mentioned so far and will have some readers wondering why I haven’t: reduce work-in-progress and introduce outcome oriented working.
Reducing WIP can have wonderful effects but explicitly reducing WIP requires authority or credibility – and usually the credibility is required to persuade someone with authority. Introducing triage, sacrifice and routines will have the effect of reducing WIP but without the overhead of persuading people that “doing less produces more”.
So I only target WIP directly once I have picked some other low-hanging fruit. Plus, having the data to back up my case will really help. Attempts to reduce WIP usually start with a screening of Stockless Production.
Similarly, outcome driven working requires a certain credibility and trust to pull off. So often people are just drowning in work which OBVIOUSLY NEEDS DOING. Even if the engineers aren’t then there are plenty of other people saying “Just F…ing do it!” So asking people to take a step back and think about the desired outcome can be hard. Better build up some credibility first.
That is my list, what would you suggest I add to it?
And if you would like to discuss these ideas further please let me know.