Q&A on the Book The Pragmatist's Guide to Corporate Lean Strategy

The book The Pragmatist's Guide to Corporate Lean Strategyby Michael Nirexplores how to practically adopt lean enterprise and lean startup concepts to turn your company into a lean agile enterprise promoting business agility. It provides examples from companies that have applied these concepts, describes the strategy, best practices, anti-patterns, and gives insights into lean and agile transformations.

InfoQ readers can download a sample of the book:  

Cadence is King - Chapter from Pragmatist Guide to Corporate Lean Strategy. 

InfoQ interviewed Nir about what makes it difficult for large organizations to focus on customers and how to overcome this, how large organizations can apply lean startup concepts, how organizations can apply a framework for adopting lean, and how to deal with the main challenges of lean agile transformations.

InfoQ: What made you decide to write this book?

Michael Nir: Last summer InfoQ interviewed me about Rethinking Lean Startup at a Big Corporate. At that time I was working with several clients rolling out lean startup and promoting business agility. At these transformations I encountered recurring anti patterns in how organizations, especially big ones, implement agile, lean, design thinking and then try to scale it all together. The culprit is not the specific method or approach; the underlying concepts are solid. Rather, it is orchestrating the overall strategy and achieving the business impact and value that is missing. Thus, Agile is relegated to software and product, Scrum tends to be even more local; Kanban is an OPS thing, DEVOPS uses jargon hardly any business person understands, Lean UX and design thinking never cross UX boundaries; Innovation labs and user centered design workshops are failing to integrate into product development, on top of which scaling efforts limit themselves as well to local optimization. In this wildly fragmented landscape it is difficult to truly impact the customer and create true business value.  I find that lean startup provides the comprehensive holistic and overarching engine for value driven growth. It is the ultimate driver for business agility. 

In the book, I share the good, the bad, and the ugly of enterprise-level adoption of lean startup practices (what we call a “lean corporation”). I provide step-by-step instructions specifically targeted to technologists in multiple roles. Building experience on Steve Blank and Eric Ries’ “lean startup” framework, this book takes these concepts to the next level by providing best practice guidelines, sharing “horror stories” and common anti-patterns in a fun and engaging way.

InfoQ: For whom is the book intended?

Nir: The book is intended for a broad audience - those in engineering, product development, technology and business management interested in strategy, business agility, lean management, execution, and emerging technologies. It takes a broad yet in depth view of contemporary advances in entrepreneurial management and leadership. It focuses on the organizational change necessary for enterprises facing market disruption.

I had some great endorsements for it already by well known individuals, together with blunt and harsh criticism from others, also well known individuals. Naturally I disliked the criticism, yet I have to agree that the book is not an introduction guide to agile, scrum or lean. I skip the basics and assume my smart readers are versed in many of the existing approaches to agile and lean, or can look these up on their own. My approach is sometimes associative, and I find it difficult to limit my writing to text book style writing. Hence, the book is intended for smart readers :-)

InfoQ: What makes it difficult for large organizations to focus on customers?

Nir: First and foremost, they’ve been in business for years, they make money, and they are comfortable within the confines of the organization; they don’t feel the need to interact with a consumer. Going outside of the office and actually asking a customer what they want is something they just don’t do. The concept of gemba is foreign to them. Most of them are convinced that they are not allowed to do it, that it’s the job of others to interact with consumers. The same is true for developing solutions for internal consumers; the prevailing mindset is “it’s not our job to ask questions.”

Inside-out thinking is a recurring challenge for enterprises. For example, traditional insurance companies focus on making it hard for the consumer to receive their money when submitting a claim. This isn’t a specific hurdle but rather a mindset of the insurance company around which many of the internal automated processes are built. They make it hard to issue a claim, they make it difficult to get support on the status of the claim, they instill an internal mindset in which the consumer is dishonest, they follow through with slow response to consumer requests, they require paper and fax be used rather than email (blaming regulation); the list goes on and on.

The story about the VP of product at a big financial business who told me, “but I have a detailed survey of my customers” when explaining his decision to offer 11 web pages full of 121 product variants, never gets old.

Can it be any different? Check out what disruptor insurance providers are doing.

InfoQ: What can be done to overcome this?

Nir: Implementing outside-in thinking in these organizations is more than a well designed exercise in creating a persona - which is often how organizations start with human centric design - it’s a nice to have - but the wrong first step. 

Rather, it is an ongoing battle to break free from the prevailing mindset of “the consumer is our enemy” and “there’s a zero sum game between us and the consumer” to embracing collaboration with the consumer. Having executives participate in sessions with real people as part of structuring the persona has a tremendous impact and leads to true empathy; the outside-in thinking usually follows.

