Product Details Lean Enterprise: How High Performance Organizations Innovate at Scale (2015)

Part III. Exploit

Chapter 7. Identify Value and Increase Flow

There is nothing so useless as doing efficiently that which should not be done at all.

Peter Drucker

The measure of execution in product development is our ability to constantly align our plans to whatever is, at the moment, the best economic choice.

Donald Reinertsen and Stefan Thomke

Most enterprises are drowning in a sea of overwork, much of which provides little value to customers. In addition to improving existing products and delivering new ones, every enterprise has several initiatives and strategic projects in play at any given time, and every day unplanned work arrives to distract us from achieving our goals. A common response to this problem is attempting to increase utilization (work harder), improve efficiency (work faster), and cut costs using outdated and counterproductive management processes. Lean Thinking provides a proven alternative which “can be summarized in five principles: precisely specify value by specific product, identify the value stream for each product, make value flow without interruptions, let the customer pull value from the producer, and pursue perfection.”¹²⁹

In the previous chapter we showed how to implement a program-level continuous improvement strategy to improve productivity and quality and reduce costs. In this chapter we show how the five lean principles were adopted by Maersk to reduce the cycle time of new features by over 50% while simultaneously increasing quality and return on investment.

The Maersk Case Study

In “Black Swan Farming using Cost of Delay,”¹³⁰ Joshua J. Arnold and Özlem Yüce discuss how they approached reducing cycle time in Maersk Lines, the world’s largest shipping company. Maersk’s IT department had an annual IT budget of over $150m, with much of its development carried out by globally distributed outsourcing vendors. They faced a large amount of demand and slow time-to-market: in 2010, median lead time for a feature was 150 days, with 24% of requirements taking over a year to deliver (from conception to software in production). At the point of analysis, in October 2010, more than 2/3 of the 4,674 requirements identified as being in process were in the “fuzzy front end,” waiting to be analyzed in detail and funded. In one case, “a feature that took only 82 hours to develop and test took a total of 46 weeks to deliver end-to-end. Waiting time consumed over 38 weeks of this,” mostly in the fuzzy front end (Figure 7-1).

Figure 7-1. Value stream map of a single feature delivered through a core system at Maersk (courtesy of Joshua J. Arnold and Özlem Yüce)

Based on the desired outcomes of “more value, faster flow, and better quality,” Arnold and Yüce chose eight goals for all teams:

1. Get to initial prioritization faster

2. Improve prioritization using Cost of Delay

3. Pull requirements from Dynamic Priority List

4. Reduce the size of requirements

5. Quickly get to the point of writing code

6. Actively manage work in progress

7. Enable faster feedback

8. Enable smooth, sustainable flow

Previously, features had always been batched up into projects, resulting in many lower-value features being delivered along with a few high-value ones. The HiPPO method (highest paid person’s opinion) was used to decide which features were high-value, and a great deal of effort was spent trying to find the “right ideas” and analyzing them in detail so as to create projects, get approval, and justify funding.

Arnold and Yüce implemented a new process for managing requirements. They created a backlog of features—initially at the project level, but later at the program and portfolio levels—called the Dynamic Priority List. When new features were proposed, they would be quickly triaged, causing the backlog to be reprioritized. When development capacity became available, the highest priority feature would be “pulled” from the list.

Features were prioritized using the Cost of Delay method (described in detail later in the chapter) which estimates the value of a feature in dollars by calculating how much money we lose by not having the feature available when we need it. Using this approach, we can determine the impact of time on value and make prioritization decisions on an economic basis. For example, the cost of delay for the feature shown in Figure 7-1 was roughly $210,000 per week, meaning that the delay incurred by having the feature wait in queues for 38 weeks cost $8M. Putting in the extra effort to calculate a dollar value is essential to reveal assumptions, come to a shared understanding, and move away from relying on the most senior person in the room making the prioritization call.

The actual number used to prioritize features is known as cost of delay divided by duration (or “CD3”). It is calculated as cost of delay for a feature divided by the amount of time we estimate it will take to develop and deliver that feature. This takes into account the fact that we have limited people and resources available to complete work, and that if a particular feature takes a long time to develop it will “push out” other features. Logically, if we have two features with the same cost of delay but one will take twice as long as another to develop, we should develop the shorter-duration feature first. One of the impacts of accounting for duration is that it encourages people to break work down into smaller, more valuable pieces, which in turn increases the CD3 score.

