Introduction

I read the book “Lean Enterprise - How high performance organizations innovate at scale” by Jez Humble, Joanne Molesky and Barry O’Reilly a while ago in its 2016 edition. After coming back to the book about 2 years later and still thinking the content is hugely relevant, I thought it might be a good idea to summarize the main ideas and present you some of the quotes I consider relevant, exciting or especially controversial. With some of them at hand, you should be well prepared for the next discussion on the matter over a couple of beers with your CTO friends.

Structure of the book (and the review)

The authors split their book into four parts. A first part called orient that introduces some general ideas of lean and its roots. An argument is made that different phases of products require different methodologies to manage them. Namely they divide into the early exploration phase and the later exploitation phase, so consequently the main part of the book is split into the two parts explore and exploit. A fourth part called transform focuses on how to bring the theories of the book into practice in existing organizations.

Fundamental ideas of the book (Part I - Orient)

Like every other lean book out there, the book introduces some basics around lean thinking and its sometimes counter-intuitive logic that makes it particularly hard to explain to your peers that are still sticking to more traditional ways of reasoning about organizations.

“Research has shown that focusing only on maximising profits has the paradoxical effect of reducing the rate of return on investment.” (p. 2)

The main clash between the two worlds of “old thinking” versus “new thinking” is shown by comparing a “Taylorist world view” versus the world view of the Toyota Production System (TPS). In short, Taylorism thinks that an organization works like a machine and can be broken down into its bits and pieces. Understanding and analyzing each bit and piece would hence lead to a proper understanding of the whole organization. This leaves Taylorists with an understanding that each person in the organization is merely a small cog, “paid simply to perform preplanned actions as quickly as possible”. In contrast to this, the lean view of the world thinks of organizations as complex human systems that cannot be understood by analyzing its parts only. Instead, lean thinking focuses on creating high trust cultures, close collaboration between managers and workers and constant improvement processes on every level of the organization, requiring workers to pursue mastery during that process rather than taking orders and not think.

“Although the principles at the heart of the TPS might seem relatively straightforward, they were very hard to adopt.” (p. 7)

People trying to implement this thought often focus too much on a specific set of tools (like Scrum, Kanban boards, stand-ups,. etc). “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.”

Instead the book suggests to enable those doing the work to solve their customers’ problems in order to get to a lean enterprise. The goal needs to be to enable the workers to do this while their actions stay aligned with the strategy of the whole organization. That requires local decisions that are in line with the global strategy.

“Even today, many people think that Lean is a management-led activity and that is’s about simpy cutting costs. In reality, it requires investing to remove waste and >reduce failure demand - it is a worker-led activity that, ultimately, can continously drive down costs and improve quality and productivity”

A way to accomplish this alignment is seen in the principle of Mission command. The idea behind Mission Command is not to create detailled plans of action that are often used in a Command and Control environment, but rather to make sure everyone is understanding the fundamental goals and strategies. It’s suggested that “The higher the level of command, the shorter and more general the orders should be”. For this to work it is crucial that people in the organization are ready to accept a higher degree of responsibility and that mistakes that are made in good faith are tolerated, not sanctioned.

The link to the Enterprise Product Portfolio

The book refers to the famous technology adoption lifecycle by Everett Rogers (I won’t go into detail here). The main idea here is, that “exploring new opportunities and exploiting existing ones are fundamentally different strategies requiring different structure, competences, process and mindset.”

For exploration the book suggests: - A radical or disruptive innovation strategy and search for new business models - A small, cross-functional, multi-skilled team - A culture of experimentation, risk taking, acceptance of failure, focus on learning

For exploitation in contrast: - An incremental innovation strategy and optimizations of the business model - Multiple teams aligned with the “Principle of Mission” - A culture of incremental improvements, optimization and relentness focus on quality and customer satisfaction

“Startups that discover a successful business model and cross the chasm often find it hard to transition into the next stage: executing and scaling in a growth market. >Meanwhile, organizations that succeed in transforming themselves into engines of execution often lose their ability to explore new business models.”

Balancing the Enterprise Product Portfolio

The book suggests to use three different planning horizons:

• Horizon 1 (0-12m): Current business, generates cash today
• Horizon 2 (12-36m): High growth business
• Horizon 3 (36-72m): Growth options

Every horizon needs a different kind of management: Horizon 2 covered in the EXPLOIT sectoin, Horizon 3 in the EXPLORE section.

