Chapter 1

According to Michael Gale, author of The Digital Helix: Transforming Your Organization’s DNA to Thrive in the Digital Age, 84% of digital transformations fail.1 Trying to understand why the other 16% succeed, he found that success required a “fundamental shift in how people had to think about how they interact, how they collaborate and work, and if you don’t spend time changing people’s behaviors, you don’t spend time changing culture and how people make decisions, all of this falls flat.”2

Our way to make this fundamental shift is to turn to the most human of abilities: the conversation. Humans have a uniquely powerful and flexible language. To get the most out of it, we need to learn the skill of conversation and how to overcome our innate biases, which work against collaboration and connection. When we change our conversations, we change our culture.

To understand the change we need, it helps to understand the culture we are coming from. As we describe in this chapter, we are still in the process of emerging from the mass-manufacturing paradigm of the software factory. This document-only model represents an attempt at communication without conversation. The failure of the software factory model has created space for the rise of new, people-centric models like Agile, Lean, and DevOps. But well-meaning attempts to adopt these new models fail when the focus is on processes and methods, reinventing some of the same mistakes of the software factory on a smaller scale, creating “feature factories,” as John Cutler calls them.3

We both began our careers in the 1990s in medium-size software companies,* wrangling C code on huge, desk-bound PCs alongside dozens or hundreds of our colleagues doing the same thing. We were small parts embedded in a much larger system. And no wonder, since the systems we were part of were an expression of the twentieth-century philosophy known as Taylorism.

A machinist and mechanical engineer by trade, Frederick Winslow Taylor led a professional crusade against waste and inefficiency, becoming one of the first management consultants in the process. At the heart of the waste, in Taylor’s mind, was the wide variation in how work was performed from one worker to the next. It would be much better, he reasoned, for everyone to be taught the one right way, and then for workers to follow that way without deviation; any other approach must necessarily be less efficient. And who determined the one right way? Professional managers and consultants such as Taylor himself.

“Scientific management,” the philosophy of which Taylor was the most vocal proponent, says that it is the job of managers to devise and understand the best way of working and then enforce unswerving standardization. With his influential 1911 book The Principles of Scientific Management, Taylor provided the intellectual underpinning for mass manufacturing based on the assembly line, with low-skilled workers doing the same simple tasks again and again under the watchful eye of management.4

Taylor’s view of the world created a very distinctive and dehumanizing workplace culture. The factory was envisioned as one giant machine. Managers were the mechanical engineers, designing how all the pieces should work and checking that they were operating correctly. Workers were merely replaceable parts: they operated within specified tolerances, or they were defective and to be discarded. Communication was top-down and limited to commands and corrections. Conversations were not required. Collaboration was not required. Thought was not required beyond doing the job you had been told to do.

The software industry we joined in the nineties had transplanted Taylor from the factory into the cubicle. Consultants and salesmen promised managers ease and efficiency in the new tools, new processes, and new methodologies they were peddling. “Having trouble with software development? Bugs and delays got you down? Never fear! We have the best practices written down and ready to go.” Management could buy the system off the shelf and tell developers to follow along. And as the work flowed through every defined checkpoint and process gate, you could be confident that you would be on time and on budget. Or so was the promise.

Lacking a mechanical assembly line, the software industry created one from paper. Managers adopted or invented logical models describing the single, right way to work and codified them in documents with step-by-step instructions and flowcharts. This documentation-driven development was designed to stamp out any possibility for error by specifying how each part of the final program would function and what each software worker would do to make it happen. There was the marketing requirements document, the product specification, the architecture documentation, the implementation specification, the test plans, and more—no human activity was left unaccounted for. Thick manuals prescribed in painstaking detail the attributes of every data structure, which language constructs could be used, and even the format of comments. Meticulous software designs arrived on designers’ desks, with every database column specified, every validation defined, and each screen carefully illustrated down to the last pixel.

But there was a logic to this. Everyone knew it was more expensive to fix defects after the software was shipped to clients. In fact, the earlier we found the bugs, the cheaper they were to fix. It was less effort to fix the designers’ flowchart than to fix the code, and less effort still to update the specification document than to change the flowchart. The inexorable logic dictated that we should spend the time up front to get everything right, and then mechanically implement to save ourselves time and money downstream. It was all very sensible, all very rational.

