Agile Conversations: Transform Your Conversations, Transform Your Culture

by Douglas Squirrel

After years of study and many missteps, we have come to understand that the key to success is not only adopting practices but having the difficult conversations that foster the right environment for those practices to work.

Great results follow when you learn that a conversation is about more than just talking; it is a skilled activity. There is more to a conversation than what you can see and hear. In addition to what is said out loud, there is what has been left unsaid—the thoughts and feelings behind our spoken and unspoken words.

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.

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.

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.

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.

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.

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.

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.

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.

Emotions are particularly difficult for people to share in conversations. Not only do we lack practice in doing so but talking about emotions also violates two of the standard principles of the defensive mind-set: avoid expression of negative feelings and be seen as acting rationally.

Distinguish feelings from thoughts. We often say “I feel” followed by a thought, as in “I feel like we made the wrong choice.” If we can substitute “I feel” with “I think,” then we aren’t expressing an emotion.

Distinguish between what we feel and what we think we are. “I feel like a fraud” is sharing a thought about what we think we are, not an emotion.

Distinguish between what we feel and how we think others react or behave toward us. This is perhaps the most difficult of these guidelines to apply, because when we say “I feel ignored” or “misunderstood” or something similar, we are actually making a statement about other people—th...

Build a vocabulary for feelings. Saying “I felt good when that happened” isn’t very specific, nor is “I felt bad when that happened.” English has dozens of words to describe specific emotional states. (See the handy “Feelings Inventory” from the Center for Nonviolent Communication.20) S...

Because the emotions are strong and clear to us, we assume they are obvious to others as well. This cognitive bias, known as the “Illusion of Transparency,” is one of the barriers to genuine transparency. Why should we share something that is obvious? As we reflect on our conversations, it is important to remember that if we aren’t explicitly sharing our emotions, then we aren’t being transparent.

Fear is one of the biggest inhibitors of transformation. An organization may suffer from fear of error, of failure, of building the wrong product, of disappointing managers, of exposing poor leadership, of any number of other disasters. Whatever its particular subject, fear paralyzes the team, inhibiting creativity and cooperation.

The goal of the Fear Conversation is to discover hidden fears and make them discussable. But how do they get hidden in the first place? Part of the answer lies in a nondescript waiting room at Columbia University, where researchers Bibb Latané and John Darley told a group of students to fill in a questionnaire as part of a psychology experiment. After a few minutes, smoke began to flow into the room from a wall vent. Everyone kept writing; none of the students said a word. More smoke billowed in, and it became hard to see. Nothing happened. No one made a move to get help or even asked what was going on. Eventually, the acrid smoke led to coughing and watering eyes, and one participant opened a window—but the dogged students continued writing, not discussing the unfolding crisis or seeking assistance until the experimenters stepped in and terminated the exercise.5 The phenomenon on display here is variously known as the bystander effect or, our favorite term, pluralistic ignorance. Individuals are uncomfortable with an event or observation, but since others are not acting, they (wrongly) assume that everyone else thinks the situation is normal and safe, and don’t act themselves.*** A common fear is felt by some or all of the people involved, but the expression of that fear is inhibited by the apparent consensus of the rest of the group. In other words, people would rather die in a fire than be the first of the group to report the smoke. That’s how strong pluralistic ignoran...

In The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA, Diane Vaughan investigates the space shuttle explosion in 1986;6 and Richard Feynman, in an appendix to the Rogers Commission Report, separately analyzed NASA’s responses to problems observed during launches of the space shuttle on cold days.7 Both observed what Vaughan called the normalization of deviance: Because the shuttle had launched without calamity over and over in cold conditions, NASA concluded that cracks observed in booster components on such flights were not a problem. Although no cracks at all in the O-rings were expected, the fact that they were small in size led some engineers to conclude the danger they posed was low. Others had concerns—What reason could there be for believing that the next crack would be as small as the previous ones?—but did not speak up loudly enough to stop the flights.

