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

by Jez Humble

As Deloitte’s Shift Index shows, the average life expectancy of a Fortune 500 company has declined from around 75 years half a century ago to less than 15 years today.

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.

we rely on people being able to make local decisions that are sound at a strategic level — which, in turn, relies critically on the flow of information, including feedback loops.

I would recommend this organization as a good place to work. I have the tools and resources to do my job well. I am satisfied with my job. My job makes good use of my skills and abilities.

Thus the survey asked people to assess their team culture along each of the axes of Westrum’s model as shown in Table 1-1, by asking them to rate the extent to which they agreed with statements such as “On my team, failure causes enquiry.”10 In this way, the survey was able to measure culture.

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.

friction creates three gaps. First, a knowledge gap arises when we engage in planning or acting due to the necessarily imperfect state of the information we have to hand, and our need to making assumptions and interpret that information. Second, an alignment gap is the result of people failing to do things as planned, perhaps due to conflicting priorities, misunderstandings, or simply someone forgetting or ignoring some element of the plan. Finally, there is an effects gap due to unpredictable changes in the environment, perhaps caused by other actors, or unexpected side effects producing outcomes that differ from those we anticipated.

“When we decided to do a microprocessor, in hindsight, I think I made two great decisions. I trusted the team, and gave them two things that Intel and Motorola had never given their people: the first was no money and the second was no people. They had to keep it simple.”

Finally, because the project approach judges people according to whether work is completed on time and on budget, not based on the value delivered to customers, productivity gets measured based on output rather than outcomes.

Thus the business case essentially becomes a science fiction novel based in an universe that is poorly understood — or which may not even exist!

Applying them continuously means doing it as often as possible (as Mike Roberts says, “Continuous means much more often than you think”), with a focus on getting through the loop in the shortest possible time.

The Invincible continuously self-disrupt while their business models are still successful (e.g., Apple, Amazon).

Confusingly, people often refer to any validation activity anywhere along on this spectrum as an MVP, overloading the term and understanding of it in the organization or wider industry.

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.

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

Continuous delivery is the ability to get changes — experiments, features, configuration changes, bug fixes — into production or into the hands of users safely and quickly in a sustainable way.

The most important principle for doing low-risk releases is this: decouple deployment and release.

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

One way to apply Conway’s Law is to align API boundaries with team boundaries.

Amazon did not replace their monolithic Obidos architecture in a “big bang” replacement program. Instead, they moved to a service-oriented architecture incrementally, while continuing to deliver new functionality, using a pattern known as the “strangler application.” As described by Martin Fowler, the pattern involves gradual replacement of a system by implementing new features in a new application that is loosely coupled to the existing system, porting existing functionality from the original application only where necessary.

Do not attempt to port existing functionality unless it is to support a business process change The biggest mistake people make is porting existing features over as-is. This generally means reproducing complexity created to serve business processes as they looked years ago, which is enormously wasteful. Whenever you are asked to add a feature which represents a change to a business process, go and observe the process from scratch and look for ways to simplify it before implementing the code to support it. You will find that much accidental complexity in business processes actually comes from being forced to use the old software you are replacing!

You know, I’m all for progress. It’s change I object to. Mark Twain

Karen E. Watkins and Victoria J. Marsick developed the Dimensions of the Learning Organization Questionnaire (DLOQ), which has been extensively studied in the academic literature. You can take the questionnaire for free at http://www.partnersforlearning.com/instructions.html.

Gallup’s Q12 survey asks what they believe are “the only 12 questions that matter” to measure employee engagement. You can find the questions, along with more information, at http://q12.gallup.com/.

What changed the culture was giving employees the means by which they could successfully do their jobs.

It’s a widely held belief that there is an order-of-magnitude difference between the best and the worst engineers.21 In reality, the 10x figure is (to put it mildly) “poorly supported by empirical evidence.”

As W. Edwards Deming noted, “A bad system will beat a good person every single time.”

Dweck’s work shows that if we reward people for the effort they put into solving problems that they find challenging, it shifts them towards a growth mindset. If, in contrast, we praise and reward people for their ability to deploy their existing skills, we create a fixed mindset.

Implicit bias doesn’t just play a role in recruiting — it pervades the corporate environment. To take just one example, women are much more likely to receive critical feedback in performance reviews (the word “abrasive” is almost exclusively used in feedback to women).

Good GRC management maintains a balance between implementing enough control to prevent bad things from happening and allowing creativity and experimentation to continuously improve the value delivered to stakeholders.

A budget should be viewed as the total sum of funds set aside, or needed, for a purpose: “What is the ceiling for how much we may spend on this activity?” It does not define what we are actually going to do — that is strategy. It is not a plan for how to achieve the strategy, nor does it forecast or measure our success in delivering value to customers.

The use of the traditional annual fiscal cycle to determine resource allocation encourages a culture that thwarts our ability to experiment and innovate. It perpetuates spending on wasteful activities and ideas that are unlikely to deliver value.

Meanwhile, many companies that claim to have implemented “private clouds” still require engineers to raise tickets to request test and production environments, and take days or weeks to provision them.

Any cloud implementation project not resulting in engineers being able to self-service environments or deployments instantly on demand using an API must be considered a failure.