Just how poorly this system worked was documented by the Standish Group in their infamous 1994 CHAOS Report on the shocking level of failure in software projects. Unlike the failures of bridges or airplanes or nuclear plants, the authors noted that “in the computer industry ... failures are covered up, ignored, and/or rationalized.” So they set out to identify “the scope of project failures,” “the major factors that cause software projects to fail,” and “the key ingredients that can reduce project failures.” The report concluded that 31% of software projects in the United States were cancelled, costing American software companies $81 billion. Only 16% of projects were completed on time and on budget.5 The report laid bare the failures of Taylorist methods and the software crisis they had created.

With the crisis widely acknowledged, there was no shortage of people searching for answers. One school of thought was captured in the Capability Maturity Model (CMM) from the Software Engineering Institute at Carnegie Mellon University. Created to help the US Department of Defense assess software contractors, CMM doubled down on the importance of documentation and process. Adherents of this approach implemented greater supervision, more checks, and additional specifications in their quest for predictability. “A software development process which is under statistical control will ... produce the desired results within the anticipated limits of cost, schedule and quality,” they asserted.6

Others from across the software industry, including software practitioners on the ground and those working with them, found inspiration and ideas in other places. Being on the front line of projects, they had the scars showing that the idealized, mechanical approach, no matter how reasonable it sounded, didn’t explain why software projects succeeded or failed. Rather than working from first principles, they observed what worked in practice. In trying to understand their experiences, they found the answer couldn’t be captured in reams of documentation. It wasn’t a tool you could buy, and it wasn’t in the mechanical application of process. It was people!

Dr. Alistair Cockburn, a keen and eloquent observer of software practices in the wild, captured the insight in his paper “Characterizing People as Non-Linear, First-Order Components in Software Development.” The title tells the story. In stark contrast with the CMM, Cockburn said he, “now consider[s] process factors to be second-order issues.”7 He found that it was largely people who make projects succeed or fail, and suggested we focus our improvement efforts on harnessing the unique attributes of people.8 For example:

1.People are communicating beings, doing best face-to-face, in person, with real-time question[s] and answer[s].

2.People have trouble acting consistently over time.

3.People are highly variable, varying from day to day and place to place.

4.People generally want to be good citizens—are good at looking around, taking initiative, and doing “whatever is needed” to get the project to work.9

This view of people is antithetical to the Taylorist view of people as mechanical, interchangeable parts. Expecting them to act as such ignores human nature and is doomed to failure. The empirical finding was that the culture of how people relate to one another and how they communicate on projects was important. Practitioners could see that we should be designing approaches and projects around people, not processes. We needed to be having the right conversations, building the right culture, if we wanted to improve our chances of success.

The idea that people are the central concern of software methods sparked an extended transformation that has reshaped the building of software since the turn of the century. Lean manufacturing disrupted and transformed the previously dominant Taylorist mass-manufacturing paradigm, scoring tremendous gains in productivity and quality by changing the culture of the factory. Rather than viewing workers as replaceable parts, Lean manufacturing relies on “both an extremely skilled and a highly motivated workforce,” one that anticipates problems and devises solutions.10

Agile software development, Lean software, and DevOps have similarly disrupted and transformed the software factory. Each of these approaches targeted different elements of the factory, but they all started with a break from the dehumanizing, mass-manufacturing approach. They changed the culture by breaking down divisions of labor and introducing collaboration in the place of rigid process.

As we’re about to illustrate in the following sections, the early proponents in each movement implicitly espoused two fundamental values, transparency and curiosity, which led them to advocate methods that developed some or all of our five key attributes of successful software teams: high trust, low fear, understanding why, making commitments, and being accountable. And these values and attributes were all about human connections, information flow, eliminating barriers, and collaboration—everything the software factory wasn’t.

The initial wins from each successive movement were amazing: early adopters reported dramatic improvements in time to market, reduced bug rates, and higher team morale. The Lean Startup advocates, for example, boasted about “doing the impossible [releasing to production] fifty times a day.”11 Unsurprisingly, many others, including both of us, climbed on the bandwagon and tried the new methods to see if we could get the same results.

The problem—and the reason for this book—is that during the explosion of Agile development, and then of Lean software and DevOps, later adopters missed the importance of human interaction. Leaders thought they could behave the same as they always had—could keep their factory mind-set—and that dictating change to others would be enough. As a result, they focused on the easily monitored, more superficial process changes: standups, work-in-progress limits, tool selection.

Without the human element and without the right conversations, these changes were singularly ineffective. As a result, across hundreds of organizations between us, we’ve repeatedly seen disillusioned executives and frustrated teams declaring that Agile development (or Lean software or DevOps) just doesn’t work.

