This is an expression originally used to describe a process for
writing code. Make it work—
I think this should be applied far more broadly than just writing code.
One example that comes up in almost every team I’ve ever been part of, is Agile ceremonies and in particular Retrospectives. Every sprint, we air our grievances and then come up with a dozen or so vague action items for behavioural improvements that are impossible to assign to any individual and never get actioned. Invariably most of the same points come up again at the next retro and the cycle repeats itself.
In the past I’ve suggested a few approaches to making retrospectives more effective that not every team follows by default. The first step is often to mix up the retrospective format. Some of the common formats include Start Stop Continue, Glad Sad Mad, Liked Learnt Lacked Longed For, and Sailboat. Some of these formats might resonate better with your team and be more likely to lead to good action items.
Next we add timeboxing, making sure to only discuss each topic for a fixed amount of time. This saves us wasting time chasing non-productive rabbit holes, only realising how much time we’ve lost after it’s too late. If we want to keep discussing the same topic for longer than our timebox that’s fine too, as long as it’s a conscious decision and we put another timebox on it.
Next we add a voting system to prioritise topics. Instead of discussing things in the order they are written down on the board, and invariably wasting a lot of time on trivial issues, we make sure to discuss the important topics first so that if we run out of time at least we only missed the unimportant topics.
Next we try to cut out non-productive discussion. If the goal is to come up with action items for team improvement, then don’t mention any problems that can’t be actioned. I get that everybody loves an opportunity to complain about problems they had during the week, but if there’s nothing we can do to fix them then save it for beer o’clock. Whinging is a great way to suck up precious time in your retrospectives.
These approaches usually lead to some improvement, but they always felt to me like approaching the problem from the wrong direction. Let’s think about this from the perspective of Make it Work, Make it Right, Make it Fast.
What does it mean for a retrospective process to work? I would say, that we actually manage to address at least a single issue raised at the retro. What does it mean for the process to be right? I would say, that we are able to prioritise issues appropriately such that our actions make as big an improvement as possible. What does it mean for the process to be fast? I would say, that we are able to address more and more issues over time.
What we have to start with is a process that doesn’t work, isn’t
right, but arguably is fast—
So from the perspective of Make it Work, Make it Right, Make it fast, what should we do to make our retrospectives more impactful?
The first step is to make it work. So what if after writing down all our thoughts and grouping them up, we vote on one single problem, perhaps the easiest one, and spend the rest of the time thinking hard about how we can actually make a meaningful improvement to just this one problem. If we can’t do this, we have no hope of making meaningful improvement to a dozen problems. We need to show that the process can actually work.
Then, and only then, can we shift our focus to making it right—
Finally, when we’ve demonstrated that not only can we make meaningful
improvements, but we know how to prioritise problems, then it makes
sense to make the process fast—
When you suggest this you’re naturally going to get pushback. If we only attempt one action item per sprint, it’s going to take too long to improve. Besides, we should have the capacity to do more than one thing at a time so why not try? But if history tells you that despite this nothing ever gets done, then what’s the harm? You say we can improve faster if we try a dozen different improvements, I say we can improve faster if we actually make a single improvement.
Make it work, make it right, make it fast. In that order.