Chapter 1. Introduction
Despite its title, this report is really about ability, learning, and adapting. Design Thinking, Lean, and Agile are mindsets that, when practiced, help organizations develop new competencies. We learn to tackle problems and explore possibilities. We strive to make every action a learning opportunity for making better decisions. And, we put learning to work as we pursue outcomes in a way that’s optimized for adapting to constant change. More than following steps, procedures, or instructions, this report describes the mindsets and ways of working that help teams to think differently, practice new skills, and develop new ability.
Popular culture depicts designers as precious snowflakes. In the movies, developers are socially inept propeller heads. And we all like to joke about bean-counting middle managers and executives who are asleep at the wheel. And, all of them are petrified of being disrupted by Silicon Valley’s hoodie-wearing startups.
Convention is dead in the modern age—there are no rules, and job roles are so last century. It’s no wonder people are so confused about how to do software better.
These are exaggerated generalizations, I know, but they do paint a picture of the mess we face when working together to build stuff that matters. Creating digital products and services is a pursuit that requires collaboration across many disciplines. Technology, design, and business all have their own kinds of architects. Strategy has different flavors, from corporate to customer to technology. Products require design, software is engineered, and someone needs to run the entire operation.
Design Thinking, Lean, and Agile are prominent mindsets among teams today. Each mindset brings its own kind of value to the product development life cycle (see Figure 1-1). And although they come from different origins—industrial design, manufacturing, and software development—they share many similarities, and are complementary and compatible with one another.
Figure 1-1. Design Thinking, Lean, and Agile
At a distance, Design Thinking is a mindset for exploring complex problems or finding opportunities in a world full of uncertainty. It’s a search for meaning, usually focusing on human needs and experience. Using intuitive and abductive reasoning, Design Thinking explores and questions what is, and then imagines what could be with innovative and inventive future solutions.
The Lean mindset is a management philosophy that embraces scientific thinking to explore how right our beliefs and assumptions are while improving a system. Lean practitioners use the deliberate practice of testing their hypotheses through action, observing what actually happens, and making adjustments based on the differences observed. It’s how organizations set their course, learn by doing, and decide what to do next on their journey to achieve outcomes.
The heart of Agile is building great software solutions that adapt gracefully to changing needs. Agile begins with a problem—not a requirement—and delivers an elegant solution. The Agile mindset acknowledges that the right solution today might not be the right solution tomorrow. It’s rapid, iterative, easily adapted, and focused on quality through continuous improvement.
Although the strengths of each mindset come to bear more so in some areas than others, no single mindset claims exclusivity over any particular activity. Too often, people ask, Lean or Agile or Design Thinking? The answer is “and,” not “or.”
In this chapter, we take a detailed look at the origins of each mindset, their strengths, and how they all fit together. Then, in the following chapters, we explore how to bring it all together in practice to define actionable strategies, act to learn, lead teams to win, and deliver software solutions.
What Design Thinking Is
Popular opinion suggests that Design Thinking is all about squiggly lines, honeycomb diagrams, overlapping circles, and loop diagrams. See for yourself. Those visual models and processes are helpful for describing what Design Thinking sometimes looks like, but they don’t really help anyone think practically or do things differently. And a cursory glance can leave the impression that it’s just process or procedure. It isn’t.
Design Thinking is a mindset as well as a toolkit of techniques for applying a designer’s ways of thinking and doing. We can apply it in any context, domain, or problem. Design Thinking helps explore new territory and define a range of potential solutions. Design is a verb as well as a noun. It’s something people do, not just a final result. It’s a journey and a way of thinking as much as it is a final outcome.
Elements of Design Thinking
Design Thinking is about design as a verb. It’s about the act of designing. Donald Norman, author of The Design of Everyday Things and the Godfather of user experience,1 describes it nicely:
Designers don’t search for a solution until they have determined the real problem, and even then, instead of solving that problem, they stop to consider a wide range of potential solutions. Only then will they converge upon their proposal. This process is called Design Thinking.
Let’s look at the component parts in Norman’s definition:
Determining the real problem
Searching for solutions
Considering many options
Converging on a proposal
He describes a discontentment with settling on the first solution. Ask yourself, when was the last time that your first idea was your best idea? Usually, first thoughts are the beginning—not the end—of finding the right solution. So much of design is about asking better questions, thorough consideration, and searching for possible solutions. The deeper our understanding of design’s formalities (constraint, requirement, environment) are, the more avenues for exploration we have. The more we explore, the more potential solutions emerge. This creates choices, and converging on a final proposal is where the designer makes choices.
Divergence, Emergence, and Convergence
An important tenet in Design Thinking is intentional and repeated divergence and convergence. The British Design Council first expressed this in 2008 as part of a global study into how 11 leading companies apply design practice. Their Double Diamond, which is now ubiquitous as a simple visual model that demystifies some of the complexities of design practice, represents diverging (out) and converging (in) as the faces of two adjacent diamond shapes (see Figure 1-2).
Figure 1-2. The divergence and convergence of Design Thinking
Stanford Design School, IBM, and IDEO also have well-recognized models for Design Thinking, wherein the concept is not represented so literally; rather, it’s implied in the approach described by their respective models. These companies are credited with popularizing Design Thinking, but they also recognize that design is not only about process, it’s about ability. Carissa Carter, director of teaching and learning at Stanford Design School, writes beautifully about the abilities that make designers great. Abilities like dealing with ambiguity, empathetic learning, synthesis, and experimentation. Process and tools are guiderails that help us to practice our abilities, but it’s by doing design that we become better designers, not by following a process. For a fuller history on the origins of Design Thinking (hint, it didn’t start with IDEO in the 90’s) read Stefanie De Russo on Design Thinking.
Emergence is what happens when we practice design. The mechanics of emergence is pretty simple. Dave Gray, coauthor of Gamestorming2 explains it best: “You will never find anything, unless you’re looking for something.”
Explorers of old understood this. Christopher Columbus set out westward from Andalusia intending to reach the East Indies to establish a new trade route. Surprise! The New World interrupted his journey halfway across the Atlantic Ocean.
Often, we don’t find exactly what we set out for, but something better is found along the way. Being unsure of exactly where you’re going or precisely how you’ll get there can be a good thing. Design Thinking is about finding your way, just starting somewhere and keeping an open mind, but not an empty head.
Design Thinking Is for All
Design Thinking is not something special, that only designers do. Everyone designs, whether it’s conscious or not. Design is not just the result of a designer working. It’s an activity that is inclusive and collaborative. With a little thought, anyone can use the design mindset. This is increasingly true in domains not considered the heartland of design, like corporations, government, health, not-for-profit organizations, and education.
AirBnB was a failing startup in 2009. Challenging its beliefs about how to win, putting itself in its customer’s shoes, and exploring solutions that don’t scale is how AirBnB learned its way to outrageous success. Design Thinking firm IDEO partnered with Kraft, first to spark a change in how the company collaborates internally to innovate its supply-chain process design. Then, with some of Kraft’s biggest customers, like Safeway, to transform operations for mutual benefit. And, finally scaling Design Thinking as a core capability at Kraft, enabling “joint value creation” with many more of their customers globally. Then, there’s the Mayo Clinic Center for Innovation, where Design Thinking is at the heart of transforming the healthcare patient experience.
The popularization of Design Thinking over the past decade is changing what it means to be a designer. And it means more than ever that everyone participates in design.
What Lean Thinking Is
Lean is a management philosophy for improving any system that produces value—that is, any organization. Persistent improvement, high quality, and reduction in waste are some common characteristics of Lean management. Although these are some good outcomes, that’s not what Lean thinking actually is. Lean is how Jones and Womack described the ideas and behaviors they observed at Toyota’s automotive manufacturing operations in Japan after World War II.3 Behaviors like continuously improving manufacturing quality and efficiency through deliberate reflection and learning, and organizing work according to customer demand. Toyota’s management practices—known as the Toyota Production System created by Taiichi Ōno4—were leading the company to outperform its western competitors. Table 1-1 summarizes these and other central ideas of Lean thinking.
Being Lean isn’t achieved by following Toyota’s recipe. That’s because it’s not procedural, it’s cultural, and it requires change. Not just a change in the way work happens, but a change in the principles and values that motivate how people work.
This sounds familiar, doesn’t it? We’ve all attended the company all hands meeting. Somebody high up speaks passionately about the need to change. We must improve and be more efficient. We must pursue quality in everything we do. We must be better. Workers file out of the auditorium, gossiping about whether the company is in financial trouble. Some speculate about a management shake-up or restructure. More seasoned workers have seen this before, remarking, “This happens every two years, a few months ahead of shareholder results announcements.” Just days later, buried by the rhythm and cadence of business as usual, most have forgotten the speech that was supposed to motivate change throughout the company.
That’s not how change happens. It doesn’t work because it asks people to change, without changing the system and culture that exists around them. It’s how we work, not just the resulting outcomes, that define Lean management.
From Scientific Management to Lean Management
Management practices forged in the smelters of the industrial revolution are still popular today. Then, mechanization and automation were transforming what it meant to work. Scientific management sought efficiency through process, rules, and control. Work was standardized; disassembled into small, repeatable tasks; and then reassembled into a schedule of tightly managed procedures. If you’ve worked to a Gantt Chart that specifies the breakdown, dependencies, and timing of your work, you’ve participated in a style of scientific management. This reflects its core value of control.
This kind of management improved efficiency, but workers ultimately detested it, which led to stronger than normal trade unionism, mostly because work became de-skilled, meaningless, and demotivating.5
In modern software businesses, control through scientific management is a falsehood. Things are too complex, too unpredictable, and too dynamic to be controlled. Managers seek certainty and predictability where in fact there is little, and their management practices provide only a comforting blanket of untruth. Only when the project fails—often when it’s too late to recover gracefully—does the lie become clear. Modern business calls for more modern management practices. In Chapter 2, we look at complexity and better ways to manage uncertainty.
Values and Principles of Lean Thinking
Lean thinking has been adopted and applied in many domains: healthcare, supply-chain planning, government, and education, to name but a few. Table 1-1 provides a snapshot of core values with related principles for the Lean management of anything.
| Values | Principles |
|---|---|
| Learning and adapting over analysis and prediction | Test beliefs through doing, not analysis or planning |
| Delay decision making to the last responsible moment | |
| Scientific thinking with deliberate practice | |
| Empowered people are happier and achieve better outcomes | Define clear goals, trust teams and give autonomy to achieve outcomes |
| Decentralize decision making | |
| Outcomes over outputs | Performance is measured by whether value is delivered, not by how much work is completed |
| Specify value, measure mostly that | |
| Manage flow to optimize value | Reduce batch size |
| Manage queues | |
| Deliver at speed | |
| Eliminate waste | |
| Respond to customer demand over creating inventory (create pull) | |
| Quality is a result, not an activity | Build quality in |
| Continuously learn and respond to improve things | |
| Pursue perfection |
There are loads of helpful methods and techniques associated with Lean thinking, such as value stream mapping,6 but simply implementing those procedures misses the point. We say Design Thinking isn’t only about process and tools, it’s about ability and practice. Lean is the same. If we take nothing else from Lean thinking, let us take Mike Rother’s brilliant teaching of scientific thinking with deliberate practice, using The Improvement Kata Model.
The Japanese word Kata means something like “a set combination of movements performed as an exercise.” The Improvement Kata (Figure 1-3) describes how we can practice the movements of scientific thinking. When we combine it with the plan-do-check-act (PDCA) cycle (Figure 1-4), we have both a way of describing the overall journey as well as some clear steps to help design and conduct the right experiments—to navigate from where we are (current condition) toward where we want to be (target condition).
But we also need deliberate practice to develop that ability. It takes practice because it’s different from our default mode of thinking. Like many learned abilities—music, sports, arts—improvement happens faster when corrective input can be provided by someone who has already mastered the craft. So, there’s a separate set of movements, The Coaching Kata, aimed at helping coaches teach.
Figure 1-3. The Improvement Kata by Mike Rother (Source: The Toyota Kata Practice Guide (McGraw Hill, forthcoming in 2017)
Figure 1-4. Interpretation of the PDCA loop by Mike Rother (Source: The Toyota Kata Practice Guide)
Following are the key concepts of the Improvement Kata:
There’s a knowledge threshold. That is, we don’t know everything, and, often, how we think we’ll get somewhere is not actually how we’ll get there.
By using the PDCA cycle to make predictions (plan), taking action (do an experiment), observing what happens (check the result), and interpret the meaning of evidence (take next action), we can systematically increase our knowledge, and iteratively learn our way toward the target condition.
Deliberate practice is how we acquire and improve the skill of scientific thinking. That is, we must practice to learn, because scientific thinking is not our natural way.
Being coached by someone who has mastered the craft provides corrective input so that we learn faster.
Too often, the conversation about Lean stops with the elimination of waste and a focus on quality in the context of process optimization. Those characteristics are undeniably important, but that’s only part of what Lean has to offer. Lean is also fundamentally about learning, exploring uncertainty, making better decisions, and leading people to achieve outcomes.
What Agile Is
Agile came from a need to deliver software projects better. Like most movements, the true origins of Agile are debated. Agile as a label came from a collective of 17 independent software practitioners who coalesced in 2001 at a ski resort in Snowbird, Utah. That meeting resulted in the publication of the Agile Manifesto, and the formation of Agile Alliance. Some of the proponents of Agile at that time—Ken Schwaber who co-created Scrum, and Alistair Cockburn—were aware of the PDCA cycle and were somewhat influenced by the Lean movement. Certainly, there are similarities in the values and principles, making Agile and Lean thinking very compatible.
At that time, software projects were predominantly managed using a heavyweight, so-called waterfall management practice. This describes the cascading nature of how work happens. Project phases like analysis, requirements, design, development, testing, and deployment run in a linear and consecutive sequence, where the preceding phases must be completed before continuing to the next phase. It wasn’t working. Depending on whether you trust Gartner or Dr. Dobbs, somewhere in the range of 20 to 50 percent of software projects were failing.
Agile became the umbrella term encompassing alternative approaches emerging through the late 1990s for managing software delivery more appropriately. The purpose was not to codify the right way, but instead to describe the values, principles, and behaviors of teams that were embracing Agile ways of working and winning. Principles such as “welcome changing requirements, even late in development,” “Working software is the principle measure of progress,” and “Continuous attention to technical excellence and good design enhances agility” are some of the twelve principles describing the Agile way. Because Agile is related to Lean, it’s unsurprising that the two mindsets share much in common. And mostly, they’re differences come down to what they’re applied to. Let’s look at these similarities and differences in more detail.
Commonalities of Lean and Agile
Agile and Lean are similar in the following ways:
They embrace and adapt to change, regardless of how late it occurs.
They produce value iteratively, in short cycles.
Each is humanistic, that is, valuing people above process, and encouraging autonomy and collaboration.
Both Agile and Lean focus on quality, which in turn improves efficiency.7
They seek to eliminate wasted effort.
They continuously improve through reflection and learning.
How Lean and Agile Are Different
Now let’s look at some differences.
Agile optimizes software delivery; Lean optimizes systems of work
Agile focuses more on creating software, whereas Lean is mostly about optimizing systems of work that produce value.
This is a little nuanced. It doesn’t mean that Agile teams don’t deliver value. Of course, they do—software has value. The point is that Agile was born out of a need for better ways to deliver software, and teams’ primary measures of success are things like delivering working software, and the ability to adapt to changing requirements. Lean goes beyond software, addressing the entire value stream in a given organization. This system of work is a superset to software delivery. That is, software delivery is one activity (among myriad other activities) that organizations do to produce value for their customers.
Continuous flow versus time-based iterations
Lean strives to achieve flow of value by aligning all work with customer demand. Work is selected according to customer demand and is pulled through the system that generates customer value. Lean principles—like managing queues, limiting work in progress, and reducing batch sizes—help to make the system of work efficient and optimize the work moving through the value stream. This flow is continuous.
Customer value matters in Agile, too, but the work is done in time-based iterations, whereby candidates are selected and prioritized according their value, size, and do-ability, from a giant backlog of possibilities. It’s not that Agile can’t be continuous and aligned to customer demand (we explore this in Chapter 5), it’s just that effort is measured in iterations, and we use things like estimated team capacity, prioritization, and team velocity (actual throughput) to manage iterative completion of work.
Stable and repetitive versus always changing
As in manufacturing, a lot of Lean practice is about consistently producing the same output, over and over again, improving and optimizing each time. This is most obvious in the production of tangible things. Many Lean principles are also relevant in portfolio management, for which it’s initiatives that are being produced. Although each initiative will have a dynamic outcome, the way we go about managing the portfolio of work is relatively stable, repetitive, and somewhat predictable.
It’s the soft in software that means things don’t need to be perfect and final on completion, never to be changed again. In fact, it’s the exact opposite. The malleability of software lends itself to continuous change. Agile is all about responding to the constant need to change, and many of its practices—like Continuous Delivery (CD)—exist to do exactly that.
All Together Now
Design Thinking, Lean, and Agile mindsets aren’t mutually exclusive. In fact, there’s quite a lot of overlap. This is confusing, first because we often prefer simple explanations, and second because in the messy world in which we live, we tend to blend mindsets into ways of working that make sense for the job at hand. Some might disagree, but this is for the greater good. There is nothing to be gained from dogmatic adherence to a particular right way to do things. On the contrary, when we thinkingly blend and combine different approaches in meaningful ways, we’re exercising our innate ability as humans to solve problems. So often the question is “Lean or Agile?” The answer is really “and”. It’s Lean and Agile and Design Thinking. Some of the characteristics of each mindset are shown in Figure 1-5, helping to address a range of different needs.
Figure 1-5. The characteristics of three mindsets
The Lean mindset drives continuous experimentation to learn our way to the correct answers. It helps in identifying the appropriate things to build as well as improving the system of work that delivers value. This is entirely agnostic to the medium in which value is produced; that is, it could be software, underpants, or healthcare.
The Design Thinking mindset is all about understanding constraints, seeing opportunity and exploring possibilities. It’s a quest toward finding opportunities and exploring solutions that create value for customers or the organization.
The Agile mindset is about achieving outcomes with software in the best way. It’s how IT teams unlock value continuously, adapt to changing needs, and build quality into the software they create.
It’s at the intersection of these three mindsets, depicted in Figure 1-6, that we see how everything can fit together.
Figure 1-6. How the three mindsets work together
Together, Lean and Design Thinking helps us to understand where we’re at today, where we want to be tomorrow, and pursue success through exploration, experimentation, and validated learning. The discipline of framing problems and opportunities and exploring many options in Design Thinking melds beautifully with the Lean practice of scientific thinking and learning by doing.
Design Thinking and Agile are a collaboration in realistic solutions. Software is the medium; engineers and designers are the artisans. Together they craft solutions that deliver on desired outcomes. And they do their work iteratively, continuously, and paired together.
Agile and Lean is where strategy meets execution. Lean gives a framework for testing our beliefs and refining strategy through learning. This learn-by-doing approach works only if every part of the system is highly adaptive. Agile provides the flexibility to respond to change, which is a first-class capability for aligning technology delivery to real value, always.
The strengths of each mindset come together to help us achieve the right outcomes. Design Thinking is about exploring problems and opportunities, Lean moves us toward building the right things, and Agile is a way of building things right. Chapter 2 maps four steps for defining strategy and executing toward successful outcomes, highlighting how each mindset contributes along the way.
1 It’s generally accepted that Norman created the term User Experience Architect when he joined the team at Apple in the 1990s. He says he created it because he felt that human interface and usability were too narrow: “I wanted to cover all aspects of the person’s experience with a system, including industrial design, graphics, the interface, the physical interaction, and the manual.”
2 David Gray, Sunni Brown, and James Macanufo, Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers (Sebastopol, California: O’Reilly, 2010).
3 James P. Womack, Daniel T. Jones, and Daniel Roos. The Machine That Changed the World (Free Press, 2007).
4 Taiichi Ōno, Toyota Production System: Beyond Large-Scale Production. (Cambridge, Massachusetts: Productivity Press, 1988).
5 R. F. Hoxie. (1916). “Why Organized Labor Opposes Scientific Management,” The Quarterly Journal of Economics, 31(1): 62, doi:10.2307/1885989.
6 Mike Rother, John Shook, and Lean Enterprise Institute, Learning to See: Value Stream Mapping to Add Value and Eliminate MUDA (Cambridge, Massachusetts: Lean Enterprise Institute, 1998).
7 Although that sounds opposed to conventional wisdom, it’s true, and a fundamental principle of how Lean improves systems of work, and Agile delivers better software for less total effort. Episode 403 of This American Life explains how higher quality is achieved for less cost using Lean management at NUMMI’s Fremont manufacturing plant in 1984, a partnership between GM and Toyota.
Get Understanding Design Thinking, Lean, and Agile now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
