The Anatomy of an MMF

I’ve been involved in a number of discussions about how User Experience work fits into an Agile process.  As a result a trying to articulate my position, I’ve come up with the following explanation of the anatomy of an MMF.

The following diagrams assume the following key:

Lets start by looking at a typical waterfall model:

In this case, all the UE work would happen early on, but obviously, isn’t Agile, so doesn’t allow for iteration and improvement.

A more Agile approach is:

In this case, the UE work is spread across the lifetime of the project, but for each increment, UE work happens early, relative to build etc.

That’s still not truly representative of an Agile project, which is more collaborative, so we have:

Here, everything happens together, as needed, for each Product Backlog Item (PBI, using Scrum terminology) and this is where the problem begins.  In order for a PBI to be sufficiently formed to be able to be planned into a Sprint, there may need to be Analysis and UE work in advance.  So typically these become PBIs of their own in preceding Sprints.  The problem I have found with this approach is that the focus is on the PBI, and the over-arching feature of value is lost, resulting on long cycle times.

So this is how I prefer to think about it:

Throughout the life of a Minimal Marketable Feature, the different disciplines are involved to varying degrees.  More UE earlier on, and more QA later.  However, the focus is still on the over arching feature, and all are still collaborating to deliver the feature as quickly as possible.  Any Sprints or PBIs are simply mechanisms to manage the flow.

Given this view of things, its a small step to allow MMFs to overlap, so that the features can smoothly flow through the system.

Rating: 4.0. From 1 vote.
Please wait...

3 comments on “The Anatomy of an MMF

  1. Great article. This was a realization that we also had in my last group. Our scrum team was a cross-functional group that included the Business Analysts, UI/UX group, and QA. Immediately those matrixed resources complained of not being able to make decisions on the fly for the developers to keep coding. They wanted time to analyze, test, work. The developers wanted to ask a question and immediately have the answer.

    Our agile mentors taught us that in scrum there are three maturity levels…
    1- hard sprint boundaries: Rest periods in between are required so that the business can digest, think, and set up the next sprint.
    2- cascading sprint boundaries: The business helps the team get into a rhythm for the current sprint and then spends the last half of the sprint focusing on setting up future sprints.
    3- sprint boundaries disappear, there is flow: The end of the sprint is a notification to show whatever is done and assess progress, but there is never a grand discussion about what the future holds. The business always has a detailed vision of the next 2 sprints, basic vision of the next 6, and a roadmap for the future. EVERY DAY, the team evolves this with the customer and moves forward.

    This is probably documented somewhere, but I can’t find the source easily. It was conveyed to me from either ObjectMentor or J.B. Rainsberger in 2006 if you want to search for original source.

    Your images do a great job of conveying these ideas. Especially the line flow. This post should become a good resource for agile adopters seeing antipatterns.

    No votes yet.
    Please wait...
  2. For my teams I split feature development to two parts: analisys and deesign goes to one sprint and the rest (build, test, release) goes into the following sprint. As a result – minimal upfront design, and maximal focus on development (in part 2 as all required details already discussed)

    No votes yet.
    Please wait...
  3. Excellent post – this is the best description I have seen on this particular subject so far (and I’ve looked at a lot of definitions). I’m trying a KanBan approach with our IT service delivery team to smooth out the never-ending amount of BAU work they have to get through. At the same time they have to deliver new services to our development teams, which I’m using a Scrum approach for.
    At the moment I’ve got a multi-functional whitebaord with the Scrum bits in the top section and a KanBan channel underneath. Maybe I’ll be brave enough to merge the two sometime 😉

    No votes yet.
    Please wait...

Comments are closed.