In a previous blog article, I mentioned how I was getting back to my programming roots and reading The Principles of Product Development FLOW: Second Generation Lean Product Development by Donald G. Reinertsen. I am in the process of reviewing each chapter. I have already posted my reviews of:
- Chapter 1. "The Principles of Flow"
- Chapter 2. "The Economic View"
- Chapter 3. "Managing Queues"
- Chapter 4. "Exploiting Variability"
- Chapter 5. "Reducing Batch Size"
Here is my review of Chapter 6, "Applying WIP Constraints."
The premise of applying Work In Progress (WIP) constraints is that it helps even out the workflow and leaves room for unexpected events. This is a challenge for organizations that believe that a pipeline at full capacity is the best approach for bringing products to market in the shortest amount of time possible. Chapter 6 of the book recommends that batch size be reduced. In an agile software development process sense, that means keeping the number of features to be completed in a given sprint small. Chapter 7 is a corollary in that, in addition to keeping the requested feature list small, the actual work in progress should be kept small.
There are two primary ways to organize teams:
-
A functional organization has all of the people in the same group who work on a function that is common to all of the organization. At Autodesk, we have teams organized in this fashion such as Human Resources, Finance, and Legal.
-
A project organization where all of the people in the same group work on the same project even though they have different responsibilities. At Autodesk, we have teams organized in this fashion such as AutoCAD, Fusion 360, Revit, and 3ds Max. These different teams all come under our Product Development Group so that best practices are shared and the result is a unified experience across product lines. We are putting more emphasis on the latter as of late.
Chapter 7 addresses the problem of random variations in flow. Applying work in progress constraints evens out the development process. For example, requiring that there are not too many completed features for QA to test allows the QA team to keep up with the project. A remedy for the limitations imposed by applying work in progress constraint is to cross-train some of the programmers so that they can test when the QA queue reaches its limit. [page 156] This would certainly help software development projects regardless of organization; however, in the case where work in progress constraints are applied so that software development managers have capacity to address emergencies, such as the need to generate a hot fix, that seems more suited to functional organizations. In an agile development process, the development team is focused solely on the features in the sprint for the duration of the sprint. There are no unexpected arrivals of work to be done.
The great thing about this book is that it provides all of the theory as mathematical formulas coupled with real-world examples that software practitioners can understand.
Queue management is alive in the lab.