Implementing the Dynamic Priority List and using CD3 to schedule work helped the team to achieve several other goals on their list, such as faster initial prioritization, reducing the size of requirements, writing code more quickly, and creating a smoother flow. By July 2011, median cycle time had been reduced by about 50% on the two services piloted. (One of the pilot services was a centralized SAP accounting system.) Arnold and Yüce present two factors causing the reduction in cycle time: increased urgency generated by the Cost of Delay calculation exercises, and decreased batch size caused by people breaking work into smaller chunks to increase the CD3. Furthermore, customer satisfaction increased significantly on the pilot projects.

Perhaps most interestingly, calculating the cost of delay clarified which work was most important. In the two systems analyzed, the distribution of cost of delay followed a power law curve. The cost of delay per week numbers for the features in the pilot service, shown in Figure 7-2, make it abundantly clear which three requirements should be prioritized above others. These requirements were not identified as being of the highest priority before the cost of delay was calculated.

Figure 7-2. CD3 per feature (courtesy of Joshua J. Arnold and Özlem Yüce)

The Maersk case study demonstrates the importance of using a flow-based approach to product development instead of large batches of work delivered in projects, and of using the Cost of Delay—not intuition or HiPPO—to measure the relative priority of work to be done.

Increase Flow

As we discussed in Chapter 6, we want to improve the performance of the delivery process before we tackle improving alignment. However, if we want to see substantial improvements in performance, we need to start by choosing the right places to focus our efforts. It’s common to see large organizations waste a lot of effort making changes to processes or behaviors that are highly visible or easy to change but not a major contributor to the overall problem. We need to begin any improvement effort by understanding where the problems arise and making sure they are understood at all levels of the organization. Only then will we have the right context to determine what to do next.

Map Your Product Development Value Streams

The best way to understand where problems start is by performing an activity called value stream mapping.¹³¹ Every organization has many value streams, defined as the flow of work from a customer request to the fulfillment of that request. Each value stream will cross multiple functions within an organization, as shown in Figure 7-3.

Figure 7-3. Value streams passing through departments

In the context of exploiting validated ideas for software, the value streams we care about are related to product development, from taking an idea or customer request for a feature or bug fix to delivering it to users. Every product or service will have its own value stream.

To begin, we select the product or service we want to study, and map the existing value stream to reflect the current condition. To avoid the common mistake of trying to improve through local optimization, it’s essential to create a future-state value stream that represents how we want the value stream to flow at some future point—typically in one to three years. This represents our target condition. The current and future value streams can then be used as the basis for improvement work by applying the Improvement Kata across the scope of the entire value stream, as shown inFigure 7-4.

Figure 7-4. Value stream mapping in the context of the Improvement Kata

To run a value stream mapping exercise, we must gather people from every part of the organization involved in the value stream. In the case of product design and delivery, this might include the product’s business unit, product marketing, design, finance, development, QA, and operations. Most importantly, the value stream mapping team must include those who are able to authorize the kind of change required to achieve the future-state value stream. Often, getting all the stakeholders to commit to spending 1-3 days together in a single room at the same time is the hardest part of the process. Aim for the smallest possible team that fulfills these criteria—certainly no more than 10 people.

Performing value stream mapping involves defining, on a large surface (Figure 7-5), the various process blocks of the product’s delivery. How you slice and dice the value stream into process blocks (also known as value stream loops) is a bit of an art. We want enough detail to be useful, but not so much that it becomes unnecessarily complex and we get lost arguing about minutiae. Martin and Osterling suggest aiming for between 5 and 15 process blocks.¹³² For each process block within the value stream, we record the activity and the name of the team or function that performs it.

Figure 7-5. Outline of a value stream map showing process blocks

Once we have a block diagram, we gather the data necessary to understand the state of work within the value stream. We want to know the number of people involved in each process and any significant barriers to flow. We also note the amount of work within each process block, as well as queues between blocks. Finally, we record three key metrics: lead time, process time, and percent complete and accurate, as shown in Table 7-1.

