This is an expression originally used to describe a process for writing code. Make it work—get something, anything, running as quickly as possible. Make it right—get the program to do what you want it to. Make it fast—get the program to do what you want it to fast enough for your needs. What’s important here is the order. If you do these in the wrong order, you’re gonna have a bad time. The easiest time to make code compile and run is when there’s barely any of it and it doesn’t really matter what it does. It’s really hard to fix bugs in tightly optimised code, because it’s likely a lot more complicated than it was before you optimised it.
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—we can generate a dozen random action items like clockwork every sprint, we just can’t action them.
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—which would be figuring out how to address the right problem. This requires us to get better at identifying where the biggest pains are in our team and also where we can make the biggest improvements. This might mean getting better at measuring various things about our team and how they impact velocity, or better understanding the expectations that other parts of the business have of us and how we impact them.
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—to start taking on more than one action item at a time. As we get better at executing on these action items, we can start to take on more of them each time, getting faster but also making sure we keep the process working and right.
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.