The phenomenon of flickering tests, or tests that randomly fail, in software development teams illustrates how normalization of deviance can affect a team, though with much less dire consequences. Developers build an automated test suite and run it on every code change. They observe that a few of the tests succeed most of the time but fail at seemingly random moments. The natural conclusion is that the tests are erroneous—they “flicker” occasionally due to some testing anomaly—and can be rerun if they fail. If they succeed after a few tries, a release can go ahead. As many of us know too well, the result is a production failure when the flickering test turns out to be alerting us to a real but intermittent fault.

The Trust Conversation is an exploration into unknown territory. You seek to understand your conversation partner’s story, which you couldn’t have known at first, and align your story with theirs. By contrast, the Fear Conversation is more directed; thanks to your work in the previous section, you will likely have some idea where there is normalization of deviance and you will be looking for fears underlying that normalization. The danger is that you can overdirect the Fear Conversation, focusing only on the fears and causes that seem likely from your point of view.

How do organizations normally define their purpose, decide their strategy, or start on a major transformation? In our experience, it’s typically a task addressed by a board of directors, a small group of leaders, or just a couple of executives. They retreat in some way (to a boardroom or an off-site location), argue and debate and cogitate, and return to present a mission statement or a roadmap or a values definition. Then the rest of the company is expected to applaud politely and return to work.

Compliance is doing what you are told. At first, this doesn’t seem like a bad thing; after all, in many workplaces, compliance is the desired behavior, allowing a stable and effective process to keep running smoothly. However, compliance fails exactly when the process isn’t stable, when creativity is needed, when the team needs to identify and overcome unknown obstacles—that is, when you need to create new business value by taking on a new challenge, exactly the situation Agile, Lean, and DevOps software development methods were designed to address. Compliance without commitment is just going through the motions. From the outside, it might look the same, but people on the team know something is missing. Compliance is showing up; commitment is engaging with your whole self.

Compliance can be enough for routine day-to-day tasks; compliance is not enough to generate change, to improve, to excel. If these are your aims, you need commitment.

A commitment should be more than a promise—something you make with conviction and knowledge, and execute with creativity and skill. You will be able to make stronger, more confident commitments if you can do two things: keep each commitment as small as possible, and use a framework that makes it easy to deliver your small commitments over and over.

Management is indeed much simpler if we believe that people doing what they’re told is enough. It is easier to staff projects if we consider developers to be interchangeable resources, one of whom can be instantly and painlessly substituted for another. It is even easier if we believe a single engineer can divide her time efficiently among two, three, or even more projects! These beliefs about substitutability and frictionless task-switching fit the Taylorist, person-as-machine model. However, humans aren’t like that, and admitting as much might undercut the basis of the management culture, forcing us to confront difficult interpersonal issues that would just be easier to ignore.

If we are being repeatedly, unpleasantly surprised—missed deadlines, system downtime, budget shortfalls—we want to take action to end those surprises. The normal approach is to ask for more detailed information, to provide more specific instructions, or to put in more detailed controls. Or sometimes all three! Unfortunately, these instinctive responses often make things worse, because they miss the root of the problem: accountability.

What do we mean by being accountable? We mean simply being obligated to render an account of what you have done and why. A feeling of accountability, held by each person, is one of the keys to success. Accountability is akin to ownership, to responsibility, and to agency. If I am in control of how I spend my time, then only I am able to provide the information on why I have done what I’ve done, providing the reasoning and the intent behind my actions.

Some films portray the strong, decisive leader barking orders—someone who is firm but fair. Tough. Not afraid of calling out someone who is screwing up. The other trope is the ineffective manager, Dilbert’s “pointy-haired boss,” who is always asking for status reports and nitpicking the details while missing the big picture. Neither of these approaches are examples of effective leadership, in part because they are at odds with true accountability (the decisive leader won’t listen to the account, and the indecisive one can’t make up their mind about what to do with the information). Both styles lead to unproductive conflict in the organization—but conflict is exactly what creates drama, which is what sells movie tickets and Netflix subscriptions, thus accounting for the popularity of these approaches in films and television.