In many cases, there is an assumption that people who create software and products know what their customers actually need. There are two problems with that: the first is assuming that there is a single homogenous customer type. There never is. There are multiple customers with conflicting demands and preferences, so it is important to identify their types and make decisions about who your customers actually are. Second, you can’t know what the customers need until you talk to them and ideally give them a prototype to try out and provide feedback on. Fall in love with the problem, not a solution. It is only through empathy and trial and failure that you can get practical feedback from your customer, not by imposing the proposed solutions and hoping that they will resonate with the customers. 

InfoQ: How can large organizations apply lean startup concepts?

Nir: In the book, the first part is named: Five Lessons from Lean Startup Thinking. I detail the lessons I learned from application of Agile and Scrum,Scaled Agile, Lean startup, Design Thinking, Lean UX,DEVOPS, Four Disciplines of Execution and more. 

The five lean startup lessons are:

• Start with the customer in mind
• Define and communicate the mission and vision
• Synthesize an integrative operating model
• Identify metrics that matter
• Pivot or persevere

When my team tried to implement these concepts we ran into the proverbial road blocks and developed work-arounds that I share in the book.

In my opinion the most important step for big organizations to succeed with applying lean enterprise concepts is by Synthesizing an integrative operating model, otherwise they will fail.

In fact, The organizations I helped create a lean enterprise engine already had a myriad of frameworks in place. Many were using agile as a delivery method, on top of which they implemented a scaled agile delivery to manage multiple delivery teams. In an internal system transformation at a Fortune 100 insurance company, they called their scaled agile delivery mechanism “the factory” and each delivery team used scrum to manage itself. At the same enterprise, they had UX experts and a Lean UX delivery team that had its own development resources. In addition, there was an ongoing DEVOPS effort to enable faster delivery of results across operations.

This familiar landscape exemplifies the well-known silos that impede the benefits that supposedly emerge from the various frameworks. I experienced agile and Lean UX initiatives that impacted parts of the organization without improving overall business outcomes. I knew that we had to take a different approach when creating a lean enterprise engine; otherwise it would become another failed improvement effort. The challenge we had was that lean startup discusses a vision of entrepreneurship but fails to provide a guiding framework of how to get there. Both books by Ries are visionary and insightful, yet they do not offer the valuable steps to getting the system up and running. Q&A with Infoq - Eric Ries The Startup Way.

We must identify the holistic delivery approach and where our various improvement initiatives fit in it! 

To be successful, we must articulate the lean engine and its relationship to the existing frameworks.

The feedback loop between product or service development and the customer must be identified, silos have to be removed, and impact-based delivery metrics put in place.

Speaking of metrics - many agile transformations embrace team velocity as one of the three top metrics, and promise executives an ongoing improvement of velocity. One may ask why velocity is the wrong metric. Focusing on velocity as a metric is similar to focusing on output rate in production; it is a wrong metric to measure and celebrate. However since it is so easy to measure, organizations prefer to focus on it rather than explore leading metrics that are impactful.

InfoQ: How can we find out sooner if we should persevere or pivot with a new product?

Nir: Metrics, Metrics and metrics! See for example an interview with InfoQ about metrics for team - Conduct Objectives for High Performance Teams. All of us have been part of projects that have failed. My pet peeve is that someone will say at some point - at least we learned something.

It reminds me of the movie: Burn After Reading by the Coen brothers. The last scene shows a CIA executive asking his subordinate, “what have we learned from the debacle?”, to which he answers, “I don’t know”. The senior then says, “well we know not to do it again - but I don’t really know what we did…”

Always start by identifying what the behaviour or learning that you’re expecting is - define the assumption and the hypothesis; only then create the solution and offer it to customers - both internal and external- evidence based methods!

InfoQ: What can large organizations do to integrate a mechanism for pivoting into their operating model?

Nir: While startups can pivot themselves on a daily basis, in bigger businesses we learned we had to integrate the concept of the pivot into the operating model.  We had to explain to the organization the accepted amount of pivots in a certain time frame; in other words, how many pivots were allowed in a given timeframe.  We found that the concepts of a pivot were not necessarily foreign to the portfolio management team and the program management office. 

Traditional product development frameworks introduce phase gates to support a GO/NO GO decision at various intervals of the development process. In practice though, these become mere administrative hurdles to overcome as the project or program progresses towards completion and the product is released to the market. Often the phase gates involve only a review of documentation, rather than evidence based feedback to a working model of the product. 

This is where pivoting provides a different framework than the traditional phase gate approach. 

The decision to pivot must be based on empirical validation evidence (relevant lead-impact metrics). 

This evidence is collected from real consumers (representing the selected persona) who interact with a partial solution - an MVP. The MVP integrates important and uncertain assumptions that we identified enabling us to measure true alignment with our vision. These pivot decisions are in line with our vision and mission to deliver the right products and features that would delight our customers. 