To summarize, they took a mechanistic view of joining the human-centric transformation, missed or denied the importance of relationships, and then wondered why nobody was cooperating and nothing was getting done.

This book, by contrast, is all about getting back to the basic human interactions you’ll need to succeed. Let’s start by reviewing the history of each movement, which will prepare us to look at the simple technique you need to master to get people back into your process: the conversation.

By the end of the 1990s, the rebellion against the software factory had produced a Cambrian explosion of alternative approaches to software. Bucking the dominant paradigm of “documentation driven, heavyweight software development processes,”12 the members of the new movements advocated heretical practices like just-in-time design, frequent delivery of working software, and involvement of real customers in software production. Most extreme was a cultural change that called for a radical reduction in planning activities in favor of collaborative interactions between individuals doing the work. To those used to the dominant practices of the software factory, these leaders seemed like a crazed mob bent on creating mayhem. And yet there were stories of amazing results—elevated morale, rapid delivery, high quality—in the teams brave enough to try these new methods.

Then, seventeen of the most visible proponents of the “lightweight software” movement gathered at the ski resort in Snowbird, Utah, in February 2001. As documented by James Highsmith, they were a diverse group, including the founders and advocates of Extreme Programming (XP), SCRUM, DSDM, Adaptive Software Development (ASD), Crystal, Feature-Driven Development (FDD), Pragmatic Programming, and others.13 The question was, could they find common ground?

As it turns out, they did, and the result was, as Martin Fowler said, a “call to arms,” a “rallying cry”:14 the Agile Manifesto, which continues to be widely used nearly two decades later.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

That is, while there is value in the items on the right, we value the items on the left more.15

The group followed the manifesto with an often-overlooked set of twelve accompanying principles. This set of principles remains a useful touchpoint for organizations who aim for agility.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.16

Together with the manifesto, these principles reflect the people-centric nature of the new methodologies. Calling out a few of the principles, we can see that common practices provide a framework for transparency and curiosity in an Agile team:

•Business people and developers must work together daily throughout the project: Commonly embodied as a short daily meeting—and called a standup regardless of the actual posture of the participants—this is an opportunity for developers to transparently share both progress and obstacles, and to ask for support from others on the team as needed.

•The best architectures, requirements, and designs emerge from self-organizing teams: Agile teams are expected to collaborate openly, discussing the trade-offs across alternatives, with each member transparently sharing their professional judgement and being curious about the judgement of others. This can be witnessed in practices such as the Planning Game, where estimates are publicly shared (transparency) and the differences are used to spark conversations (curiosity) to uncover what influences differences in opinion.

•At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly: One of the signature Agile practices is the retrospective, an opportunity for team members to discuss their experiences, both as individuals and as a team. There is a wide range of retrospective activities, such as those captured in the book Agile Retrospectives: Making Good Teams Great, and they all rely on the ability and willingness of team members to transparently share their experiences, and the curiosity of the team to learn about the experiences of others on the team.

Perhaps the most dramatic change introduced by Agile development was not how people on the team related to one another, but how Agile practitioners embraced customer collaboration, as reflected in the first two principles: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” and “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” Together, these two principles enshrine transparency and curiosity as the core protocols of Agile development between the team and the customer. By delivering software frequently, the Agile team provides the customer a transparent view of their progress, and the team is curious about what the customer would value next, even if it means upsetting their plans.

Agile development has never been just one thing, one set of practices, and certainly not the Taylorist vision of one best way to do things imposed everywhere. What it provides is a set of values and guideposts to build a resilient organization that can adapt to the tumultuous world in which we live.** At the core, the Agile approach demands a culture that can support collaboration and learning—a culture that has created conversations between people who had no reason to talk to each other in the software factory. The success of Agile has opened the doors to radical thinking far beyond the software teams in which it incubated.

Why, then, do we now see, over and over again, “feature factories” operating in the same spirit as those software factories of the nineties while claiming to be Agile? In fact, only the visible artifacts and processes have changed; the mind-set and the conversations, and therefore the culture, are the same. Instead of mounds of documentation and two-year project plans, these teams are fed a steady stream of features to implement without any connection to the upstream customer needs or the downstream business impact. The software assembly line has been replaced by a sweatshop, with piecework assigned to each worker. The labels are different—requirements may come in the form of stories or acceptance criteria instead of a monolithic document; there may be a burndown chart in place of a Gantt chart—but the outcome is the same: disconnected development, barriers to collaboration, endless handoffs, painfully slow progress, and often wrong software at the end of it all.

