BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Q&A on the Book Agile Conversations

Q&A on the Book Agile Conversations

Bookmarks

Key Takeaways

  • Conversations are vital elements of an agile process and culture.
  • Having effective conversations is a hard, but learnable skill.
  • The first thing your team should build is trust.
  • A key to reducing fear is being truly curious about its source.
  • Being accountable is the way to achieve real customer collaboration.

The book Agile Conversations by Douglas Squirrel and Jeffrey Fredrick explores how productive conversations can change the way organizations develop software. It provides techniques and exercises that can help you gain insight into communication and collaboration issues and improve your day-to-day conversations, achieving valuable business results from your agile team.

InfoQ readers can download an extract of Agile Conversations.

InfoQ interviewed Douglas Squirrel and Jeffrey Fredrick about how we can improve our conversations and recognize situations where trust is low, how aligning stories can help to increase collaboration, how to have better conversations about the things we fear, how managers and teams can collaborate to jointly design decisions, why we should talk about accountability and the challenges that come with being accountable, and how to apply conversations as part of an agile transformation.

InfoQ: Why did you write this book?

Douglas Squirrel: We wrote this book because again and again, we saw organizations really trying to improve, to do the right thing, and yet ending up stuck, discouraged, and frustrated. In the last twenty years there have been some real breakthroughs in how software development is done, and yet not everyone has been able to reap the benefits.

Jeffrey Fredrick: Have you heard the quote "the future is already here - it’s just not evenly distributed"? That’s the problem we are trying to solve, allowing everyone to benefit from the transformations in work.

InfoQ: For whom is this book intended?

Fredrick: We wrote the book with those frustrated people in mind. Those people who are trying to make things better, who’ve tried doing everything by the book, and yet aren’t getting results. Those people who are on the edge of giving up, who are starting to think "it’ll never work here!" These people might be executives, they might be practitioners, or they might be managers who feel caught in between. That frustration is a reliable signal; it tells us this is someone who believes there’s a better way but doesn’t know how to get there. Those are the people who will have the motivation to do the work. Who else has the motivation to rethink something as fundamental as the conversations they have day-to-day?

Squirrel: Really this topic of productive conversations goes well beyond software, but we aimed the book at organizations looking to change how they do software by one name or another - an agile transformation, Lean, DevOps, or digital transformation - because they are often the ones we see looking for solutions right now. This focus allows us to be more specific in our examples, but the skills apply any time humans are involved.

InfoQ: What are agile conversations?

Squirrel: That’s a good question - and funnily enough, it isn’t one that we answer in the book! Agile conversations are focused on learning, responding to new information, and building trust and internal commitment. By surfacing all the information in the room, you generate more options and make better decisions.

Fredrick: Social scientist Chris Argryis called these "Model II" conversations, contrasting them with "Model I" conversations which use defensive reasoning and are all about winning, saving face, and convincing others. Some of his students and colleagues at Action Design use the term "Mutual Learning" for this type of conversation, which describes it well.

InfoQ: How can we improve our conversations?

Fredrick: The first thing to do is to recognize that we need to improve them in the first place!

Squirrel: Yes, when we describe productive reasoning most people say, "Yes, my boss needs that" or, "I think we should train our product managers to use it." But in fact, each of us is having unproductive, defensive conversations, and we need to start with ourselves. It’s threatening to admit that you might be contributing to the situation that is frustrating. At the same time it’s liberating to realize that you are partially at fault because it means you can do something about it.

Fredrick: Once you’re ready to take a look at your own behavior, the only materials you need are a pen and a piece of paper. We lay out a process, called the Four Rs, that let you analyze and improve your conversations. You’ll Record a conversation, Review it using one of the tools we provide in the book, Revise it into an improved form, and then Roleplay the improved conversation so that you can get used to talking in this more productive way.

InfoQ: How can we better recognize situations where trust is low?

