The Right Thing
When my team and I started working on our new project, it seemed like this daunting pile of work with no end in sight. Initial guesses put us at a time horizon of four months to get it all done. It was way later than everyone would have liked.
So we set out to see how we can speed things up. At first we started to negotiate the scope, but we were already looking at an MVP plan, there wasn’t much to trim. With a fixed scope – our backlog in hand – and a clear budget – 40 person hours in any given week (at best) – we turned to look into getting the most out of the time we have – and to figuring out where we were losing time.
Enter stage right: A tool called LinearB provided us insight into our current flow of change.
Coding time → time waiting for a review → time it takes to review → time waiting for a deployment → deployment
Looking at the data immediately made it clear that we were losing or wasting a lot of time, waiting for things to happen.
With LinearB as a canary, we made a number of changes to improve our flow of work. Every time, we kept tracking if indicators moved in the right direction. This post is just about the first and possibly most impactful step we took.
There’s very little reason to wait for reviews, and virtually no reason to wait for a deployment.
Just Leave it Out
The most straightforward way to eliminate these waits is to do just that: eliminate them.
Mob programming or ensemble programming are the best approach to this: The whole team works on the same problem together, in one large session with a shared screen. Once a problem is solved, everyone has seen, contributed to and reviewed the solution automatically, by virtue of being present. (There's a bit more to it, but bear with me for argument's sake.)
This is a highly effective step and yields surprising results. It's also very counter-intuitive to most people. Getting a dev team and wider organization on board with this technique is a whole endeavor in and of itself, in many cases.
So with this idea promoted to ultimate goal, I thought about what first step we could take to make small-but-significant improvements to our way of work. This is the first iteration, we came up with.
The Rule
We changed our workflow to focus on these waiting things first, with a very simple rule:
When picking your next activity, focus on the right-most column first.
Deploy what needs deploying – the right-most column (besides Done).
Then review what needs reviewing – second column from the right.
Then see if you can unblock blocked tickets (we placed the Blocked column after In Progress).
Next, try to help out with something already in progress.
Lastly, start a new item.
Our cycle time (DORA definition: the time between starting development and deploying the code to production), shortened quite a bit, just from eliminating the waste of waiting.
Why does this matter? Aren’t we working in sprints, delivering a package at the end?
It matters because focusing on delivering every task as soon as possible allows for the fastest feedback cycle. Every step after the initial coding time adds feedback and improves the work. Wait time delays this feedback, but without this feedback we can’t know if a given task is in fact done already. We run the risk of not finishing the story within the sprint. Earlier feedback mitigates that risk and increases the chance of delivering everything we committed to.
When focusing on the thing on the right, you’re focusing on the right thing.