Workflow – Minimally Marketable Features

Posted by: Dave Goerlich in Agile.

As I described in the overview of Our New Development Process, the MMF (Minimally Marketable Feature) workflow is the customer facing portion of our development process.  Our changes in this area have had the biggest impact upon our clients, and have met a positive response.  It has allowed us to isolate our clients from the implementation, and remain focused on the behavior of their application.

Our transition to a lean development process was the first exposure most of our clients had had to any type of agile environment.  Understandably many of them felt out of their element and truthfully we felt the same way.  What really made the transition successful for us and our clients was the trust that came from the good relationships we’ve maintained.  Being very transparent with our clients went far in cementing that trust.  We let them know that this was a major change for us too, that we were (and still are) learning and refining our process.  Since our clients are very much part of the project team, I openly solicited input from them on how we could improve the process.

Kanban Boards

We employ separate MMF Kanban boards for each client’s project.  Each board has the following queues through which the MMFs flow:

1. Backlog – This is an unordered list of all MMFs that have been conceived. This queue has no limit. It serves as a dumping ground for ideas as simply existing in this queue does not imply any commitment that an MMF will ever be implemented. MMFs in the Backlog may or may not have an estimate.
2. Pending / Scheduled – This queue is prioritized with a limit of 3. Barring priority changes, MMFs in this queue are committed to development. A planning meeting with the client is triggered when this queue reaches 1 item. During this planning meeting the next two MMFs to be developed are identified and added to the queue in order. The client is welcome to change priorities at any time, reordering the queue or swapping MMFs from the Backlog. All MMFs in this queue will have an estimate.
3. Work In Process (WIP) – To address our goal of reducing WIP, this queue has a limit of 1. It is while an MMF is in this queue that the nested, story card based workflow is employed.
4. Acceptance Testing / Show & Tell – Again, to reduce WIP, this queue has a limit of 1. Once the MMF in this queue is ready, a deploy of the software is triggered.

Estimation

Each MMF is given a “shirt size” of small, medium, large or extra large.  These estimates are assigned at any time while the MMF is in the backlog queue.  Sometimes estimates are assigned when an MMF is added to the backlog.  Other times an MMF does not receive its estimate until we are about to pull it into the pending queue.  There is no scientific method for determining the shirt size of a given MMF. It’s a simple process of assigning a “gut feel” based on the description of the MMF.

Even though there is no formal process to calculating them, some of our clients have found them quite valuable in helping determine priority.  We’ve had clients make the decision that the combined value of 3 small MMFs outweighed the value of one large MMF, and pulled them into the pending queue ahead of it.

Once MMFs have been pulled into the pending queue, the estimate serves as the primary tool by which we can answer the client’s question of “How long until I have this?”

Estimates are not carved in stone.  As we work, we understand the scope of an MMF better and uncover knowledge upon which we are able to make a better estimate.  Sometimes development of a higher priority MMF will impact the estimate of an MMF farther back in the workflow.  The more accurate our estimates, the more valuable and useful they are.  We update our estimates as necessary for the overall good of the system.

A change of more than one size, such as small to large or XL to medium, does trigger a review as to why we are making such a significant change to our original estimate.  Even though the process of setting an estimate is one of an educated guess, we do want to continue to improve our ability to make accurate guesses.

Data Tracking, Trailing Indicators and Their Application

There is a significant amount of data that exists around just this part of our development process – enough to keep a data mining, business intelligence geek busy 40+ hours a week.  The truth is, however, that if I were to spend my time doing analysis of our process – there wouldn’t be enough flow through the process to generate data worth analysis.  We are a tiny team of 2, after all.  I applied YAGNI, and we are only tracking the couple of data points that are critical to our management of the system.

For every MMF, we track the date it is pulled into the WIP queue (start date) and the date it is finished in the acceptance test queue (complete date).  From those two dates, we are able to calculate and record the MMF’s cycle time.  We do not record any additional data points for MMFs.

We log MMF cycle times by complete date and estimated size.  I maintain population means by estimate size, rounded to a full day.  I’m then able to use these averages to compute the answer to the client’s question of “How long?” by applying them to all MMFs ahead of the one in question.  MMFs in the WIP or acceptance testing queues  are included by determining days left as the difference between start date + average days and today.

Flexibility to Interface with our Client’s Business

Each client and each project will naturally be a little bit different than the last.  We have adapted this workflow a little bit to better fit with our client’s business process.  For one client, we expanded the limit for the pending queue to 5.  This allows for a longer interval between the triggered planning meetings, which fits better with his schedule.  For another client we actually maintain the backlog as a collection of different lists of MMFs – one for each functional area of the project.

Kaizen

Our goal is to work towards the most efficient and effective process for developing software for our clients.  Just as I solicited input from our clients for improvements, I’m very interested to hear your feedback on this workflow.