In 2003, just a couple of years after the Snowbird meeting gave rise to Agile software development through the Agile Manifesto, two deeply experienced programmers and software team leaders (who happened to be married to each other) brought ideas from Lean Manufacturing into Agile circles with their book Lean Software Development: An Agile Toolkit. Mary and Tom Poppendieck delved heavily into the Toyota Production System’s just-in-time, waste-reducing manufacturing methods to find insights, and translated them for the software world.

The Poppendiecks distilled the essence of Lean Software into a set of challenging principles:17

The Poppendiecks emphasized themes of optimization everywhere, rapid learning through frequent delivery, and system tuning and thinking. None of these themes are compatible with the software factory, and many build on the Agile principles that were already chipping away at the status quo when the Poppendiecks wrote their first book in 2003.

•Draw value-stream maps, just like their manufacturing colleagues, to locate inefficiencies (also known as muda, a Japanese word for waste).

•Look for and eliminate bottlenecks in their processes, from initial feature invention all the way to customer delivery and adoption.

•Aim to limit work in progress, so a QA team, for example, will accept only ten new features to test rather than building up a huge backlog of work it can’t process.

•Emphasize “pulling” features from one process step to the next rather than “pushing” them; so a programmer might pause her coding if there is no one available to review her work, rather than continuing to build up more “inventory” of unreviewed, unreleasable code.

As more companies embraced Lean software principles, more Lean manufacturing ideas showed their utility, including the Theory of Constraints for managing bottlenecks and the Kanban method, which did away with even the lightweight timeboxing of “sprints” in favor of a direct application of pulling work to regulate flow. Always pushing to “see the whole,” Lean software expanded to encompass operations in organizations of all sizes, from startups (as in Eric Ries’s The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses) to multinationals (as in Lean Enterprise: How High Performance Organizations Innovate at Scale).

Empowerment Is the Key

At first glance, unlike the Agile Manifesto, there is little explicitly in the Poppendiecks’ principles or Lean practices that suggests we need to worry very much about messy, inconvenient people and their difficulties in communication. Looking at the principles, we see that all but the second (Amplify Learning) and fifth (Empower the Team) are about processes and efficiencies. It’s easy to conclude that all we need is technical analysis of value stream maps and cold, calculated elimination of waste—and many adopters of Lean methods did exactly this, to their cost.

But as Mary and Tom Poppendieck say in Lean Software Development, “The foundation of human respect is to provide an environment where capable workers actively participate in running and improving their work areas and are able to fully use their capabilities.”18 Now that certainly sounds more like Cockburn’s “non-linear, first-order components,” i.e., people! And if we continue to look deeper, we see more connections to the fundamental, people-oriented values of transparency and curiosity:

•To eliminate waste, incorporate integrity, and work with the whole system, we will need to be transparent about where we have erred in creating inefficiencies and about how the system works (and doesn’t work!) as a whole.

•To amplify learning and deliver quickly, we will have to be curious about what options we have to achieve our goals and perhaps even experiment with multiple options simultaneously (a classic Lean strategy for quick learning).

•And to empower the team, we will need to be transparent with them about what we are trying to achieve and where they can contribute, and we will need to encourage their curiosity about all aspects of our customers and our business.

In fact, the successful Lean software teams we have seen rely heavily on vigorous, candid, continuous communication, with direct customer feedback, information radiators (like build status indicators and big, visible business-relevant charts), and even Toyota-style Andon lights (personal red/green/amber indicators used by team members to announce widely that they are stuck or blocked). These tools and practices, grounded in transparency and curiosity, are used to spur productive conversations about continuous improvement.

The problem is that, as with Agile development, too many organizations adopt the practices without the underlying spirit. We have seen organizations with the Lean Six-Sigma Green Belt certifications pinned to cubicle walls but lacking the culture of collaboration and continuous improvement. In our experience, this is a symptom of executives who thought transformation was something that could be purchased, and then wonder why the value stream maps and pull systems lie discarded and unused.

By 2009, the time was ripe for the humanistic software movement to broaden, and none knew it better than Patrick Debois, a frustrated consultant and project manager in Belgium. He was annoyed because on project after project, he saw how the deep divide between the responsibilities of developers and system administrators was holding back progress. Though many development teams were undoing the negative legacy of the software factory, they continued the same old practices when interacting with the operators who deployed and ran their code—minimal communication, low trust, and avoidance of difficult conversations. And just as they had within development teams, those behaviors slowed progress and kept everyone from delivering the right working software. It was clear that Agile development needed to move downstream: “The operations team needs to be agile, and it needs to be integrated into the project.”19