When mapping a value stream, we always record the state of the processes as they are on the day we perform the exercise. It’s extremely tempting to record numbers representing an ideal or best case state rather than the typical state—but looking at what the numbers are right now helps to keep people on track. Wherever possible, the team should actually go to the places where the work is done and ask the people doing it for the real numbers. This helps the team to experience the different environments where works take place across the value stream.

The output of a simple value stream mapping exercise for a single feature that goes through a relatively straightforward product development value stream is shown in Figure 7-6. If it proves useful, we could go into more detail on each of the stages of the process and state what happens when a process rejects input as incomplete or inaccurate. This is particularly important when the ratio of lead time to process time is large or when the downstream process has an unusually poor %C/A.

Figure 7-6. Example value stream map of a feature

Running this exercise for the first time in an organization is always enlightening. People are invariably surprised—and often shocked—by how processes in which they do not participate actually work and are impacted by their work. We have seen arguments break out! Ultimately, by producing a better idea of how work moves through the organization, value stream mapping increases alignment, empathy, and shared understanding between the stakeholders.

Perhaps the most valuable metric when performing this exercise is %C/A. It’s very common to discover that a great deal of time is wasted on failure demand such as rework: developers discover flaws in the design, testers are given builds that cannot run or be deployed, customers ask for changes when they see features showcased, and critical defects or performance problems are discovered in production or reported by users. Facilitators of these exercises should come armed with questions to discover and capture rework, such as:

§ At which points do we discover problems in the design?

§ What happens in this case?

§ Who is involved in that step?

§ How do handoffs work?

§ At what point do we discover whether the feature actually delivers the expected value to customers?

§ Where are architectural problems (such as performance and security) discovered?

§ What is the effect on lead time and quality?

These issues should be captured on the value stream map, their probability recorded in the form of %C/A in the processes that discover them and (where possible) attributed to the part of the value stream where they were actually caused.

The total amount of waste in an enterprise value stream is usually very sobering. While everybody has an intuitive grasp that enterprise value streams are inefficient, seeing the whole value stream from idea to measurable customer outcome often reveals staggering amounts of waste. This waste manifests itself in the percentage of time that is not value-adding, in how often work is sitting idle in queues, and crucially in the %C/A numbers that show us where we have failed to build in quality during upstream processes.

Finally, value stream mapping reveals the folly of local optimizations. In almost every case we have seen, making one process block more efficient will have a minimal effect on the overall value stream. Since rework and wait times are some of the biggest contributors to overall delivery time, adopting “agile” processes within a single function (such as development) generally has little impact on the overall value stream, and hence on customer outcomes.

In most cases we need to rethink our whole approach to delivering value by transforming the entire value stream, starting by defining the measurable customer and organizational outcomes we wish to achieve through our redesign. In order to mitigate the disruption of this kind of change, we usually limit our efforts to a single product or set of capabilities within a product—one which would most benefit customers and the organization as a whole.

We then create a future-state value stream map which describes how we want the value stream to function in the future. The goal of this design activity is to improve performance. Martin and Osterling define optimal performance as “delivering customer value in a way in which the organization incurs no unnecessary expense; the work flows without delays; the organization is 100 percent compliant with all local, state and federal laws; the organization meets all customer-defined requirements; and employees are safe and treated with respect. In other words, the work should be designed to eliminate delays, improve quality, and reduce unnecessary cost, effort, and frustration.”¹³³

There is of course no “right answer” to creating a future-state value stream map, but a good rule of thumb is to aim to significantly reduce lead time and improve rolled %C/A (indicating we have done a better job of building in quality). It’s important for participants in this exercise to be bold and consider radical change (kaikaku). Achieving the future state will almost certainly require some people to learn new skills and change the work they are doing, and some roles (but not the people who perform them) will become obsolete. For this reason, as we discuss in Chapter 11, it’s essential to provide support for learning new skills and behaviors, and to communicate widely and frequently that nobody will be punished for carrying out improvement work—otherwise you are likely to experience resistance.

