The slides cover many aspects of lean manufacturing, one of the topics covered is The Buffering Law
Systems with variability must be buffered by some combination of:
Tafoya and Skowronski explain the implication of this law
If you cannot pay to reduce variability, you will pay in terms of high WIP, under-utilized capacity, or reduced customer service i.e. lost sales, long lead times, and/or late deliveries.
The following variability buffering examples are provided:
- Ballpoint Pens:
- can’t buffer with time (who will backorder a cheap pen?)
- can’t buffer with capacity (too expensive, and slow)
- must buffer with inventory
- Ambulance Service:
- can’t buffer with inventory (an inventory of trips to hospitals?)
- can’t buffer with time (response time is the key measure)
- must buffer with capacity
- Organ Transplants:
- can’t buffer with WIP (perishable – very short usable life)
- can’t buffer with capacity (we cannot ethically increase capacity)
- must buffer with time
In software engineering we experience variability due to a number of reasons, including policies and practices we put in place. The prominent cause of variability considered here is changing requirements and the varying levels of demand for features.
This variably is due to a number of reasons e.g. a customer gaining insights after using the software, a new opportunity in the market, a change in regulation etc. This variability is largely due to external events. Iterative and incremental development practices help reduce the impact of this variability but this does not illuminate variablility. Therefore, according to the Buffering Law, we need to buffer with some combination of inventory, capacity or time.
We cannot buffer with inventory because we don’t know what the future requirements will be. If we did we would not have variability in the first place.
A teams capacity is their ability to produce features as and when the business needs them. There are a number of options teams can use to improve their capacity e.g. process improvements (ScrumKanban), technological improvements (automated acceptance tests), increasing or decreasing team size (two pizza rule).
Due to the nature of software development most teams are continuously trying to catch up with a backlog of requirements. Many of these teams are continuously improving their velocity. With this in mind, it is naive to think that we can cause a huge increase capacity simply because we need to. That is like saying we only take the short cut when we are in a rush. The teams capacity is not like a tap that we can turn on and off. While all teams can (and should) incrementally improve, drastically increasing capacity in times of need it is not always feasible and it is not a trivial task.
In software development we need to buffer with time. Teams aim to deliver the requested features over a period of time. As Tafoya and Skowronski point out, when you buffer with time you pay with “reduced customer service i.e. lost sales, long lead times, and/or late deliveries”. Which reads like a readers digest version of the history of software development.
Photo attributed to: Tim Pearce