Kanban, MMFs and the Goldilocks Principle

https://agileproductdesign.com/blog/2009/kanban_over_simplified.html really resonates with me.

The article explores Kanban and how it differs from other agile approaches such as Scrum.

My experience with scrum was as follows. You peel off a set of stories from the backlog to deliver in that sprint. Because you have a fixed-timebox there is pressure to make the stories quite fine-grained so you can be sure that they’ll fit in the time box, and you don’t have fractions of stories assigned to the sprint. You try and identify a theme to provide a common goal, but that can be a bit artificial, and some of the stories don’t really fit with it. Inevitably you are too greedy and as the end of the sprint draws near everyone feels under pressure to complete stuff, quality goes down, and then there’s a long tale of testing that ends up being done in the next sprint. Often the testing can’t be done anyway because you’ve got to wait for other stories to be completed before you have enough of an e2e experience to test (there’s only so much that can be achieved through unit testing). You try to write stories that are customer facing, but as they are quite fine-grained, this can be a bit of a struggle – stories creep in for backend and engineering work. You have trouble explaining the backlog to your stakeholders because the stories are too fine-grained to see the wood from the trees, and they are also not all customer-facing.

In order to cure these problems, we started evolving towards a Kanban approach, beginning by adopting the notion of Minimal Marketable Feature or MMF. An MMF is in the Goldilocks zone of granularity – neither too big nor too small, just right. There is a beautiful tension between making the feature marketable yet keeping it minimal, and a lot of hard work goes into designing the backlog and getting this right, as it should. We still have stories – they are used to break down the work to deliver an MMF, and we still try to make them customer-facing to keep the team thinking that way but don’t force it.

MMFs are marketable, so it became easier to communicate with stakeholders about the functionality being delivered and how it contributes to the business.

Execution focus turned away from the sprint to the MMF. When is the MMF expected to ship? Is the burndown of stories/tasks for that MMF tracking to that expected date? If not, what’s blocking, can the block be removed? Or is it that it’s just taking longer and expectations need to be reset with stakeholders? Do we need to shift effort from another MMF being done in parallel to one MMF to ensure that at least one gets completed ready for the next release? How is a release (= set of MMFs) tracking? Will all the MMFs make it (not too much of a disaster if they don’t, because all MMFs are designed to be self-contained, marketable in their own right)?

We found that a Kanban board of MMFs is quite an effective way of tracking progress. Focus shifts towards pushing an MMF across the board as quickly as possible, and lining up MMFs in the queue to feed the continuous delivery pipeline. There is no pressure to finish it against some arbitrary deadline (end of sprint); instead the team pushes itself to get MMFs through the system as fast as possible, though without skimping on quality and in a way that is sustainable long-term: late nights and productivity-sapping long hours are avoided as much as possible.

We have continued using sprints, but they’ve been demoted to useful planning checkpoints where an engineering team can re-evaluate it’s capacity, communicate with stakeholders about MMFs that have been completed since the last checkpoint, update expectations about when MMFs in flight are likely to finish, and raise awareness of what’s coming next in the queue. There is no longer a need to identify a theme for a group of stories in a sprint, because the MMF is the theme – all stories required to build it are naturally grouped.

I wouldn’t go back to Scrum.