Agile and Lean: A Primer for the Business Leader

Looking for DevOps: A Primer for the Business Leader in our Ways of Working series? Click the link above.

In our last post we discussed the ways of working from manufacturing that brought us to where are are today.

Given the importance of taking an optimal approach for the type of work, it is important to understand what agile, lean, DevOps, and waterfall are and their history. People, historically, have spent very little time thinking about or improving how they do what they do. This is the first in a series of posts adapted from the book Sooner Safer Happier addressing these different frameworks.

What Is Agile?

Origins

Agile (along with Lean) has origins in manufacturing in Japan, heavily influenced by the teachings of W. Edwards Deming from the 1950s onward. As we saw in A Sense of Urgency, the 1986 Harvard Business Review article “The New New Product Development Game” articulates the benefits of better ways of working that were taking place in manufacturing firms like
Toyota, Honda, and Xerox. The article is still remarkably up to date. These organizations, in the context of new product development, had small, empowered, multidisciplinary teams working in small iterations and with a clear North Star outcome. They were empowered as to how to achieve the mission, within guardrails, and with a high degree of experimentation. As of the date of the article, Xerox was developing new products with half the number of people and in half the time compared to the previous sequential, stage-gate process.

The article uses the sport of rugby as an analogy, with the team moving together up the pitch with the ball. This led Ken Schwaber and Jeff Sutherland in the early 1990s to call their iterative and incremental approach to software product development Scrum, as per the scrum in rugby.

At the same time, others in software development, myself included, were experimenting with “lightweight processes” (versus heavyweight, sequential, stage-gate processes), finding that more value was delivered sooner with less delivery risk, higher levels of engagement, and no “sunk cost fallacy.” With experimentation and experience, “lightweight” processes for software development became increasingly popular, being more suited to the emergent nature of digital work. As Barry O’Reilly, author of Unlearn, has subsequently put it, “Think Big, Start Small, Learn Fast.”

The Agile Manifesto

In 2001, seventeen leading software developers met in Snowbird, Utah, to discuss new, lightweight methods of developing software. They produced what became known as the Agile Manifesto. This manifesto is a set of four values and twelve principles that optimize outcomes where the type of work is unique product development. Teams who follow these principles welcome changes to requirements late in product development; trust motivated individuals to get the job done; believe that the best architectures, requirements, and designs emerge from self-organizing teams; and adjust behavior at regular intervals in order to become more effective. While the manifesto was put together by software developers, the values and principles apply to any unique emergent type of work, not only software.

The principles laid out in the manifesto are the very opposite of the top-down management methods advanced by Taylorism. Instead of supervisors giving orders, multidisciplinary teams work together toward a clear outcome aligned to business strategy. They determine safe-to-learn experiments to test the outcome hypothesis (probe), measure results (sense), and react accordingly (respond). Teams are empowered within minimal viable guardrails (for example, compliance, standards, and regulation). Change and changing how you change, based on feedback loops, is essential to optimize outcomes. The principles leverage emergence to your advantage to reduce risk early and pivot to realize more value sooner.

The Agile Manifesto intentionally leaves it to people to figure out how to apply the principles because organizations are complex adaptive systems and each context is unique. It acknowledges that there is no one-size-fits-all set of practices.

One of the principles states: “Simplicity, the art of maximizing the amount of work not done, is essential.” The focus is on outcomes over output. That is, maximizing outcomes with minimal output, the most value for the least effort. The definition of “productivity” is the number of units of output for each unit of input, which for unique emergent work is not optimal. Instead, the focus should be on “value-tivity,” maximizing outcomes for the least output.

The Agile Industrial Complex

As we passed the tipping point in the Age of Digital, to quote Dan Mezick, an “Agile Industrial Complex” developed. This is a top-down imposition of Agile practices and one-size-fits-all processes with no empowerment for teams. It is push, not pull. It is prescriptive and formulaic, not emergent or empowering, and rarely optimizes for desired outcomes in context. It is a forced infliction of emergent ways of working, done with a traditional, deterministic mindset. It is Agile snake oil, cookie-cutter Agile, Agile-in-a-box. Install it and you will be Agile. It is Agile for Agile’s sake, Agile as the goal, measuring “how Agile are we.” It does not necessarily lead to agility, to better outcomes.

The word “Agile” itself has collected a lot of baggage since its first inception, and I come across many people who have been burnt by an overzealous infliction of it in the past. The word generates resistance. To quote Peter Senge, author of The Fifth Discipline, “The harder you push against a system, the harder it pushes back.” To increase agility, to optimize for outcomes, given history and culture, sometimes the best approach is not Agile at all.

