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. To develop my perspective, let me step back and use analogy from manufacturing. I promise it all comes together in the end. For now, a SAT question:
Push Planning is to Traditional Management as Kanban or Pull System is to
a) Time Blocked Iterations
b) Story Points
c) Burn Down Rate
When computer software started managing factories in the 60’s, a team of IBM analysts developed Materials Requirements Planning (MRP or Push contorl 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. Now, change your mindset to development, and re-read this paragraph replacing “push” with “traditional management”, “lead time” with “work estimates”, “parts” with “requirements”, “work stations” with “development teams” and “final assembly” with “project.” Does it bother anyone that manufacturing figured this out before development managers?
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. If you picked “all of the above” to the SAT question, give yourself a gold star. Those three components work together to enable development teams to Pull work – thus, the focus on burn down rate. Along with time blocked iterations and story points, it enables maximizing team and project performance. How to apply them and the Fist “law of development physics” are coming up next.
Credits: Much of what is covered in this post is directly or by analogy 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 all development processes and 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.”