Wait is waste! Value stream mapping, as Wikipedia reads, is a lean manufacturing technique used to analyse and design the flow of materials and information required to bring a product or service to a consumer.
The process of visualising a value stream is valuable for many reasons, one of which is that it can highlight bottlenecks or wait states. A wait state is a period of time in which actors in the value stream are waiting for something to happen, e.g. waiting for another dependent actor to finish their task. Actors in a wait state are typically not being utilised and therefore wasting time and money. Visualising the stream and quantifying the cost of these wait periods can often lead to fundamental organisational change.
In plan based or waterfall delivery wait states are ever present, at least from a single project perspective. All phases have a certain lead time while actors (analysts, developers, ops, testers etc.) start work and feed back more work to the other actors. The larger the phases, the longer that lead time is (within limits of course). Developers develop while testers wait, Testers test while developers wait. So how do you deal with these wait states? Typically speaking a customer isn't going to be to fond of paying for people to twiddle their thumbs. Depending on the period of time the wait state is expected to last you're either going to have to take the hit or repurpose the actors elsewhere. Repurposing is a very common practise - you'll see analysts swoop in at the start of a project write up a big document and slingshot onto the next project, resourcing has be carefully orchestrated so that a developer can roll off one project onto another that is about to start development and of course this all requires that the project goes according to plan - its like a giant game of Jenga. In the middle of a riot.
These practises may help reduce visible wait states but fail totally at solving the root problem - you've simply diverted peoples attention. You've traded off the measurable for the unmeasuarable. You've lost valuable insight by losing your analysts, increased the time taken to deliver features to due ramp up time for new developers and reduced effectiveness of testing because all the testers usually have to go on are out of date documents. Its hard to make a change when you don't realise doing it badly. The other glaring issue here is that the practitioners aren't the ones covering the cost of these problems - its the customer.
So what of agile & lean? The agile/lean model actually tends toward reducing wait states naturally. The model promotes 2 things
- an "everybody, all at once, from early on" (Lean Architecture) mentality. This is realised in the form of a team being the primary unit of delivery as opposed to a specialist with the support of a team.
- Delivery in small batch sizes. Deliver in smaller increments reduces lead time between deliverables. In fact any large constraints that can potentially create lag become immediately apparent and need to be dealt with to facilitate quick return.
The team analyses, the team develops, the team tests, the team deploys, the team doesn't need to wait. Start to finish the people that know the most deliver the solution and they do so by delivering small chunks of features to the customer to support continuous and evolving understanding of the solution. This reduces any potential bottlenecks from knowledge loss or misinterpretation of what the end user wants.
If you're coming from an organisation that is used to cycling siloed roles and specialists (analysts, developers, testers) the transition to a more team focused cross functional model isn't an easy one but the result is a more effective, predictable approach to delivery which benefits both yourself and the customer.