At this stage, don’t try to guess how the future state will be achieved: focus on the target conditions to achieve. Once the current and future-state value stream maps are ready, we can use the Improvement Kata to move towards the future state. In Chapter 6 we described the use of the Improvement Kata to drive continuous improvement at the program level. The target conditions for the future-state value stream map should be fed into program-level Improvement Kata cycles. However, where value streams extend beyond the teams involved in programs of work—perhaps into IT operations and business units—we need to also establish Improvement Kata cycles at the value stream level, with owners who establish and track key performance indicators and monitor progress.

Warning

Organizations using the phase-gate paradigm (described in Figure III-1 at the beginning of Part III) will find the principles described in the following chapters increasingly hard to implement without fundamentally changing their organizational structure. The Improvement Kata described in Chapter 6 can (and should) be implemented everywhere as it makes almost no presuppositions about organizational structure. We have just discussed how to map and improve the flow of work through your organization, which will enable you to begin incrementally changing the form of your organization and the roles of your people. Chapter 8 discusses lean engineering practices that enable faster, higher-quality delivery at lower cost. If your organization outsources software engineering, your outsourcing partners will need to implement these practices, and this is likely to require changes to your relationship, including potentially contractual changes. Chapter 9, which describes an experimental approach to product development, requires that designers, engineers, testers, infrastructure specialists, and product people work collaboratively in very short iterations. This is extremely hard to do when any of these functions are outsourced; it’s marginally easier when all teams are internal, but still requires everyone to work in a coordinated way.

Everyone can, and should, begin the journey we describe in Part III. Be forwarned: implementing the entire program will be disruptive to most organizations and take years of investment and experimentation to achieve. Do not try to implement the entire program across all of your organization quickly—use value stream mapping and break down future-state value stream maps into blocks to do it iteratively and incrementally, value stream by value stream.

Limit Work in Process

If our goal is to increase the flow of high-value work through the product development value stream, value stream mapping represents an essential first step. However, we must take further steps to manage the flow of work through the system so as to decrease lead times and increase predictability.

In the context of product development, the Kanban Method provides principles and practices to support this goal, as described in David J. Anderson’s Kanban: Successful Evolutionary Change for your Technology Business.¹³⁴ First, we must visualize the flow of work through the value stream: we take the current-state value stream map and translate it to a physical or virtual board with columns representing process blocks and queues between blocks. We then create a card for each piece of work currently passing through the value stream, as shown in Figure 7-7. These cards are moved across the board as work progresses through the value stream.

Figure 7-7. An example of a Kanban board

We can visualize the dynamics of the value stream by creating a cumulative flow diagram that shows the amount of work in each queue and process block over time. An example of a cumulative flow diagram is shown in Figure 7-8. It clearly shows the relationship between work in process(WIP) and lead time: as we reduce WIP, lead time falls.¹³⁵

In the Maersk case study, we discussed two ways to reduce the size of the batches of work that move through the product development value stream: reduce the size of requirements and unbundle projects into requirements that can be prioritized independently. Limiting WIP is another powerful way to reduce batch size. Since reducing batch sizes is the most important factor in systemically increasing flow and reducing variability, and has important second-order effects such as improving quality and increasing trust between stakeholders, we should pursue these practices relentlessly, and measure our progress.

Figure 7-8. A cumulative flow diagram

The Kanban Method offers a comprehensive way to manage the flow of work through the product development value stream by using the following practices:

§ Visualize workflow by creating a board showing the current work in process within the value stream in real time.

§ Limit work in process by setting WIP limits for each process block and queue within a value stream, and updating them in order to trade off lead time against utilization (how busy people are).

§ Define classes of service for different types of work and the processes through which they will be managed, to ensure that urgent or time-sensitive work is prioritized appropriately.

§ Create a pull system by agreeing on how work will be accepted into each process block when capacity becomes available—perhaps by setting up a regular meeting where stakeholders decide what work should be prioritized based on available capacity.

§ Hold regular “operational reviews” for the stakeholders within each process block to analyze their performance and update WIP limits, classes of service, and the method through which work is accepted.

WIP LIMITS SHOULD HURT

Part of the purpose of WIP limits is to reveal opportunities for improvement. Imposing WIP limits will focus attention on work which is blocked or hard to complete, since our inability to complete it prevents us picking up new work. At this point, it’s tempting to relax WIP limits to make sure “something is getting done.” It’s essential to avoid this temptation and address the sources of the problem instead.

