Inspire, develop, and guide a winning organization.
Create visible workflows to achieve well-architected software.
Understand and use meaningful data to measure success.
Integrate and automate quality, security, and compliance into daily work.
Understand the unique values and behaviors of a successful organization.
LLMs and Generative AI in the enterprise.
An on-demand learning experience from the people who brought you The Phoenix Project, Team Topologies, Accelerate, and more.
Learn how making work visible, value stream management, and flow metrics can affect change in your organization.
Clarify team interactions for fast flow using simple sense-making approaches and tools.
Multiple award-winning CTO, researcher, and bestselling author Gene Kim hosts enterprise technology and business leaders.
In the first part of this two-part episode of The Idealcast, Gene Kim speaks with Dr. Ron Westrum, Emeritus Professor of Sociology at Eastern Michigan University.
In the first episode of Season 2 of The Idealcast, Gene Kim speaks with Admiral John Richardson, who served as Chief of Naval Operations for four years.
New half-day virtual events with live watch parties worldwide!
DevOps best practices, case studies, organizational change, ways of working, and the latest thinking affecting business and technology leadership.
Is slowify a real word?
Could right fit help talent discover more meaning and satisfaction at work and help companies find lost productivity?
The values and philosophies that frame the processes, procedures, and practices of DevOps.
This post presents the four key metrics to measure software delivery performance.
November 2, 2020
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.
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.”
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.
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.
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.
“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:
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.
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.
No comments found
Your email address will not be published.
First Name Last Name
Δ
We're thrilled to announce the release of The Phoenix Project: A Graphic Novel (Volume…
The following post is an excerpt from the book Unbundling the Enterprise: APIs, Optionality, and…
A few years ago, Gene Kim approached me with an intriguing question: What would…
Ever since digital tools and experiences became aspects of everyday work life, there’s been…