The framework brings together concepts from various schools of thought - thus it is crucial to Synthesize an Integrative Operating Model. Otherwise pivoting, which is at the heart of a successful lean enterprise implementation, will not be truly accepted as an option and will be viewed as a failure rather than as validated learning.

Make pivoting a celebrated event. Bigger organizations are reluctant to pivot and see a pivot as a threat. So lower the danger, reduce the impact, and demonstrate the benefits of the pivot.

InfoQ: Your book provides a framework for adopting lean. What does it look like?

Nir: I discuss five techniques to succeed, progress, and change, along with the implementation timeline:

• Define the mission
• Identify customer personas
• Implement the prototype MVP and program training
• Run experiments with customers to validate your hypotheses
• Pivot or persevere in a build-measure-learn cycle

I develop a daily schedule that includes the above five techniques to succeed and their focus in the implementation timeline of the first 30 days, the first 90 days, and the first 12 months.

While my initial approach was that of a framework-by-framework analysis of tools and techniques to succeed, I felt that synthesizing the information from the day-in-the-life perspective would provide a comprehensive map of the step-by-step plan for corporate lean strategy and execution. The day-in-the-life perspective also enables getting started faster and delivering results quicker.

Every chapter has a mapping of the activity and the time recommended spending on that activity. 

For example during the first 30 days it is as below:

Activity	Time Spent	Comments
Define vision	50%	Collaborative vision definition
Identify customer personas	10%	Focus on outside-in point of view
Prototype MVP and program training	25%	Train executive leadership
Run experiments	10%	Prepare for experiments
Pivot or persevere	5%	Ideate potential pivots

InfoQ: How can organizations apply this framework?

Nir: Focus on getting business people in the room - that’s one of the things I like about the four disciplines of execution. If you want to change how an organization does business, it is not enough to have engineers practice Scrum; there has to be business buy in. It all connects to this amorphic idea of business agility. I already discussed it on rethinking lean startup in a big corporate. We found that having the PMO lead and support the effort makes lots of sense. This is another gainful insight - use existing common structures yet repurpose them.

Once you have business buy in, and in the same room, train them, get them to come up with ideas. I prefer conducting an executive workshop; however this could work with any team. Then have them break down the assumptions lurking their ideas. Next step, have them rank the ideas according to most important and most uncertain. Let them pick a risky and uncertain idea and identify the hypothesis behind the assumption. This is a tricky step where many need coaching; help them distinguish between an assumption and a hypothesis. Ask them how they might validate the hypothesis - they need to create a tangible test that can be quickly validated. 

At this step, as we start the process, I ask them to validate without any software being written! Software is an enabler that isn’t necessary to validate business assumptions!

Sometimes we follow with a crazy five days MVP - similar to The Design Sprint concepts, however less UX oriented than what is proposed there.

The teams then proceed to create a Kanban board of their validation activities. We ask them to present their validations and pivots - similar to an agile demo - in 90 days. We grow the program organically, and we add development members into the teams. This is the opposite of how agile teams normally grow - where scaling is usually seen as growing organically from development; I believe that’s the main reason agile is limited in impact. Business agility has to be customer focused; it is not about having dev teams deliver faster.

InfoQ: What are the main challenges of agile transformation, and how can we deal with them?

Nir: That’s a great question! And one that I am often asked when speaking to various audiences.

There are several recurring patterns of challenges - they are all around vision, leadership and alignment.

So many companies are ’agile by name only’nowadays, where it is crucial to start with the basics - when you say agile what do you mean? What are you trying to achieve? What are you trying to solve? What is your vision for business agility - rather than creating merely agile engineering teams?

“Big bang” (full reorg), top-down, lean agile transformation fails to address the minds and hearts of middle managers who play an important role in any organization. Not building trust with this group is the first sign of failure for a lean agile coaching organization.

When you initiate a lean agile transformation, spend extra time on expectation setting.

Ensure that the roadmap of the lean agile transformation, including deliverables with related measurements and milestones, are defined as is the process to collect this data. Set regular data reviews and ensure that the format of the reports that you provide meets the expectations of your audience. Ideally, set up an automated report from a lifecycle management tool of your choice.

I mentioned that velocity of a team is a vanity metric that is not meaningful for the business because it reflects output - quantity rather than quality and business relevance, on top of which it is easy to game it. When you focus on velocity you also impede the breaking of silos - since you encourage teams to throw their work over the wall so to speak

Lastly - in my opinion - without feedback loops with customers, agile is as wasteful as waterfall; the only reason for adopting lean agile is to activate a fast-responsive feedback loops that enables data based decisions for product and service development.

About the author

Michael Nir is a keynote speaker, best selling author and Lean Agile inspiration expert; known for his passion, creativity and innovation. The author of ten books on influence, consumer experience, and Agile project management, Nir delivers practical skills gained from eighteen years of experience leading change at global organizations in diverse industries.