Essential Scrum – Agile Principles (2)
Leverage Variability through Inspection, Adaptation, and Transparency
Prediction and Adaptation
- Keep options open.
- Accept that you can’t get it right up front.
- Favor an adaptive, exploratory approach.
- Embrace change in an economically sensible way.
- Balance predictive up-front work with adaptive just-in-time work.
- Validate important assumptions fast.
- Leverage multiple concurrent learning loops.
- Organize workflow for fast feedback.
Work in Process (WIP)
Work in process (or WIP) refers to the work that has been started but not yet finished. During product development, WIP must be recognized and properly managed.
- Use economically sensible batch sizes – Table 3.2
- Recognize inventory and manage it for good flow.
- Focus on idle work, not idle workers.
- Consider the cost of delay.
Focus on idle work, not idle workers
Idle work is work that we want to do (such as building or testing something) but can’t do because something is preventing us. Perhaps we are blocked waiting on another team to do something, and until that team completes its work, we can’t do ours. Or maybe we just have so much work to do that it can’t all be done at once. In this case, some of the work sits idle until we become available to work on it. Idle workers, on the other hand, are people who have available capacity to do more work because they are not currently 100% utilized.
Many product development organizations focus more on eliminating the waste of idle workers than on the waste of idle work. For example, in traditional thinking, if I hire you to be a tester, I expect you to spend 100% of your time testing. If you spend less than 100% of your time testing, I incur waste (you’re idle when you could be testing). To avoid this problem, I will find you more testing work to do—perhaps by assigning you to multiple projects—to get your utilization up to 100%. Unfortunately, this approach reduces one form of waste (idle-worker waste) while simultaneously increasing another form of waste (idle-work waste). And, most of the time, the cost of the idle work is far greater than the cost of an idle worker. Let’s explore why this is true.
To illustrate the issue, let’s apply the keep-workers-100%-busy strategy to the 4 × 100-meter relay race at the Olympics. Based on the keep-them-busy strategy, this race seems highly inefficient. I pay people to run and they seem to be running only one-quarter of the time. The rest of the time they are just standing around. Well, that’s not right! I pay them 100% salary so I want them to run 100% of the time. How about if when they’re not carrying the baton, they just run up and down the stands or perhaps run another race on an adjacent track? That way they will be utilized 100% at running. Of course, we all know that you don’t win the relay gold medal by keeping the runners 100% busy. You win the gold medal by getting the baton across the finish line first. So, the important takeaway is “Watch the baton, not the runners” (Lar- man and Vodde 2009). In the context of product development, the baton sitting on the ground equates to work that is ready to be performed but is blocked waiting for necessary resources. You don’t win the race (deliver products) when the baton is on the ground.
Anyone who owns a computer understands this graph. What happens if you run your computer at 100% (full processor and memory utilization)? It starts to thrash and every job on the computer slows down. In other words, the computer is working on more things and actually gets less productive work completed. Once you get into that state, it is very difficult to get out of it (you probably have to start killing jobs or reboot the machine). Your computer would be much more efficient if you ran it at closer to 80% utilization.
Cost of Delay
Cost of delay is the financial cost associated with delaying work or delaying achievement of a milestone.
Consider this question: Should we assign a documenter to the team on the first day of development or at the end of development? Assume that we assign the documenter full-time for 12 months to work on this product, even if he is not needed 100% of the time. Doing so costs an incremental $75K (think of this as idle worker waste) above what it would cost if we brought him on for two months at the end once the product reaches the state of “all but documented.” If we assign the documenter to do all of the documentation at the end, we will need him full-time for only two months, but we will also delay the delivery of the product by the same two months. If we delay shipping the product by two months, the calculated cost of delay in terms of lifecycle profits is $500K (lifecycle profits are the total profit potential of a product over its lifetime; in this example, that potential decreases by $500K). In this example, the cost of the idle worker is $75K and the cost of the idle work is $500K. If we focus on optimizing the utilization of the documenter, we will substantially suboptimize the economics of the overall product.
- Adapt to real-time information and replan.
- Measure progress by validating working assets.
- Focus on value-centric delivery.
- Go fast but never hurry.
- Build in quality.
- Employ minimally sufficient ceremony.
When to write a document
- It is a deliverable as part of the product (for example, installation instructions, user’s guide, and so on)
- Our goal is to capture an important discussion, decision, or agreement so that in the future we will have a clear recollection of what was discussed, decided, or agreed to
- It is the high-value way of helping new team members come up to speed quickly
- There is a regulatory requirement that a certain document be written (a cost of doing business in a regulated industry)