Capital “A” Agile versus Lowercase “a” agile

In Sooner Safer Happier, capital “A” Agile is used to refer to agility in this sense: as a noun, a product, a process, a set of practices, doing Agile. This alone does not necessarily translate into better outcomes. I prefer “agile” with a lower case “a,” as a verb, rather than a noun, as in being agile, as in exhibiting agility. It refers to behavior, to culture, to principles, which inform millions of decisions every day. How that manifests will be unique, as your context is unique, and as we will see throughout this book.

Sometimes, I will use the word “nimble” in place of agile in order to sense check. For example, we want to be nimble (i.e., we want to learn fast, continuously improve, and pivot), rather than we want to do Agile (we’re doing standups, counting points, and doing mandated, top-down two-week sprints, but not necessarily improving and still working within a broader deterministic mindset). Equally, we don’t necessarily want to “do Nimble” or run a Nimble Transformation. We do want to improve ways of working suited to our unique context in order to optimize for outcomes.

As organizations are complex adaptive systems, there is no one best way. The majority of agility is about behavioral norms, culture, rather than processes or tools. It’s people, process, and tools, in that order.

From Mass Production to Lean Production

“Lean production” was a term coined by John Krafcick, the first American engineer hired at the Toyota-General Motors joint venture, NUMMI. His training at NUMMI included lengthy periods in Japan at Toyota factories, where he learned the fundamentals of Lean production at the source. The term first appeared in the book The Machine That Changed the World. One description states that “Lean production is lean, because it uses less of everything compared with mass production. Half the human effort in the factory, half the manufacturing space, half the investment in tools, half the engineering hours, in half the time.” The core idea is to maximize customer value while minimizing waste.

Lean production began in the Toyota Production System where, due to economic necessity in the 1950s, with smaller volumes than in the US or Europe and with limited capital, Toyota’s chief production engineer, Taiichi Ohno, devised a way to change machine stamping dies for body panels from a day to an astonishing three minutes. In doing so he found that it cost less per part to make small batches rather than run off enormous lots. This was because it eliminated the cost of carrying large inventories, and it meant that any stamping mistakes showed up almost immediately with minimal waste.

Building on concepts from Sakichi Toyoda (founder of Toyota) and his son, Kiichiro, Ohno also instigated a kaizen process of constant improvement with all workers, rather than improvement being a job role that someone else did, as was the case in the US car industry and Taylorism. Finally, Ohno developed new ways to coordinate the flow of parts within the supply chains, moving to a just-in-time, pull-based system, further eliminating costly inventory and waste and optimizing for flow. It took Ohno more than twenty years to fully implement these concepts. The result: in 2008 Toyota was the number one car manufacturer globally, stripping GM of the sales crown for the first time in seventy-eight years. Currently, Toyota has the highest market value of any automotive manufacturer, worth four times more than GM and seven times more than Ford.

In Lean Thinking, Daniel Jones and James Womack outline five lean principles:

1. Value: specify value from the point of view of the customer.
2. Value Stream: identify the value stream and all the steps in it, from concept to cash.
3. Flow: limit work in progress; stabilize flow; focus on lead time, throughput, and flow efficiency; alleviate impediments to flow.
4. Pull: move from a push-based system of work to a pull-based system of work; go at the capacity of the system of work and don’t over-
   produce.
5. Perfection: the relentless pursuit of perfection.

Lean and agile, with a common root in post–World War II Japan, have a lot in common, such as a focus on building quality in, value, flow, respect for people, a pull-based system of work, and a kaizen process of continuous improvement and visualizing work. However, a key area where they differ is the focus on “standardized work” in lean. Mass production looks for “good enough,” and lean production looks for perfection. This is desirable for repetitive production; however, for the unique, unknowable, emergent domain of product development, “perfect is the enemy of good,” to quote Voltaire. Lean production (suited to knowable, repetitive work) seeks to minimize variability, striving for perfection, in some cases targeting Six Sigma levels of perfection. Agility (suited to unknowable unique work) actively seeks and benefits from variability with multiple minimally viable, safe-to-learn experiments in order to optimize for outcomes.

In our next post in this series, we’ll examine the origins of DevOps.

- About The Authors

Jon Smart

Jon is co-founder and CEO of Sooner Safer Happier. Jon is a business agility practitioner, thought leader, and coach. Jon has been an agile and lean practitioner since the early 1990s. Jon helps large organizations deliver better value sooner, safer and happier through better ways of working. He is the lead author of the award-winning and bestselling Sooner Safer Happier: Patterns and Antipatterns for Business Agility.

Follow Jon on Social Media

• 
•