The Kanban Method follows four principles of continuous improvement designed to minimize resistance to change:

§ Start with what you do now

§ Agree to pursue incremental, evolutionary change

§ Initially, respect current roles, responsibilities, and job titles

§ Encourage acts of leadership at all levels

The Kanban Method is a powerful tool to improve performance and increase quality and trust at the team level in an environment where there is no buy-in for continuous improvement at the senior management level. In such a situation, we strongly recommend that teams deploy the Kanban Method as their first step to get better. Once you have demonstrated measurable improvement, you still need to pursue enterprise-level continuous improvement since, in a typical enterprise context, adopting Kanban at the team level is likely to lead only to incremental improvements.

Managing Work in Process at the Enterprise Level

The primary goal of limiting WIP is to finish work to a sufficiently high level of quality so as to increase throughput. Reducing lead times in this way requires that there be sufficient slack in the system to manage the WIP effectively. Slack is also essential to provide time for process improvement work. Since 20th-century Taylorist theories of management emphasize maximizing employee utilization, this requires a significant change in thinking for many organizations.

In enterprises, one indicator of too much WIP is the number of people assigned to more than one project. This pernicious practice inevitably leads to longer lead times and lower quality due to constant context switching. Instead of assigning people to multiple projects, have a centralized team that can provide extra specialist support to teams on demand, but do not assign these people to any teams and carefully monitor their utilization to keep it well below 100%.¹³⁶

Cost of Delay: A Framework for Decentralizing Economic Decisions

One of the biggest problems in product development is delivering valuable features so late that they no longer provide a competitive advantage. As the Maersk case study shows, a major contributor to this problem is batching up features into projects and delivering the results to customers after months of waiting. Value stream mapping often reveals—as it did at Maersk—that much of the time spent waiting was in the analysis phase, with features sitting in the product backlog waiting to be analyzed, estimated, approved, and prioritized for development.

As we saw in Chapter 3, the information provided by these activities is of very low value. Frameworks such as Scrum recommend to prioritize the backlog by business value but offer very little guidance on how to calculate it. Prioritizing by business value also fails to make explicit the time sensitivity of work. However, a powerful framework for making rational prioritization decisions based on economics exists in the form of Cost of Delay.¹³⁷ The team at Maersk reduced cycle times for high-value features through a combination of unbundling features from projects and using Cost of Delay as a lightweight method to identify and prioritize the work with the highest opportunity cost.

To use Cost of Delay, we begin by deciding on the metric we are trying to optimize across our value stream. For organizations engaged in product development, this is typically lifecycle profit, but a logistics company might use a metric such as cost per ton mile (the amount it costs to move one ton a mile). When presented with a decision, we look at all the pieces of work affected by that decision and calculate how to maximize our One Metric That Matters (see Chapter 4) given the various options we have. For this, we have to work out, for each piece of work, what happens to our key metric when we delay that work (hence “cost of delay”).

Let’s start with a naively simple example to outline the mechanics. Say we have two pieces of work that we could begin when we arrive on Monday morning. We are assured (quite forcefully) that they are both of the highest priority. What should we do?

We start by calculating how much it will cost us if we do not do the work. Task A is to upgrade a core piece of software to a new version that supports encrypting credit card data to meet a compliance deadline, which is two weeks from now. We will be fined $50,000 per working day that we are not in compliance. The cost of not doing this work is zero up until the point at which the penalty kicks in, and the cost of delay for the work is $250,000 per week after the deadline. Task A will take two weeks.

Task B is to complete a key feature required by prospective customers, which we have already advertised will be ready one week from now. We expect we will close $100,000 of business per week when we release this new feature. Furthermore, one of our competitors is right behind us, and we believe they will release a new version of their software with this feature one month from now. Task B takes one week to complete.

The arithmetic is simple, and our options are shown in Figure 7-9. If we perform Task A first, then we delay Task B by two weeks, costing us $200,000. If we perform Task B first, we delay Task A by a week, costing us $250,000. Thus we should perform Task A first.

Figure 7-9. How do we prioritize Tasks A and B with Cost of Delay?

