Lean Enterprise: How High Performance Organizations Innovate at Scale By Jez Humble, Joanne Molesky, and Barry O’Reilly
Software has three characteristics which enable this kind of rapid innovation. First, it’s relatively inexpensive to prototype and evolve ideas in software. Second, we can actually use such prototypes from an early stage in their evolution. Finally, in the course of creating these prototypes, we can discover a great deal about what customers find valuable and incorporate it back into our design — accelerating the rate at which we can test new ideas with users, collect feedback, and use it to improve our products and businesses.
The business world is moving from treating IT as a utility that improves internal operations to using rapid software- and technology-powered innovation cycles as a competitive advantage.
The traditional program and project management models we have used for IT are unsuited to rapid innovation cycles.
In most cases it was impossible to realize anything more than incremental improvements because only part of the organization changed — and that part still needed to work with the rest of the organization, which expected them to behave in the traditional way.
Do not turn obstacles into objections.
the most common failure mode for such organizations is their inability to change their organizational culture, not the availability of good tools.
Creating, updating, and communicating the company’s purpose is the responsibility of the enterprise’s executives.
Giving people pride in their work rather than trying to motivate them with carrots and sticks is an essential element of a high-performance culture.
The key to creating a lean enterprise is to enable those doing the work to solve their customers’ problems in a way that is aligned with the strategy of the wider organization.
The results are clear: a high-trust, generative culture is not only important for creating a safe working environment — it is the foundation of creating a high-performance organization.
“The higher the level of command, the shorter and more general the orders should be.
According to the Principle of Mission, we create alignment not by making a detailed plan of how we achieve our objective but by describing the intent of our mission and communicating why we are undertaking it
The long-term value of an enterprise is not captured by the value of its products and intellectual property but rather by its ability to continuously increase the value it provides to customers — and to create new customers — through innovation
Skeptics often treat size, regulation, perceived complexity, legacy technology, or some other special characteristic of the domain in which they operate as a barrier to change. The purpose of this chapter is to show that while these obstacles are indeed challenges, the most serious barrier is to be found in organizational culture, leadership, and strategy
Limiting initial investment and creating resource scarcity is essential to managing the risk of innovation
Given that most innovative ideas we have will not succeed, we must come up with simple, quick experiments to eliminate bad ideas rapidly and cheaply
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
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
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
John Seddon, author of Freedom from Command & Control (Productivity Press), states that “dysfunctional behavior is ubiquitous and systemic, not because people are wicked, but because the requirement to serve the hierarchy competes with the requirement to serve customers…people’s ingenuity is engaged in survival, not improvement.
We then aim to stop starting work and start finishing it as soon as possible
Ensure people are rewarded for favoring a long-view system-level perspective over pursuing short-term functional goals
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 fo
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
Improvement Kata described in Chapter 6. That is what allows an organization to adapt rapidly to its changing environment. Toyota calls this “building people before building cars.
Discovery is a rapid, time-boxed, iterative set of activities that integrates the practices and principles of design thinking and Lean Startup
“Design thinking takes a solution-focused approach to problem solving, working collaboratively to iterate an endless, shifting path toward perfection. It works towards product goals via specific ideation, prototyping, implementation, and learning steps to bring the appropriate solution to light.
During Discovery, we create a collaborative and inclusive environment for a small cross-functional, multidisciplinary team to explore a business, product, or improvement opportunity. The team should be fully dedicated and co-located to maximize the speed of learning and the effectiveness of real-time decision making. It must assume ownership of delivery and be empowered to make the necessary decisions to meet the objectives of the initiative
When forming a team, it is key to keep the group small, including only the competencies required to explore the problem domain. Large teams are ill-equipped for rapid exploration and cannot learn at the speed required to be successful. The group must know their limitations and boundaries, taking responsibility to reach out and engage others outside the group for input and collaboration when appropriate
Based on the new information they are discovering, people learn, change, and improve when they are involved in a process that is energizing, interactive, and adaptive
First, success requires a shared sense of purpose in the entire team. The vision needs to be challenging enough for the group to have something to aspire to, but clear enough so that everyone can understand what they need to do. Second, people must be empowered by their leaders to work autonomously to achieve the team objectives. Finally, people need the space and opportunity to master their discipline, not just to learn how to achieve “good enough.
The quality of a problem statement increases our team’s ability to focus on what really matters — and, more importantly, ignore what does not
We start exploration with divergent thinking exercises designed to generate multiple ideas for discussion and debate. We then use convergent thinking to identify a possible solution to the problem
People who cannot temporarily let go of their role and status, or set aside their own expertise and opinions, will fail to develop empathy with others’ conflicting thoughts, experiences, or mental models. The ability to listen and ask the right questions becomes a powerful skill, and the insights it brings are the foundation of effective problem solving and experimentation
Remember, metrics are meant to hurt — not to make us feel like we are winning. They must be actionable and trigger a change in our behavior or understanding
We must adopt the mindset in which all our ideas are hypotheses based on assumptions that must be tested, and that most of these assumptions will be proved wrong
It is not enough to do your best; you must know what to do, and then do your best. W. Edwards Demin
“If you have a piece of data on which you cannot act, it’s a vanity metric…A good metric changes the way you behave. This is by far the most important criterion for a metric: what will you do differently based on changes in the metric?
“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.
Innovation in large, bureaucratic organizations is challenging because they are inherently designed to support stability, compliance, and precedence over risk taking
Remember, reaching big numbers is not a big win; meeting unmet needs and delighting customers is
Features delivered are not a measure of success, business outcomes are
We will (as Martin Fowler puts it) deliberately and prudently accumulate technical debt in order to run experiments and get validation
The moment a product (if we are in Horizon 3) or feature (in Horizon 2) goes from being an experiment to validated, we need to start aggressively paying down technical debt
Lean operations emphasizes standardization and reduction of waste, uncertainty, and variation in order to create efficient processes that produce consistent, quality products. In contrast, lean development utilizes uncertainty and variation early in the design process to learn from experiments, especially from failures — which is the most effective way to solve problems and drive innovation
We do not need to build requirements; we need to answer questions about the desired functionality of our product
If people are punished for failing to meet targets or metrics, one of the fallouts is that they start manipulating work and information to look like they are meeting the targets
High-performance organizations are constantly evolving to adapt to their environment, and they do so in an organic way, not through command and control
Do you know how much time your engineering organization is spending on no-value-add activities and servicing failure demand versus serving value demand, and what the major sources of waste are
There is nothing so useless as doing efficiently that which should not be done at all. Peter Drucke
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.
It’s important for participants in this exercise to be bold and consider radical change (kaikaku)
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
Auditors love the deployment pipeline because it allows them to track every detail of exactly which commands were run on which boxes, what the results were, who approved them and when, and so forth
Deployment is the installation of a given version of a piece of software to a given environment. The decision to perform a deployment — including to production — should be a purely technical one
Release is the process of making a feature, or a set of features, available to customers. Release should be a purely business decision
Enormous, overly complex systems and burned-out staff are symptoms of focusing on output rather than outcomes
Gojko Adzic presents a technique called impact mapping to break down high-level business goals at the program level into testable hypotheses
One of the most common challenges encountered in software development is the focus of teams, product managers, and organizations on managing cost rather than value. This typically manifests itself in undue effort spent on zero-value-add activities such as detailed upfront analysis, estimation, scope management, and backlog grooming. These symptoms are the result of focusing on maximizing utilization (keeping our expensive people busy) and output (measuring their work product) — instead of focusing on outcomes, minimizing the output required to achieve them, and reducing lead times to get fast feedback on our decisions
Management through process control is acceptable in certain contexts within manufacturing processes (the kind of systems for which Six Sigma makes sense), but not in product development — where its result is optimizing for efficiency and predictability at the expense of innovation and ability to adapt to changing conditions
Amazon stipulated that all teams must conform to the “two pizza” rule: they should be small enough that two pizzas can feed the whole team — usually about 5 to 10 people
by default, decisions should be made by the people who are directly affected by those decisions
As Reed Hastings says, our goal is to create teams that are highly aligned but loosely coupled
Give teams the tools and authority to push changes to productio
Ensure that teams have the people they need to design, run, and evolve experiment
Ensure that teams have the authority to choose the their own toolchai
Figure 10-2. Product teams working together, with a service layer for performing deployment
Typically, this is achieved by using the “vertical slice” approach in which we build small increments of functionality end-to-end across the whole technology stack
and by rapid, we mean hours or days — to create hypotheses, test, and learn from the results