Common wisdom defines value as something that customers are willing to pay for. That line of thinking is applicable to repeatable processes, such as manufacturing.
When it comes to digital product development, processes are not nearly as repeatable as they are in manufacturing. In the new product development, what customers might find valuable are often unclear. In such environment, we need a new definition of value. That definition must support the discovery of who our customers are and what their needs are.
Validated learning
Since value is not known upfront, we must engage in the process of learning what value for the customer might be (“Value is what customers actually want”, Womack and Jones, Lean Thinking).
Another guiding principle for finding out value is by Gerald M. Weinberg: “Value is what people are willing to pay (or do) to have their requirements met.”
The only plausible way to perform the process of validated learning is to adopt the hypothesis-driven development. We do not push our ideas of what customers may be willing to pay for; instead, we switch to the pull model of working.
Pull means doing work in response to the immediate downstream demand.
To be able to gain insight into the downstream demand, we need to propose a hypothesis and immediately implement it. Once implemented, the modified product gets placed in customers’ hands, and we collect feedback by observing customer behaviour.
That feedback, collected via implemented hypothesis, is then used to validate the hypothesis. It can either corroborate the hypothesis (in the sense of “yes, we were right, that change indeed delivers value to the customer”), or it can falsify the hypothesis (“it looks like we were wrong in assuming that the change will deliver value to the customer”).
“The trick to learning rapidly is creating small cheap experiments that will inform a decision you’re trying to make” -Joshua Kerievsky
Establish the pull model of working
Once the value has been identified, the delivery of the value should be mapped into steps. Each step must contribute, in a partial way, to the delivered value. It is vitally important that the necessary steps occur in tight sequence. That way, value flows smoothly to the customers.
Why is it called ‘pull model of working’? Customer behaviour (identified via hypothesis-driven development) pulls the value from the next upstream delivery. Customer behaviour determines which hypothesis will enter (will be pulled into) the value stream.
Seek perfection
Common wisdom warns us that perfect is the enemy of good. In this case, however, we seek perfection not by being dissatisfied with the good, but by eliminating waste.
Well established value stream with steps necessary to implement the pull mode of working can easily be invalidated if we allow waste to enter the process and to begin festering. It is paramount to keep a watchful eye on any signs of waste and to diligently eliminate it.
What is waste?
Anything that is not positively identified as value is waste.
For example, imposing an inspection gate at the final step of value stream delivery is waste. It is not possible to inspect quality into a product. Finding out that the value is defective after the value has already been implemented is completely wasteful. Garbage in, garbage out.
Inspection must be eliminated and replaced with the full-fledged shift-left process that favors early and frequent failures that happen all the way upstream.
How to measure flow?
Flow is characterized by four metrics:
- Cycle time (how long does it take from starting to work on a hypothesis to fulfilling the hypothesis)
- Lead time (how long does it take from the moment we collected validated learning to fulfilling it)
- Throughput (the number of steps completed in a fixed amount of time)
- Work-in-Progress, or WIP (the amount of work that has started but not completed)
It should be obvious that the more we manage to eliminate waste, the smoother and tighter the flow will get. The goal is to achieve short cycles, shorten the lead time, increase the throughput while minimizing the WIP.
What is this tightening of flow buying us? The short answer is increased frequency of feedback.
Factors that threaten to slow down flow
- High WIP – as a leading indicator of cycle time WIP is the primary intervention point to enable us to establish, or interrupt, the flow. High WIP introduces speed bumps into the flow. Reducing the WIP speeds up the flow.
- Multitasking – it’s a deception that maximizing the utilization of people and resources increases the throughput; fully utilized highway becomes a parking lot.
- Minimize slack – tightening the screws and cramming more work into a queue has about the same level of effectiveness as jamming more paper into the printer hoping that will increase the speed of printing.
Making changes in how we work
We’ve been tasked with focusing on continuous improvement. It is not possible to continuously improve without experimentation and rapid learning. It is therefore useful to adopt a work discipline that is based on several principles:
- Leave task lists behind. We should not focus on things we want to do; instead, focus on the minimum essential completion criteria. What do we have to do to deliver this minimum essential completion sooner?
- Stop measuring outputs; only measure required outcomes.
- Stop starting and start finishing. Favor dealing with steps that are closest to the finish line. Ignore steps that are still stuck at early stages of the flow.
- Set WIP ceilings. Each step comprising the value delivery process must have a WIP cap. Periodically revisit those WIP caps and experiment by making the WIP capacity even smaller. Did the experiment accelerate the delivery, or did it slow the delivery down?