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

by Jez Humble

Many organizations moving to agile methodologies spend an undue amount of time on tool choice hoping to magically solve their underlying problems. But the most common failure mode for such organizations is their inability to change their organizational culture, not the availability of good tools.

Shareholder value is the dumbest idea in the world…[it is] a result, not a strategy…Your main constituencies are your employees, your customers, and your products.

For many years, the conventional wisdom held that corporate executives should focus on maximizing shareholder value, and this goal was reinforced by compensating executives with stocks.4 However, these strategies have a number of flaws. They create a bias towards short-term results (such as quarterly earnings) at the expense of longer-term priorities such as developing the capabilities of employees and the relationships with customers. They also tend to stifle innovation by focusing on tactical actions to reduce costs in the short term at the expense of riskier strategies that have the potential to provide a higher payoff over the lifetime of the organization, such as research and development or creating disruptive new products and services. Finally, they often ignore the value of intangibles, such as the capabilities of employees and intellectual property, and externalities such as the impact on the environment.

In fact, extrinsic motivators such as bonuses and rating people in performance reviews actually decrease performance in such nonroutine work.

It is common for people to focus on specific practices and tools that lean and agile teams use, such as Kanban board, stand-up meetings, pair programming, and so forth. However, too often these are adopted as rituals or “best practices” but are not seen for what they really are — countermeasures that are effective within a particular context in the pursuit of a particular goal. In an organization with a culture of continuous improvement, these countermeasures emerge naturally within teams and are then discarded when they are no longer valuable.

Clausewitz’ concept of friction is an excellent metaphor to understand the behavior of complex adaptive systems such as an enterprise (or indeed any human organization). The defining characteristic of a complex adaptive system is that its behavior at a global level cannot be understood through Taylor’s reductionist approach of analyzing its component parts. Rather, many properties and behavior patterns of complex adaptive systems “emerge” from interactions between events and components at multiple levels within the system. In the case of open systems (such as enterprises), we also have to consider interactions with the environment, including the actions of customers and competitors, as well as wider social and technological changes.

The most important concern leaders and managers operating within a complex adaptive system face is this: how can we enable people within the organization to make good decisions — to act in the best interests of the organization — given that they can never have sufficient information and context to understand the full consequences of their decisions, and given that events often overtake our plans?

Certainly the thieves may be able to follow the design plans and produce a loom. But we are modifying and improving our looms every day. So by the time the thieves have produced a loom from the plans they stole, we will have already advanced well beyond that point. And because they do not have the expertise gained from the failures it took to produce the original, they will waste a great deal more time than us as they move to improve their loom. We need not be concerned about what happened. We need only continue as always, making our improvements.16

Dear Eric, thank you for your service to this company. Unfortunately, the job you have been doing is no longer available, and the company you used to work for no longer exists. However, we are pleased to offer you a new job at an entirely new company, that happens to contain all the same people as before. This new job began months ago, and you are already failing at it. Luckily, all the strategies you’ve developed that made you successful at the old company are entirely obsolete. Best of luck!4

Whenever you hear of a new IT project starting up with a large budget, teams of tens or hundreds of people, and a timeline of many months before something actually gets shipped, you can expect the project will go over time and budget and not deliver the expected value.

Lean Startup principles are just as important for internal software engineering projects, including services and platforms such as private clouds, systems replacements, and so forth. Enormous initiatives, with roadmaps of months or even years, constantly pop up for these types of projects, with lip service paid to working incrementally to solve a real (internal) customer problem. In fact, teams building these systems are often dismissive of their customers’ needs and preferences — we often hear statements such as “we know what they need better than them.” Projects run in this way, without regularly delivering incremental value to their customers in order to get feedback, are an appalling waste of time and resources and rarely achieve their intent, outcome, or objectives.

But there are other serious negative consequences: internal systems that are painful to use make employees frustrated, impact morale and their ability to do their work effectively. Apart from underperformance costs, businesses create systems that add further complexity to already enormously complex production environments. The inevitable outcome is “shadow IT” — teams deserting the services approved or maintained by the IT department in favor of something better so they can get their work done. Organizations

The project paradigm exacerbates this problem. Projects typically take so long to go from start to finish that stakeholders try and ram as many features as possible into each one, mindful of the fact that it will be hard to get features added once the project is complete.

Define, measure, and manage outcomes rather than output. Applying the Principle of Mission, we specify “true north” for our program of work — our ideal stakeholder outcomes. Then, at the program level, we work iteratively, specifying for each iteration the measurable program-level outcomes we want to achieve. How to achieve these outcomes is delegated to teams working within the program. Based on the feedback from real customers after each iteration, we work to improve quality of demand, improve speed, and improve quality of outcomes.