Patrick began trying to find others interested in what he called “Agile System Administration.” There were few takers at first—at one conference, only two people showed up to a session on the new topic.20 But there were others thinking the same way, notably John Allspaw and Paul Hammond, heads of operations and engineering respectively at Flickr. Their presentation “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr,” which called passionately for collaboration and trust between developers and operators, rapidly spread through Agile circles.21 Patrick watched a livestream of their talk with increasing excitement and, soon thereafter, launched the first “DevOpsDays” conference in Ghent. The DevOps movement, armed with powerful values and technical tools, had been born.

There is no DevOps czar, and there was never a DevOps equivalent of Snowbird, so there is no definitive list of DevOps principles. But the seminal Flickr presentation is one of the clearest statements of goals for DevOps that we are aware of, and it’s useful as a litmus test to gauge how teams that claim to be DevOps focused truly behave. The principles from the second half of that presentation are below (lightly edited to fit nicely into a list):

Notice how explicit Allspaw and Hammond are about the crucial elements of trust, respect, and collaboration; this is clearly a movement for people, not machines.

That’s not to say that there aren’t key DevOps technical and team practices. These include:

•Cross-functional team: Developers and operators work together in a single team rather than in separate groups with a handoff of completed code from one to the other.

•Cattle, not pets: For DevOps-focused teams, servers are not special snowflakes with individual identities and custom configurations but undifferentiated, identical, fungible machines that can be replaced at a moment’s notice.

•Infrastructure as code: Instead of manually configuring servers, system admins write programs (in special-purpose languages provided by tools like Puppet, Chef, or Kubernetes) to set up and test their machines.

•Automated deployment: Once the server is running, system admins and developers write more code together to make deployment to that server a one-click operation. That deployment can be triggered by continuous integration tools, further tightening the link to developers and their work.

•Sharing metrics: A team operating with a DevOps mind-set will have engineers and system admins alike looking at system uptime, error rates, user logins, and many more indicators of operational health, and addressing any indicated problems together.

In the 1980s, Simon Travaglia invented the ultimate sysadmin caricature for the online publication The Register.23 The Bastard Operator from Hell (or BOFH) despised developers and users alike and made it his purpose to increase their misery without limit. Travaglia went overboard for comic effect, of course, but he touched on the deep suspicion and mistrust present between developers and system administrators in traditional organizations, with impenetrable separation between the teams.

Thus, it’s no surprise that the DevOps principles and practices above are so clear in their demand for collaboration above all else: share your runbooks, display your metrics, discuss your failures (transparency). And respect the other “side” by avoiding finger-pointing and by finding out what effects your actions have (curiosity). By focusing on shared concerns and bringing developers and system administrators into a conversation with each other rather than about each other, DevOps moved away from the assembly-line mentality, with people-oriented values and attributes underpinning the DevOps movement—at least as it was originally conceived.

Bewilderingly, among some enterprises, there is a recent trend of anointing a special team that is separate from development and operations: the “DevOps” team. The whole point of DevOps is to create unity and collaboration among different specialties, not more silos. We even see job ads for “DevOps engineers,” who apparently are a special breed different from normal engineers and system admins. What happened? We believe this is the result of a buzzword-bingo approach to management. Rather than cultivating “individuals and interactions,” we have organizations hoping to avoid rethinking how to operate and instead get by with a reconfiguration of the software factory. And the surprising thing is that many have achieved that dubious goal.

The success of Agile development, Lean software, and DevOps in transforming the landscape of software is undeniable. Ideas that seemed extreme are considered normal now. Completing a feature in a day or an epic in a week is no longer astonishing, even in the largest corporations. As described by Eric Minick, program director at IBM,

Looking at history, the most striking thing to me is that delivery has actually gotten better. Just look at release cadences. Teams were content with an annual release cycle. As agile hit corporations, they were then proud to get to quarterly. If you’re at quarterly now, that’s slower than average. Monthly is more normal now. Almost every big enterprise has some cloud-native team releasing daily or better. Today’s cadence is an order of magnitude or two better than 15–20 years ago. Not bad.24

