What’s so Wrong with Pushing

In agile development, much emphasis is rightfully placed on burn down rate, the number of story points completed within an iteration of development. I’ve never been fully satisfied with explanations for why this measure and control of it is so critical. In reality, burndown is only meaningful when story points are limited in a time-blocked iteration.

To develop my perspective, let me step back and use analogy from manufacturing. I promise it all comes together in the end.

When computer software started managing factories in the 60’s, a team of IBM analysts developed Materials Requirements Planning (MRP or Push control system). The idea was that you could break down any manufactured assembly into its component parts, assign lead times to each for how long it needed processing before it was joined to a larger assembly and have the system release or Push parts to work stations for construction at the appropriate time. MRP became a hit in the US and Europe. By some estimates sales of MRP systems reached almost 1/3 of all software sold in the US in the late 1980’s.

Then along came Toyota. As MRP’s popularity crested, Toyota was out manufacturing the US and took a large part of the rap for the decline of American manufacturing. Their secret weapon: Kanban. In Japanese, Kanban simply means “card.” Here the idea was that when a work station was ready for more parts, they sent authorization or a card to request it. The amount requested was a fixed amount determined by the cycle time of manufacturing and rate of processing. This rippled back through the process to Pull work along each step of production.

Comparison of push to pull manufacturing control systems. Adapted from Hopp and Spearman, Factory Physics, Foundations of Manufacturing Management, Mcgraw-Hill/Irwin, 1996, p 163.

How could a simple card take down the computing power of IBM? In looking for the answer to why Push did not work, pundits, and scholars of the 1980’s used similar arguments that we hear today for why traditional project management does not yield better results: The parts data needs to be more accurate. Master production schedules needed to be more realistic. More training is required to teach the concepts. Top management needs to be more involved.

Eventually, most agreed that the true fundamental problem was that Push is based on a flawed model. Lead times for Push calculations are attached to parts that have no awareness of what is actually happening at their work stations. If the work stations are idle, the same amount of work is scheduled as if they are working overtime. This problem is complicated by the fear that a late start for a part can cause it to miss final assembly which encourages inflated lead times and even more work to get scheduled for already backed up work stations.

Pull systems solved this flaw by using the card as a signal to indicate the state of the work station. Only when a work station is able to take on more work, is it requested. And, then, only for an amount that can be processed quickly while maximizing throughput.

Kanban boards are a simple way to apply a pull system to a team working together. When properly done, they limit the number of cards that can be in any phase of work for a team. New work cannot be pulled in for the team to work on until there is space on the board for a new card. This space is only created by finishing the  work of a previous card.

Iterative development is another way to create pull. Work is pulled by measuring how much is completed in an iteration by measuring burndown. This sets a limit to the number of story points (units of work) in a time-blocked iteration. Each iteration pulls only as many story points as the burndown chart demonstrates is possible to complete within an iteration. Together story points, burndown charts, and time-based iterations enable pulling work to maximize team and project performance.

How to apply these and the the first of the “laws of development physics” are coming up next.

Credits: Much of what is covered in this post is credited to Wallace Hopp’s and Mark Spearman’s great book Factory Physics, Foundations of Manufacturing Management, Mcgraw-Hill/Irwin, 1996 and the application of its principles while working at George Group. I pulled my original edition off the shelf last week. A 3rd edition has since been released. So much of what they discuss in this book has application to development processes and broadly to any business process. I encourage anyone searching for fundamental principles to dig into it. I’ll be referring to it as I further develop some of my “laws of development physics.”