Ensure people are rewarded for favoring a long-view system-level perspective over pursuing short-term functional goals. People should be rewarded for continuous and effective (win-win) collaboration, for minimizing the amount of work required to achieve the desired outcomes, and for reducing the complexity of the systems we create to enable these outcomes. People should not be punished when failures occur; rather, we must build a culture of experimentation and collaboration, design systems which make it safe to fail, and put in place processes so we can learn from our mistakes and use this information to make our systems more resilient.

When faced with a new opportunity or a problem to be solved, our human instinct is to jump straight to a solution without adequately exploring the problem space, testing the assumptions inherent in the proposed solution, or challenging ourselves to validate the solution with real users.

If we had one superpower, it would be to magically appear whenever a problem or new opportunity was under discussion. Our mission would be to prevent anybody from commencing a major program to solve the problem or pursue the opportunity until they do the following: Define the measurable business outcome to be achieved Build the smallest possible prototype capable of demonstrating measurable progress towards that outcome Demonstrate that the proposed solution actually provides value to the audience it is designed for Since we are only mortal, we trust that you will keep a copy of this book to hand to wield at the appropriate moment.

Long product development cycles dramatically reduce the potential return on investment we can achieve from successful new products. Most perniciously, long development cycles delay the time it takes to get customer feedback on whether we are building something valuable. Typical market research activities are poor at predicting a product/market fit, especially in new product categories. Research said that minivans and iPods would not be successful. In the absence of good data, people tend to get their pet projects funded. Particularly in enterprise IT, we often see spectacular amounts of money poured down the drain on systems replacement projects — even (perhaps especially?) in organizations operating in highly regulated sectors.

Let us be absolutely clear. In most enterprises, around 30%–50% of the total time to market is spent on activity which provides almost zero value in terms of mitigating the risks of our investments.

The most inefficient way to test a business model or product idea is to plan and build a complete product to see whether the predicted market for it really exists. Yet this is exactly what we do once we have an approved business case. Part of the problem is the language we use to describe the product development process. For example, consider the term “requirements.” Whose requirements are they? Are they user requirements? In Lean IT, Steve Bell and Mike Orzen comment that “users are often unable to articulate exactly what they need, yet they often seem insistent about what they don’t want…once they see it.”6

A common objection to these principles is that such experiments cannot possibly be representative of a complete product. This objection is based on a false understanding of measurement. The purpose of measurement is not to gain certainty but to reduce uncertainty. The job of an experiment is to gather observations that quantitatively reduce uncertainty.7 The key principle to bear in mind is this: when the level of uncertainty of some variable is high, we need very little information to significantly reduce that uncertainty.

As discussed in Chapter 2, an important factor in the success of the Lean Startup approach is to limit the size of the explore team and the resources available to them (including time). This encourages people to apply their creativity and focus on learning rather than pursuing “perfect” solutions. There are no awards for elegance of software design or automated test coverage in an MVP — the more skeletal, the better, provided we can gather the information we need. Many of the “war stories” exchanged by Lean Startup practitioners describe the ingenious shortcuts they took in the pursuit of validated learning.

It’s essential to distinguish between Taylor’s scientific management, discussed in Chapter 1, and the experimental approach we describe here. In scientific management, analysis is performed and decisions are taken by management, with the people who do the work functioning more or less as automatons. In the experimental approach, the job of leadership and management is to design, evolve, and operate a system in which the people doing the work have the necessary skills and resources to run their own experiments, thus individually and collectively learning, developing, and growing their knowledge.

As shown in Table 3-2, applying the scientific method to product development is fundamentally different from the traditional plan-based approach and requires different skills and behaviors. It is not that the traditional project lifecycle is bad — it can be effective in projects where the thing to be built has been built many times before and the risks are well understood. But traditional project management is the wrong model for conditions of uncertainty, such as new product development or any kind of custom software development.

The only assumption that always holds true is that no business plan survives first contact with customers.

It should not be a lagging metric such as return on investment (ROI) or customer churn, both of which measure output after the fact. Lagging indicators become interesting later when we have achieved a product/market fit. By initially focusing on leading metrics, we can get an indication of what is likely to happen — and address a situation quicker to try and change the outcomes going forward. For example, customer complaints are often a leading indicator of churn. If customer complaints are rising, we can expect that customers will leave and the churn will increase. Our OMTM should always evolve as we learn more about the problem we want to solve.

What is the problem we are trying to solve? Product development Are we attempting to create new products or services that involve customers? How will we know that we are engaging them and they are interested in our product? Tool selection Are we attempting to select a tool for using in the organization? How will we know that it is the best tool for the process? Process improvement Are we attempting to improve our internal capability and efficiency? How will we know if our changes are having the desired impact?

What stage of the process are we at? Problem validation Are we trying to identify that a problem exists by talking to people to see if they are experiencing the pain of the issue we’re trying to solve? Solution validation Are our people demonstrating alignment and buy-in for the problem we are aiming to solve through qualitative interviews? MVP validation Are we creating experiments to quantitatively prove that our solution is working to solve the problem we have identified?