Squirrel: First we suggest you try to understand the stories you and the other person are telling yourselves about the situation. For instance, if you are doing contract work for a client and your relationship is fractious, you might believe that your client sets unrealistic deadlines cavalierly, while your client might believe that you’re not committed to their success. That would be an example of unaligned stories, or low trust. As we say in the book, it’s as if Ptolemy, Newton, and Einstein all got together for a trip to Mars! Their different stories about how the universe works means that no amount of process innovation or clever tooling is going to get that rocket to the right destination, not until they talk through their stories together.

Fredrick: That’s right. We unconventionally define trust as the state where your stories are aligned. You don’t need to have the same stories - for example, you might very well trust that your client is going to ask you for targets that are far too aggressive - but both parties’ stories need to be explicit, discussable, and comprehensible to the other. Once you understand the other person’s story, behavior that was previously threatening becomes understandable and seems much more reasonable, even if you still disagree.

InfoQ: How can aligning stories help to increase collaboration?

Fredrick: Once you trust each other and have aligned your stories, you have a common basis to work from; without this, effective collaboration is impossible. In the client-contractor example, when each of you believes the other doesn’t care, you won’t even look for better outcomes.

Squirrel: Why would you bother? The other guy is out to get you.

Fredrick: That’s right. Whereas when you’ve aligned your stories, you will have a common foundation to build on, which allows you to work with the client to adjust scope, prioritise features, or consider a technical shortcut.

Squirrel: Of course it’s not at all obvious how to actually align your stories once you find you’re in a low-trust situation! We spend a whole chapter of the book describing detailed steps to accomplish this, using a method called "Test-Driven Development for People", also known as the "Ladder of Inference".

InfoQ: How can we apply coherence busting to have conversations about the things we fear?

Fredrick: Fear narrows our worldview. It makes us uncreative. Coherence busting helps us break out, become more curious, and realize there are more options we can explore. For instance, we tell the story of an executive who felt trapped by her fear that her software team would miss deadlines, leading to disastrous financial losses. She believed that the developers were incapable of understanding business needs and setting appropriate targets, and worse yet, that discussing it would anger the developers and make them even less productive. This affected her so much that she had physical symptoms of fear, like heart palpitations, after prioritization sessions with her CTO.

Squirrel: We were able to help her to use Coherence Busting to look for other explanations besides developer indifference. Among other alternatives, she came up with:

  • The engineers are secretly working for an evil supervillain bent on destroying the company.
  • They don’t understand the importance of the features.
  • They don’t have the experience to make good estimates.

Fredrick: It’s very helpful to have an alternative that is absurd and humorous, like the one about the supervillain. Laughter is neurologically incompatible with fear, so when you consider a ridiculous option, you immediately reduce your fear and increase your curiosity. Having a list of several options, all incompatible, helps you get to a curious mindset that makes your conversation much more productive.

Squirrel: The executive was able to use that curiosity to share her fears and explore other options in her next prioritization session, and she and the CTO discovered an alternative approach that would reduce delivery risk significantly.

InfoQ: Knowing why something needs to be done empowers people. Simon Sinek tells us to start with the why. What's your take on this?

Squirrel: He’s wrong! Starting with why is disastrous, because you haven’t built a foundation of trust and reduced fear that makes your communication about purpose effective.

Fredrick: We’re not quite being fair to Sinek, as he does suggest that you need a trusting relationship with your organization before you can form a common purpose. But like most business authors, he doesn’t tell you how to do that. We give you specific steps and examples that first build the foundation of trust, and then let you jointly design a Why that everyone is internally committed to.

InfoQ: How can managers and teams collaborate to jointly design decisions?

Squirrel: Start by making sure each participant adds an egg.

Fredrick: Squirrel’s referring to a well-known story we re-tell in the book, about how cake mix didn’t sell well in the 1950s until the manufacturers removed the egg powder and added the words "Add Your Own Egg" to the box. Just pouring water into a bowl didn’t feel like baking, but if you had to actually locate, break, and mix in an egg, it changed the psychology. Now it was your cake, something you were part of. Sales took off as a result.

Squirrel: The same psychology operates when your organization makes a decision: you’ll only have internal commitment if the team is part of the decision making. In the book, we give specific guidelines for helping your team to "add their own egg" as they discuss important decisions, including inviting opposing views, timeboxing the discussion, and establishing a decision-making rule.

