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.