How to Measure Anything, Douglas Hubbard recommends a good technique for deciding on a given measure: “If you can define the outcome you really want, give examples of it, and identify how those consequences are observable, then you can design measurements that will measure the outcomes that matter. The problem is that, if anything, managers were simply measuring what seemed simplest to measure (i.e., just what they currently knew how to measure), not what mattered most.”6

In the early stages, we must spend less time worrying about growth and focus on significant customer interaction. We may go so as far as to only acquire customers individually — too many customers too early can lead to a lack of focus and slow us down. We need to focus on finding passionate early adopters to continue to experiment and learn with. Then, we seek to engage similar customer segments to eventually “cross the chasm” to wider customer acquisition and adoption.

Once leaders see evidence of rampant growth with us operating with unscalable processes, we’ll easily be able to secure people, funding, and support to build robust solutions to handle the flow of demand. Our goal should to be to create a pull system for customers that want our product, service, or tools, not push a mandated, planned, and baked solution upon people that we must “sell” or require them to use.

In the early stage we are still learning, not earning. Therefore it is important that we do not limit our options by committing time, people, and investment to building features that may not produce the desired customer outcomes. We must accept that everything is an assumption to be tested, continually seek to identify our area of most uncertainty, and formulate experiments to learn more. To hedge our bets with this approach, leverage things that don’t scale — build a runway with scenarios for how we may continue to build out our product.

There are several frameworks that deal with scaling agile software development methods. In general, these frameworks take small teams practicing Scrum and add more structures on top to coordinate their work. However, these teams are still embedded within a phase-gate program and portfolio management process that is more or less unchanged from the traditional project management paradigm. They still apply top-down thinking and tend to batch up work into releases with long cycle times, thus limiting the use of the information collected to guide future decisions. Our approach differs in several important respects from these frameworks, as well as from more traditional phase-gate frameworks.

Implement an iterative continuous improvement process at the leadership level with concise, clearly specified outcomes to create alignment at scale, following the Principle of Mission. Work scientifically towards challenging goals, which will lead you to identifying and removing — or avoiding — no-value-add activity. Use continuous delivery to reduce the risk of releases, decrease cycle time, and make it economic to work in small batches. Evolve an architecture that supports loosely coupled customer-facing teams which have autonomy in how they work to achieve the program-level outcomes. Reduce batch sizes and take an experimental approach to the product development process. Increase and amplify feedback loops to make smaller, more frequent decisions based on the information we learn from performing our work to maximize customer value.

The researchers concluded that to achieve high performance, companies that rely on software should focus first and foremost on their ability to execute, build reliable systems, and work to continually reduce complexity. Only then will pursuing alignment with business priorities pay off.

People need to understand that they must always be working towards the vision and that they will never be done with improvement. We will encounter problems as we move towards the vision. The trick is to treat them as obstacles to be removed through experimentation, rather than objections to experimentation and change.

Each day, people in the team go through answering the following five questions:8 What is the target condition? What is the actual condition now? What obstacles do you think are preventing you from reaching the target condition? Which one are you addressing now? What is your next step? (Start of PDCA cycle.) What do you expect? When can we go and see what we learned from taking that step?

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.

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

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.4 For each process block within the value stream, we record the activity and the name of the team or function that performs it.

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.

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.

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.

Despite the name, continuous delivery is not about deploying to production multiple times a day. The goal of continuous delivery is to make it safe and economic to work in small batches. This in turn leads to shorter lead times, higher quality, and lower costs.

Test automation is emphatically not about reducing the number of testers — but test automation does change the role and the skills required of testers. Testers should be focused on exploratory testing and working with developers to create and curate suites of automated tests, not on manual regression testing.

It is impossible to evolve high-quality automated test suites unless testers collaborate with developers in person (irrespective of team or reporting structures). Creating maintainable suites of automated tests requires strong knowledge of software development. It also requires that the software be designed with test automation in mind, which is impossible when developers aren’t involved in testing.

Test automation can become a maintenance nightmare if automated test suites are not effectively curated. A small number of tests that run fast and reliably detect bugs is better than a large number of tests that are flaky ...

However, we should not be optimizing for the rate at which we declare things “done” in isolation on a branch. We should optimize for the overall lead time — the time it takes us to deliver valuable software to users. Optimizing for “dev complete” time is precisely what causes “integration hell.” A painful and unpredictable “last mile” of integration and testing, in turn, perpetuates the long release cycles that are a major factor in project overruns, poor quality software, higher overall costs, and dissatisfied users.

Often, these two terms are treated as synonyms — that is, we use deployment as our primary mechanism for performing releases. This has a very serious negative consequence: it couples the technical decision to deploy to the business decision to release. This is a major reason why organizational politics gets injected into the deployment process, to the detriment of all.

Enormous, overly complex systems and burned-out staff are symptoms of focusing on output rather than outcomes.