Fredrick: That last one is particularly important; joint design isn’t another name for consensus or democratic decision-making. Not every participant should have veto power or the ability to force through their view. The goal is to ensure you have everyone’s contribution, that they know they’ve been heard, and still get to a decision efficiently. The decision can be made by a leader or an executive team, only now it will be a more informed decision.

Squirrel: The agile-killing disaster to avoid is the "management bubble", where uninformed leaders pass down well-meaning decisions without any input from those on the team. That’s a recipe for lack of commitment and failure to execute.

InfoQ: Why should we talk about accountability, what makes it so important?

Fredrick: Accountability is actually what we’ve been building towards across all these conversations. It is what allows a high performing organization to move rapidly at scale. You’ve built a common purpose, you’ve got commitment towards the goal, then you need accountability to ensure your execution is on-track and stays on-track. Being accountable means sharing your plans and later sharing the results you achieved. This sharing is essential for maintaining alignment as well as for effective feedback and iteration.

Squirrel: For us, accountability is a positive term. Unfortunately accountability has become associated with a threat, with negative results. Have you ever heard someone say, "Whom can I hold accountable for this huge success?" I’m guessing never. Instead it is used with phrases like, "Whose neck do I wring if something goes wrong?" When this is the organization's view of accountability, it is no surprise that information doesn’t flow where it is needed when it is needed. That’s what makes the accountability conversation so important, to ensure the right people have the right information at the right time.

Fredrick: Of course, you need to have a firm grip on all the other conversations as a foundation before accountability is going to work at all: trust and reduced fear to make it safe to share your message; a common understanding of why you are pursuing your goals; and a clear commitment so you know what those goals are.

InfoQ: What challenges come with being accountable and how can we deal with them?

Squirrel: The biggest obstacle to effective accountability is clarity about what you are reporting on. Far too often there hasn’t been the groundwork to build that shared understanding. Attempts to render an account fail miserably when the parties don’t have the same expectations, or even the same language for describing those expectations.

Fredrick: That’s why we recommend the briefing and back briefing technique, an idea we picked up from Steven Bungay. It fits nicely with an agile, iterative mindset because you’re frequently either briefing someone - explaining the goal, constraints, and freedoms of the work to be done - or hearing a back briefing from them, where they describe their intended action and how it fits with the briefing. This allows you to give feedback in both directions early and often, and helps keep the agile process running in the right direction.

InfoQ: What's your advice if organizations want to explore applying conversations as part of their agile transformation?

Fredrick: The most important message - besides "buy the book!" - is that it’s necessary to do the work.

Squirrel: Amen! We find it’s easy to nod along and agree that conversations are important, but it’s a very different thing to do the work to improve. Get out a piece of paper and apply the Four Rs on one of your own conversations. That’s threatening because you - perhaps an executive, or a technical lead, or a knowledgeable team member - will need to admit that you are part of the problem.

Fredrick: When leaders and teams and organizations overcome that barrier and really work to improve their conversations, the results are amazing. The improvement in alignment, speed, and quality of agile teams that use these methods is breathtaking. Changes happen very quickly when you remove the obstacles to effective communication.

Squirrel: And we’d love to hear from readers who give it a go - find us on our website.

About the Book Authors

Douglas Squirrel, co-author of Agile Conversations, uses the power of conversations to create dramatic productivity gains in technology organizations of all sizes. Squirrel’s experience includes growing software teams as a CTO in startups from fintech to e-commerce; consulting on product improvement at over 80 organizations in the UK, US, and Europe; and coaching a wide variety of leaders in improving their conversations, aligning to business goals, and creating productive conflict.
 
Jeffrey Fredrick, co-author of Agile Conversations, is an internationally recognized expert in software development with over 25 years’ experience covering both sides of the business/technology divide. Fredrick is managing director of a FinTech company, runs the London Organisational Learning Meetup, and is a CTO mentor through CTO Craft. 

Rate this Article

Adoption
Style

BT