In the previous post, I discussed how queues hurt product development cycle times, quality, and efficiency and as one reader pointed out, revenue as well. When queues become large, they can truly hamper our ability to compete effectively in the marketplace. Thus if we want to regain control of our schedules and be more responsive to the market place, we need to shrink queues. One place to start is by looking at batch size because queue size can never be less than the batch size (It can be much larger, but never less.)
When it comes to large batches, product management is a big offender. When I was a product manager at a company using traditional serial development (i.e. waterfall), I produced large 50 – 100 page Product Requirement Documents (PRDs) that represented three calendar months of development work. I would turn these over to the development team who required two calendar weeks just to read and respond with questions. When it finally was approved, engineering developed all the requirements defined in the release (except for the ones that got cut so we could hit our target dates.) They then sent their developed code to QA in one large delivery. When it finally passed testing, the company dumped, or rather I mean “deployed”, the release on the customer. Our account managers contacted each customer to inform them that this was a large release, many features had changed, and we recommend that they attend our full day training so that they will continue to find our application useful.
We need to think about structuring our work differently. Instead of creating large PRDs, we should instead outline the requirements so as to understand the inter-dependencies, identify user interface elements that need to be prototyped and tested, and be able to communicate the vision for the release. After this, break down each requirement into a minimum marketable feature (MMF)1. Define enough MMFs (three to 10) so that engineering can start development. Each time engineering starts work on an MMF, define another one for the queue. By doing this, you will see results faster, receive feedback sooner, and be able to adjust priorities as you learn more and/or new opportunities emerge. You might also notice your work load will become smoother, allowing you to be more responsive to your constituents.
1Minimum marketable feature (MMF) is described by Mark Denne and Jane Cleland-Huang in Software by Numbers: Low-Risk, High-Return Development (New Jersey: Prentice Hall, 2003). The authors describe an MMF as a feature that “creates market value in one or more of the following ways: competitive differentiation, revenue generation, cost saving, brand projection, and enhanced loyalty.”