Here at IBM’s Lean practice we use a diagram called ‘Mississippi’ to analyze demand. It is not so-called because it originates in Mississippi – in fact I’ve been given to understand that this tool was developed, and named, in our UK practice*. Instead, it’s called the Mississippi because, like that great river, demand comes from many different sources (or tributaries) and can leave a process through a number of different points (the delta). And, apparently, at times the Mississippi delta reflects tidal patterns and flows upstream. In the same way, demand can route back into, or upstream within, a process – for example, in the shape of rework.
We want to analyze the volume and frequency of demand for a number of reasons. Understanding demand helps us to:
- Identify failure demand – Where are additional requests re-entering the process, as rework? Where is there process activity which doesn’t ‘go anywhere’?
- Illustrate channels in and out of the process, so we can identify potential control points, or illuminate a lack of filter, and see where demand might be routed in via unexpected channels.
- Tell us what we don’t know: which elements of demand are we unaware of? We need to understand all demand so that we can build and resource (load level) a process which can meet that demand. Sometimes finding out what we don’t know is a lesson in itself.
These benefits are as relevant to Lean for DevOps as in any other area.
It’s hard to say what you’ll learn from conducting this analysis, until you’ve done it, as every Mississippi is different. But to demonstrate some of the valuable lessons I’ve learned from drawing up Mississippis, here are some real life examples:
In their different ways, each of these helped make the case for a shortening of the SDLC, closer coupling of development to business demand, and a more nimble deployment process.
*If you’ve seen this in use outside of an IBM engagement, I’d love to hear about it! Find me on Twitter to set the record straight.