We can also calculate what happens if we try and do both tasks simultaneously. Assuming we assign half our capacity to each, it will take us two weeks to complete Task B and three weeks to complete Task A. That leads to a total delay cost of $350,000. This shows we should still perform Task A first before Task B.

Use CD3 to Encourage Smaller Blocks of Work

Applying the CD3 method as described in the Maersk case study, Task A’s CD3 is 125,000, whereas Task B’s CD3 is 100,000, which tells us that Task A is higher priority. Suppose we have an alternative to Task B: Task C. Task C will provide the same value to 80% of the customers who wanted the feature delivered by Task B ($80,000 per week), but we estimate that completing C will take half of the time of B (.5 week). Task C’s CD3 will be 160,000, making it higher priority than Task A. Using CD3 consistently has an important side effect—it encourages us to break work into smaller and more valuable chunks.

There are several consequences to using Cost of Delay. By calculating cost of delay for each feature, we no longer rely solely on a product owner to estimate the business value for the stories in the backlog, which is a poor way to prioritize since this person must constantly recalculate in order to take into account the time sensitivity of business value. Instead, given that we have limited capacity, we think of prioritization as choosing what to delay.

When development capacity becomes available, the team simply picks the item with the highest delay cost at that time. This is a key advantage of using Cost of Delay: following the Principle of Mission, it allows everybody in the organization to make rational, transparent economic decisions without the need for command-and-control mechanisms such as onerous reviews, approvals, and prioritization by the most senior person in the room. We separate out several concerns which can each be addressed independently at the correct level of the organization:

1. What is the economic metric we are trying to optimize? (Remember the One Metric That Matters from Chapter 4.) Communicating this metric is the responsibility of leadership.

2. What is the impact on this metric of delaying each piece of work? Calculating this delay cost is the key goal of analysis.

3. How should we schedule and prioritize work? This can be determined autonomously by teams given the information from points 1 and 2 above.

Furthermore, Cost of Delay provides us with an economic argument for limiting work in process. As we saw in the example above, the delay cost of trying to perform both A and B simultaneously was greater than completing the individual tasks sequentially.

Of course, the example above is very simplistic. First of all, we assumed that the cost of delay would remain constant over time. This is rarely the case in real life. For example, the cost of delay for Task A rises to $50,000 per day right after the last day we can start the upgrade work to complete it in time to meet the external deadline. But for Task B, the amount of business we can close is likely to be time sensitive, given that our competitors will soon have a similar feature.

The time sensitivity of the cost of delay is captured in an urgency profile. Urgency profiles that might be used in real life for Task A and Task B are shown in Figure 7-10. Cost of delay, on the y axis, represents the amount of money it costs per unit time to delay the work. To calculate the totaldelay cost, we measure the shaded area under the graph. Although in theory there are many possible urgency profiles, in general almost all tasks in a given organization will fit a handful of standard profiles. These can be modeled within a Kanban system by using classes of service.

Figure 7-10. Urgency profiles for Task A and Task B

The second problem we face is that in many cases, it is extremely hard to get a precise dollar number for cost of delay. To arrive at a number, we typically make several assumptions and include multiple factors. For example, not completing Task A on time might lead to a loss of customers’ confidence in our ability to keep their data safe, which could impact future sales. It’s important to make these assumptions explicit, visible, and recorded alongside the work being discussed so we can validate them. The most important thing to bear in mind is that we are aiming for accuracy, not precision, in our estimates. If the uncertainty around the cost of delay is very high, this means we are in the “explore” domain and must test our assumptions, perhaps using one of the techniques, such as modeling a key metric with Monte Carlo simulations or testing business hypothesis with MVPs, discussed in Part II.

One of the major benefits of Cost of Delay is that instead of arguing about answers to the questions we pose, we can reason about the assumptions we make in our models and focus on validating them. Cost of Delay enables a key cultural change—from political fights over whose work is more important to exposing and validating our assumptions and their effect on economic variables. This does require a certain level of organizational maturity. As with all process changes, we recommend starting off with a product where people actually want to try using Cost of Delay, and providing the necessary support to experiment with it.