While a lot has changed in the schedules and the scope of our projects, there are times when we feel a sense of déjà vu. Large organizations are often stuck with a few Agile or Lean or DevOps processes uncomfortably coexisting with the old methods in a weird combination of practices—a “water-Scrum-fall” chimera.25 And we’ve met many small organizations and startups where the practices from Lean, Agile, and DevOps are on display, yet the designers and developers and operations people describe themselves as working in a “feature factory,” with all the same micromanagement and autonomy-destroying practices as before. It’s as if the giant software factory has been reassembled using smaller pieces with different names. There have been real benefits, but this isn’t the “enthusiasm, close collaborative teamwork, superb customer connection, and conscious design thinking” that inspired Richard Sheridan to write a book with the radical title Joy, Inc.26 What happened?

One part of the answer comes from Niels Pflaeging, who tackled the question in his article “Why We Cannot Learn a Damn Thing from Toyota, or Semco.” Pflaeging ponders why so many well-known examples of practices that work at pioneering organizations generate so little change. His insight is that what holds back transformations is the lack of “that magic ingredient ... our image of human nature, the way we think about people around us, and what drives them.”27***

Organizations have embraced the process and tools created by the Agile transformation, yet the Taylorist factory mind-set remains. There’s a lot less documentation to write, fewer specifications to read, and hardly any mandated signoffs, but these practices have merely been replaced with endless planning meetings and many pages of tickets in a project management tool—practices that still offer the Taylorist promise of giving management the insight and control they demand, because the role of managers is still to ensure that the right things get done.

What about the people doing the work? Remember those nonlinear, first-order components of software development? They remain first order and they remain nonlinear. Cynthia Kurtz’s and David Snowden’s Cynefin framework (see the sidebar on page 20) gives us language to discuss them.28 The feature factory wants to put humans in the lower-right, “obvious” quadrant: “If we have everyone in the planning meeting and the standup and the retrospectives, then they will collaborate.” This cargo-cult approach to collaboration doesn’t work with humans, whose nature is squarely in the upper-left, “complex” quadrant. Deliberately cultivating the dynamics of an effective organization takes a lot more work and a lot more skill than just putting a group of people cheek by jowl and calling them a team.

If we understand that the individuals and teams in our organizations are complex systems in and of themselves, then what should we do? According to the Cynefin framework, the appropriate way to navigate in complex scenarios, where there are no guaranteed right answers, is to “probe-sense-respond.”29 So, how do we probe-sense-respond with humans? That’s called a conversation—and it’s the way out of the factory.

Sidebar: The Cynefin Framework

Cynefin is a sense-making framework whose goal is to allow shared understandings to emerge and to improve decision-making (see Figure 1.1).

Figure 1.1: The Cynefin Framework

While there are a rich set of activities and applications in the Cynefin community, the first lesson of the framework is that appropriate behavior depends on which domain you find yourself in.

•When the situation is Obvious (causes and their effects are well understood), tools such as flowcharts are useful, because there are a limited number of possibilities, and the current state determines the next right step.

•When the situation is Complicated (causes and effects are known but only to specialists), with intricate needs such as troubleshooting unexpected behavior in a sophisticated machine, you’ll need to develop the relevant knowledge, either through homegrown analysis or by bringing in an expert.

•When the situation is Complex (causes and effects are only understood retrospectively), with unpredictable parts such as evolving team dynamics over the course of a project, past experience in other contexts (other teams) is not a sufficient guide for what to do next; instead, you need to experiment and develop multiple perspectives to understand the patterns that exist before deciding how to respond.

•And in a Chaotic situation (with no link between causes and effects), such as an outage in a distributed system, it is appropriate to act first in an attempt to bring the situation into a state where the normal relationships between cause and effect again apply.

As a body of theory, Cynefin is relevant to software and humans several times over. The software systems we build are, at least, Complicated and often have (unplanned) Complex emergent behaviors. The teams building the software system are complex systems themselves. And Cynefin further recognizes that humans are complex in and of themselves, not bound by simple rules. The framework gives us a good language for describing why the mass-manufacturing approach to software, with simple jobs performed by supposedly interchangeable workers, had such disastrous results.

*	Jeffrey at Borland, Squirrel at Tenfold. Both have long since been swallowed by bigger fish.
**	In fact, Alistair Cockburn and a number of his colleagues have begun coaching companies on adopting a methodology-agnostic approach that provides exactly these simple guidelines, called “Heart of Agile.”
***	See “Preparing: Theory X and Theory Y” in Chapter 7 for more on this key ingredient.