MMF driven sprints in a Kanban world

The more experience I get with Kanban, and the more I talk about it with people, I see that one of the main challenges is maintaining some form of goal-driven cadence that energizes the team.

If every one of your Kanban Cards/Stories is an independent goal (e.g. a support environment) its easy to connect to the business and there’s usually an SLA to energize you.

If you are working in an environment where the business goals are quite big, and have been broken down in order to flow through your system, its a different challenge.

I’ve lately been thinking more and more about how to use the MMF level to generate this cadence.

It actually started in a pure-scrum environment where a team was frustrated about fixed length sprints, and asked why not to do a sprint that is aligned with the delivery of the feature that they’re currently working on. Later, I’ve started to dive deeper and deeper into Kanban, and I’m seeing teams that I think will benefit from a clearer higher level goal than delivering stories. It also makes a lot of sense to align the cadence with the higher level activities, the “mini-projects” that you are working on.

In parallel, there was some discussion over in kanbandev around improving the status reporting/visibility around features in a kanban world. So I sat down with @AmitElad7, another Kanban freak to think about what we can experiment with here. Also, doing some research, I recalled that Scrum Type C is quite similar to what we are discussing. And I also came (again) across Kanban and the New New Product Development Game | AvailAgility which discusses MMFs and Scrum Type C and talks more or less about our direction here.

So, down to business, what are we talking about?

The main thing we came up with is the understanding that ideally, a team should be able to do an MMF-based one piece flow - meaning a WIP limit of one MMF per team.

What does this mean? lets assume the team is currently working on an MMF. This MMF has some stories in progress, some are done, some have been identified but not yet started. This is similar to observing a team which is in the middle of a Scrum sprint. They are working on stories, doing a daily standup, reviewing each story with their customer/product owner as it materializes. Once all the stories are done (working tested software, potentially shippable product), this MMF is also done, and can be reviewed (at the MMF level), retrospected. Then the team can start planning the next MMF - understanding the story, breaking down to smaller bits that can flow in the team and which the team can swarm on. Once the planning is done, the team can start working on this MMF-driven sprint.

So far so good.

Now a few questions come up:

* What is the length of this MMF-based sprint? Is it pre-determined using Estimation/Commitment? Does it emerge as the stories are completed and progress is made?

* What happens if the team cannot effectively swarm to one MMF? Do we introduce another MMF? What happens to the Cadence then? Do we do the Cadence as one big team, or break into teamlets that do the cadence for their MMF separately?

* How do we deal with the issue of first/last days of an MMF sprint? How do we use the Slack there, and how do we deal with overloading Testing at the end? Is it enough to say “break work into smaller story, use much more automation” and the other typical recommendations of how to avoid the ScrumFall? Since we are more of the Kanban evolution model, shouldn’t we allow a better way to deal with this than requiring a fast revolution?

* What kind of visibility/metrics can we align with th

I will not answer all questions today, but try to follow up in other posts soon. In the meanwhile we’re also trying out those things in actual client deployments, which in a true agile fashion will probably affect our thinking… :-)

To sum up for today, it seems like what we are talking about is improving the ability of the MMF to be a boundary object between a team and the bigger project/release, emphasizing it as the main object for discussion, tracking, reviewing, delivering to the downstream aspects of the workflow, and ideally releasing. This idea is sort of a mashup of different ideas raised by others, and I suspect some of the Kanban practitioners are already doing this at some level, but its not yet documented or supported fully by tooling at this point (as the discussion about feature-level burnups/CFDs/parking lots in kanbandev highlights).

It also might warrant a catchy name, which is not one of my strengths.

Screatureban? (Scrum-Feature-Kanban…)

FeatureBan?

Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.