Applying Cost of Delay across the enterprise allows us to decentralize decision making and bring decisions under economic control. To do this, we have to change the way we think about managing work, particularly the role of the group responsible for prioritizing decisions at the portfolio and program level (often known as the project management office, or PMO). In the Cost of Delay model, the key responsibility of this group changes from making the actual decisions to creating and updating the framework for making decisions: working with finance and individual projects to create standard urgency profiles and templates, gathering and analyzing data, rolling out cost of delay across the organization, and creating feedback loops to continuously improve the quality of the decision-making process. The actual decisions can then made by teams on the ground, based on the cost of delay information updated when there is new work or when the assumptions underlying existing calculations change. This is a large change that will require executive support, a pilot, and improvements based on learning before it is ready to be adopted by the organization as a whole.

Finally, there are things that you should not do with Cost of Delay. Avoid simply adding cost of delay on top of existing prioritization methods. Its purpose is to improve the quality of demand by enabling us to identify and avoid lower-value work whilst shortening lead times for high-value work. If we turn Cost of Delay into a heavyweight process that sits alongside existing processes, we will not achieve that goal. Cost of Delay provides the biggest payoff when queues are large—in other words, when there is a long lead time. It is essentially a countermeasure that becomes valuable when there is too much work in the system. If you don’t have large queues and too much work, using Cost of Delay will likely provide little overall value.

In the context of software-based products and services, implementing lean engineering practices is essential to reducing lead times overall and gathering rapid customer feedback as early as possible in the product lifecycle. The ultimate solution for the deficit of throughput—and thus productivity—is to reduce lead times overall by reducing batch sizes, managing work in process, and reducing the cost of delivering value to customers. In terms of measuring value, there is no substitute for shipping and getting real customer feedback.

Conclusion

In high-performing organizations, leadership and management has a sharp focus on the value the organization is creating for its customers. Working scientifically toward challenging goals, which leads to identifying and removing or avoiding no-value-add activity, is the essence of Lean Thinking, and this requires a significant mindset change for most organizations. Value stream mapping is a powerful tool to visualize our work, so we know our current conditions and create a shared understanding of where we are and where we want to get to. An effective value stream mapping exercise can be truly eye-opening by allowing teams to see, for the first time, the flow of work through the organization in response to customer demand, and their true contribution within it. The output of a value stream mapping exercise is then used to set target conditions for the Improvement Kata described in Chapter 6. We can then use the Kanban Method to manage the flow of work through the value stream, set and update WIP limits and classes of service, and create a pull system to increase flow.

Improving the flow of work through the organization is one side of the coin. The other is making sure we are working on the right things. Cost of Delay provides a way to measure the value of time, enabling teams to make transparent prioritization decisions. By quantifying the value of the work we are doing, we can avoid doing low-value work. If we limit work in process across the value stream and only work on the highest-value tasks, we can rapidly reduce time-to-market for work which is the highest value to our customers.

Questions for readers:

§ How is work prioritized in your team or organization? Do you use an economic model or do HiPPOs decide?

§ How would you try to implement an economic model for your current backlog? Why not look at the items within your current iteration queue and estimate the Cost of Delay for each?

§ What is your current lead time for changes? How could you reduce batch sizes in order to decrease lead time?

§ How do you discover the economic impact of your work once it is delivered? Do the team only focus on input and output metrics, such as velocity? How could you work with finance, product management, or other departments to understand business outcomes and bottom-line impacts of your work?

§ Do you batch features up into projects as part of your planning and funding processes? How might you unbundle projects and move to a model where you incrementally fund and deliver only the high-value work (we discuss financial management in Chapter 13)? How would you coordinate work across value streams?

¹²⁹ [womack]

¹³⁰ http://costofdelay.com; [arnold].

¹³¹ Value stream mapping was first described in [rother-2009] and is the subject of an excellent book by Karen Martin and Mike Osterling [martin].

¹³² [martin], p. 63.

¹³³ [martin], p. 101.

¹³⁴ [anderson]

¹³⁵ These two quantities are in fact causally related; in the mathematical field called Queue Theory this is known as Little’s Law.

¹³⁶ Pawel Brodzinski has a good article on WIP limits for portfolio management: http://brodzinski.com/2014/06/portfolio-management.html.

¹³⁷ The concept of Cost of Delay was invented by Don Reinertsen—see [reinertsen].