Explore (Part II)

The key take-away for me is, that all the traditional ways of setting up big, planning heavy projects for products in the Explore stage is bound to fail. So whenever uncertainty is very high, the methods from this chapter are worth a closer look.

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

So, in order to properly explore the problem space, the book suggests to not “commence a major program to solve the problem or pursue the opportunity until” the folling things have been completed: - A clear definition of a measurable business outcome has been achieved - The smallest possible prototype capable of demonstrating measureable progress towards that coutcome has been built - It has been demonstrated that the proposed solution actually provides value to the audience it has been designed for

The book strongly opts to not waste too much energy on detailled business planning (because it provides “large amounts of information with extremely limited value”). Instead, focus on the key risks and evaluate those and use a light-weight tool like the business model canvas for business modelling.

“The most inefficient way to test a business model or product idea is to plan an build a complete produt to see whether the predicted market for it really exists. Yet >this is exactly what we do once we have an approved business case.”

The book makes a strong statement on requirements in product development: The word requirements should be eliminated from the world of (non-trivial) product features and replaced with hypothesis.

Instead, it’s recommended to do the following: - Setup a team with limited resources available (including time!) - Gather information to see if you have a problem worth solving and people who want to pay for it - Then, design a MVP - an experiment designed to maximize learning from potential early adopters with minimum effort.

“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 the measurement. The purpose of measurement is not to gain certainty, but to reduce uncertainty.”

The authors reach out the hand to more classical project approaches here by stating that the traditional way of setting projects up is not bad in itself. It can be successful for projects that contain only very little uncertainty, e.g. because they have been executed several times before in exactly the same manner. (Custom) Software development, however, by its nature is different in this regard and ususally heavy on the exploration side. The fundamental question though should be “should be build it?” rather than “can we build it?”.

Create a shared understanding for the exploration endeavour

“When you want to build a ship, do not begin by gathering wood or cutting boards. But awaken within the heart of man the desire for the vast and endless sea.”

The book references Dank Pink’s work on team engagement and motivation. Pink, in a nutshell, says that three elements are needed for highly engaged and highly motivated teams: 1) A shared sense of purpose 2) People must be empowered by their leaders to work autonomously 3) People need space and opportunity to master their discipline

Accelerate Experimentation with MVPs

There is a lot of discussion and a wide range of interpretations about what an MVP really is. The book gives a definition: An MVP is seen as the smallest possible product that has three (plus one) critical characteristics: - People can choose to use it or buy it (valuable) - People can figure out how to use it (usable) - We can deliver it when we need it with the resources available (feasible) - It is “delightful” to use

So for example, the MVP could have the form of a concierge service, a “wizard of oz” application (where the frontend is functional but everything in the back is mocked) or a micro-product.

Engineering practices for exploring

There is a clear tension between the need to rapidly build MVPs and the engineering craftsmanship understanding of building software at high levels of quality using practices like e.g test-driven development. MVPs require to deliberately choose to accumulate technical debt in order to be fast to run experiments. Two practices in engineering are recommended to apply nevertheless: - Continuous integration, and - A small number of unit tests / user-journey tests

Exploit (Part III)

Products in the exploit phase already have signifikant traction and a prooven product/market fit. Thus, the methods shift away from the exploration model and more towards incremental thinking and a continuous improvement process.

Most important for the continuous improvement process is implementing it at the senior leadership level first and use it there to drive the evolution of both, the organization itself and the processes in use. Only after this, it can be successfully used throughout the whole organization.

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

The other key elements of the exploit phase are: - Working scientifically towards challenging goals, which will lead you to identifying and removing no-value-add activity - Useing continuous delivery to reduce risk of releases, decrease cycle time and make it economic to work in small batches - Architecture that supports loosely coupled, customer-facing teams with autonomy in how they achieve their outcomes - Reduce batch sizes and take an experimental approach to product development - Increase and amplify feedback loops to make smaller, more frequent and fast decisions

The book spends quite a bit on explaining how an improvement process can be run, using the example of Toyota’s “Improvement Kata”. It provides a structured way of approaching improvements and consists of basically 4 steps: 1) Understand the Challenge (Planning phase) 2) Grasp the current condition (Planning phase) 3) Estabiish the next target condition (Planning phase) 4) Iterate toward the target condition (Execution phase)

There is a lot of literature on the process, so I will skip deails here. Remarkably:

“In Toyota, one of the main tasks of managers is to teach the Improvement Kata pattern to their teams and to facilitate running it.”

Identify Value and Increase Flow

It seems like an obvious statement to say, that an organization should only work on things that really provide value. Doing efficiently what does not need to be done at all is a classical example of waste. Lean thinking provides a set of five principles to actually achieve that in an organization: - 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 product - Pursue perfection

Tools that can help to understand where a problem starts are e.g. a technique called value stream mapping.

“While everybody has an intuitive grasp that enterprise value streams are inefficient, seeing the whole value stream from idea to measureable customer outcome often >reveals staggering amounts of waste”

A practial tip refers to too much work in progress (WIP): “In enterprises, one indicator of too much WIP is the number of people assigned to more than one project.”

Cost of delay as an alternative approach to business value

To book introduces a methodology of calucluating “cost of delay” rather than business value of new features. The authors claim that it is easier in a decentralized environment to decide about what to delay instead of what to prioritize.

“By calculating cost of delay for each feature, wo no longer rely solely on a product owner to estimate the business value for the stories in the backlog. (..) Instead, given that we have limited capacity, we think of prioritization as choosing what to delay.”

For those of you not fully convinced that this is the same thing as your business value estimates: I found that too, but it kind of makes sense to add a time dimension to the value something creates (or does not create if it’s delayed). But it still stays equally hard to calculate dollar amounts for delay. A good hint is that whenever the uncertainty about the dollars is too high, consider whether you are really still in the exploit domain - or whether you should switch over to explore methods again.

Adopt lean engineering practices

Clearly, in this model the capability to innovate relies on the ability to frequently run experiments/tests with real users. So the speed with which new software can be deployed and tested is a clear competitive advantage. Engineering practices should support this. A central one named here is continuous delivery.

“The goal of continuous delivery is to make it safe and economic to work in small batches”

The book cites two “golden rules of continous delivery”: 1. The team is not allowed to say they are “done” with any piece of work until their code is in trunk on version control and releasable 2. The team must prioritize keeping the system in a deployable state over doing new work.

Take an experimental approach to product development

The central message is: Make sure to build the right things and *focus on outcomes rather than output”. This is tricky, as humans seem to have an “almost irresistible tendency” to speciy the way to a certain result rather than the result itself.

This, solutions to problems should never be proposed on a program / portfolio level. Rather it should be up to the teams within the program to decicde how they will achieve those results. This is critical for two reasons: - The initial solutions we come up with are unlikely to be the best - Organizations can only move fast at scale when the people building the solutions have a deep understanding of both user needs and business strategy and come up with their own ideas

A program (product portfolio) level backlog is not an effective way to drive these behaviours

A concrete technique to be used here instead of feature backlogs on program level is impact mapping. Impact mapping always begins with a program-level target condition. Then it works its way down to first identify all relevant stakeholders, describes possible ways how stakeholders could help and only then proposes options how to achieve the target conditions.

Performing User Research

Moving away from requirements towards hypotheses is key to successful user research.

A good hypothesis looks like this:

“We believe that building this feature for these people will achieve this outcome. We will know we are successful when we see this signal from the market.”

No major new development work should be undertaken before a hypothesis has been created so it can be determined if the work delivered the expected value. This is a key difference to classical project management, where usually output is measured and not outcome/value creation. “By focusing on the outcomes we wish to achieve, rather than solutions and features, we can separate what we are trying to do from the possible ways to do it”.

Part IV - Transform

The last part of the book speaks about how to implement lean thinking in your organization. It touches on some interesting areas like how accounting influences product development and how to deal with regulatory requirements. The single most important idea from the last paragraph for me however was the idea about the right mindeset.

The authors divide between a fixed mindset and a growth mindset. A fixed mindset is characterized by an attitude of avoiding challenges, easily giving up on obstacles, ignorant or in fear of feedback and threatened by the success of others. While a growth mindset embraces challenges, grows with the effort needed, learns from feedback and finds inspiration in the success of others.

Achieving a growth mindset within the organization is key to a lot of ways of thinking and working presented in the book. And there even seems to be evidence on how such a mindset can be created:

“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, incontrast, we praise and reward people for their ability to deploy their existing skills, we create a fixed mindset.”

Conclusion

For me, the concepts in the book make great sense. If you have read up to here and ended up with more questions than ansers in your mind, it’s probably the right time to go an get your own copy of the book :)