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"
- Chapter 6. "Applying WIP Constraints"
- Chapter 7. "Controlling Flow Under Uncertainty"
Here is my review of "Chapter 8: Using Fast Feedback." The premise of this chapter is that software development projects need to use feedback loops and control systems for the economic benefit of the company conducting the projects. Unlike manufacturing systems were variation is the enemy, the goal is to exploit the variability that is associated with software development since developing each piece of code is different.
The chapter makes some key points.
When managing a project via metrics, it is better to look at leading indicators. If lagging indicators are used, it is too late to make adjustments by the time the metrics are calculatable. For example, it is better to track the start times for project tasks instead of completion times. Tasks that start on time tend to end on time. If a task fails to start on time, adjustments can be made such as assigning other resources or shortening the tasks. For tasks that are late in completing, less can be done, since much of the work has already been accomplished.
Corrective actions should be taken based on economic impact instead of absolute changes in proxy variables. [page 217] It's not a good idea to put a project on the hot seat merely because it is a week late. Only projects where the consequences are grave should achieve such treatment.
Adaptive control systems are designed to track dynamic goals. These differ from control systems for static goals. Because software development projects have inherently high amounts of variability (i.e., no two pieces of code being written are exactly the same), it is critical to recognize when goals should be dynamic instead of fixed at the start of the project. [page 219]
Fast feedback compresses the time between cause and effect. It allows projects to take corrective actions sooner rather than later.
Although most projects tend to ensure that programmers are 100% loaded, to ensure companies are getting the most for their programming dollar, organizations operating at 100% capacity utilization usually apply too little resources, too late, to change a project's direction when the unexpected occurs. [page 223]
Control systems can be made faster and more efficient by controlling decisions without participating in them. [page 225] If programmers are aware of the rules that govern a project, they can make these trade-offs themselves without having to escalate issues. Knowing the rules also demystifies the decision-making process and improves project morale.
Feedback systems are not limited to providing information back to upstream processes. [page 229] They can also provide information downstream. For example, if code reviews during the coding process determine areas of code that are less than solid, QA can be alerted to this fact that when the code is released later in the project, extra testing is warranted. In addition, extra time for logging defects can be allocated in the QA schedule.
"Slow feedback undermines urgency in product development and leaves workers feeling like victims of a monolithic machine. When we accelerate feedback loops, we improve efficiency and generate urgency. Feedback is orders of magnitude more important in product development than it is in manufacturing." [page 241]
The book makes a great project analogy using a relief valve.
A mechanical relief valve opens at a certain pressure. This pressure is chosen to avoid overstressing the system that is being protected. The relief valve recloses at a certain pressure since it is undesirable to completely depressurize a system. If the pressure range between the opening and closing point is too small, the valve will cycle open and shut many times, an undesirable condition...
When we establish a relief valve for a project, we worry about similar details. For example, consider the case of using the feature set as a relief valve for schedule variation. This entails dropping features when we deviate from the planned schedule. We need to decide how large a deviation will trigger dropping features, who will make the decision, which features will be dropped, and how much total work should be dropped. It is important to drop sufficient work content to return the project to the center of its control range... It is insufficient to return the project to slightly below its upper limit because this is an inherently unstable operating point. [page 227]
My management mentor, Eric Wagner, wrote a great book on software project management entitled Shutting Up: Listening to your employees, Leading by example, and Maximizing productivity (see my review). In it, he covered this very topic with a formula.
The central theme behind the formula is that a given project development team can only develop so much content (C) at a given quality level (Q) given a stated amount of budget (B) and (S) schedule. Unless a process change is introduced, the rate at which progress can be made is a constant (k). This formula was developed based on our work at GTE where upper management wanted to "add more features" without any adjustments to resources nor time, yet expect the same quality. In a related fashion, the central idea behind Chapter 8 of The Principles of Product Development FLOW is that fast feedback gives a project an opportunity to make these adjustments based on the economic value associated with the consequences.
Project adjustment is alive in the lab.