Lean Enterprise: How High Performance Organizations Innovate at Scale (Lean (O'Reilly))

by Jez Humble

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.

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”).

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.

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.

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.

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.

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.

To run a value stream mapping exercise, we must gather people from every part of the organization involved in the value stream.

must include those who are able to authorize the kind of change required to achieve the future-state value stream.

We want enough detail to be useful, but not so much that it becomes unnecessarily complex and we get lost arguing about minutiae.

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

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.

Table 7-1. Metrics for value stream mapping Metric What it measures Lead time (LT) The time from the point a process accepts a piece of work to the point it hands that work off to the next downstream process Process time (PT) The time it would take to complete a single item of work if the person performing it had all the necessary information and resources to complete it and could work uninterrupted Percent complete and accurate (%C/A) The proportion of times a process receives something from an upstream process that it can use without requiring rework

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.

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.

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?

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.

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.

“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.”5

Corriente de valor

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 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.

Kanban: Successful Evolutionary Change for your Technology Business.

Figure 7-7. An example of a Kanban board

work in process (WIP)

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...

Work in process

Kanban Method follows four...

Start with what you do now Agree to pursue incremental, evolutionary change Initially, respect current roles, responsibilities, and job titles En...

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 continuou...

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 Ka...

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%.

One of the biggest problems in product development is delivering valuable features so late that they no longer provide a competitive advantage.

Frameworks such as Scrum recommend to prioritize the backlog by business value but offer very little guidance on how to calculate it.

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”).

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. ...

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.