Understanding Lean product development: Batch Size, Work in Process (WIP) & Risk
The following is a chapter from my book Rocket Fueled Process available for free PDF download.
Note: As we build complex systems, the size of our batches of work, and the number of those batches, directly influences our risk profile. We can think of it like Sprints in a Scrum process, or tickets on a Kanban board. If we queue too many tasks/tickets, and those items remain open and working in parallel, we have exponentially increased our risk profile, often without acknowledging the gross cost.
Understanding Batch Sizes and Risk
Batch size is the size, measured in work product, of one completed unit of work. Cycle time is the amount of time it takes to complete one batch of work. What we focus on with lean development is reducing batch sizes, thereby reducing cycle times, thus increasing potential learning points over time.
Batch size, risk and cycle time are all directly proportional. As any grows larger, so do the others. The amount of risk we create is equal to our batch size and cycle time, i.e. our total work in process. Risk shows itself in the form of total investment at risk (this could be labor, inventory, market opportunity cost, revenue, etc). As such, batch size is also directly correlated to the number of blind assumptions (i.e. untested hypotheses) that inform our product release.
As shown in the drawing below, the graph on top performs incremental releases over eight cycles. The graph on the bottom uses all eight cycles to perform one release. The process on the bottom generates 64 times more potential work at risk.
Implementing Work in Process Constraints
Work In Process (WIP) is any ongoing work that has not been completed. The largest and most identifiable component of WIP is batch size. As Donald Reinertsen states in The Principles of Product Development Flow, the most simple and powerful economic driver in a development process is a reduction in batch size, i.e. to constrain WIP.
By limiting our WIP or batch size, we achieve the following beneficial properties:
- Minimum queue size
- Minimum iteration length and cycle time
- Maximum speed to completion (Minimum time to market)
- Minimum technical risk
- Minimum personnel risk
- Minimum documentation
- Fast hypothesis testing, rapid learning
- Minimum cost of ownership per increment of completed work
- Reduce the number of blind assumptions that fuel our decisions
Eliminating Unnecessary Work In Process (WIP)
Work in process goes far beyond the core development cycle. Here are some easy questions to identify wasteful work in process:
- Are people creating documentation for products months in advance of any ability to implement?
- Do our designers over-design every interface and add features that we clearly do not have the capacity to complete?
- Do we have ‘brainstorming’ sessions in the middle of a pre-defined cycle?
- Do engineers over-engineer for their emotional gain? Does oversight exist to prevent this?
- Are all of our teams driven by the same organization priorities? Will they be able to cross the finish line together?
Synchronicity Is Essential
With the absence of a framework for implementing constraints on a development process, things naturally get out of sync. This is very dangerous to an organization because upstream production will not respect downstream capacity. This relationship becomes very inefficient because different teams cannot unite around a common business goal. Furthermore, the collective parts of the organization become unable to share the responsibility of overall business success. Unsynchronized teams are prone to scary risk profiles, extreme waste, and hard failures.
An organization will end up with team-specific velocities, work in process, batch sizes and cycle times. If any other teams or the entire organization are dependent on a main large branch (or batch of team work), as seen below, the failure or misdirection of that main branch could be catastrophic.
A common example of synchronicity risk is the ‘swat team.’ Somehow the rest of a development team is either too busy or perceived as lacking enough talent to complete an initiative. A specialty team will be brought in to work in a vacuum apart from the standard process. The failure points for this become misdirection, incorrect assumption and difficult project integration with the greater system.
Synchronize Small Batches Around Common Goals
The ideal scenario is for all teams in an organization to develop a predictable development cycle, with proper cadence and inter-team delivery. When upstream units respect downstream capacity, much of the unnecessary work in process is naturally eliminated, therefore creating more resources for revenue generating initiatives or optimizations.
Read more from my book Rocket Fueled Process, available for free PDF download.
