Most of the studies that discuss failed software development projects find misunderstood requirements and inadequate change management among the leading causes of failure. These failures can’t be adequately addressed just through more rigorous documentation or web based tools. Generating shared understanding is a social act – therefore, one of the elements of improving requirements is through improving the related social interactions or conversations.

But how do we go about improving conversations? Where are the engineering practices or process improvement techniques we can apply to consistently achieve improved performance? John Searles has written several books that break down conversations into a series of speech acts and even has a notation for describing a conversation. I found Searles work on Speech Acts to be very interesting. There is value in classification and understanding of patterns in conversations. But I am not sure this translates to an easily digestible approach. I also believe that conversations have flows and states, but I am also not sure that a process flow is an effective way to represent a conversation.

I can’t break the process of the flows and states a cake baking in the oven goes through down to detailed steps. I can tell you when it might be appropriate to bake a cake, when we are ready to put the cake in the oven, what happens during the baking process, and I can tell you how to check to see if a cake is done. So the approach I am advocating here is to be able to know when a specific conversation is called for, what it takes to be prepared for a conversation, how to approach the conversation, and how to check and see if the conversation has been performed.

Conversations for Shared Understanding

A conversation for shared understanding often involves one person on the project learning something new from someone else on the project. Conversations for shared understanding are important between different functional groups and when defining expected outcomes. For example, requirements documents define what needs to be done on a project. The requirements documents by themselves are typically not adequate. The gap in understanding leaves room for the development organization to build something that is not optimal either from a development or a requirement standpoint.

I love college football. One Saturday when I first got married, I was watching a game on TV. I planned to head over to my friend Steve’s house later in the day to watch the afternoon game. My wife called down from upstairs to ask me to take out the trash. I agreed to do it, thinking I could grab it out of the kitchen on the way out the door after the current game before I went over to Steve’s house. Her context was very different from mine. She meant, right now – all the trash in every room of the house – and clean the bathroom’s while you are at it. So, while I agreed to her requirements, we didn’t have a shared understanding of the request.

When is a Conversation for Shared Understanding called for?

Anytime a lack of shared understanding slows down the project or creates rework or other waste. A lack of shared understanding happens all the time in projects – particularly between functional groups and early in a project. So a conversation for shared understanding is important early in a project. Typically, these early conversations should be around the overall context and objectives of the project. A conversation for shared understanding is also called for with each specific feature or request. On software development projects it is important everyone involved in delivering, verifying, or accepting a feature or project deliverable has a shared understanding. Conversations for shared understanding should be at the outcome and context level. They are not intended for the technical implementation details to be explained to business stakeholders. The point is to establish context and understanding of the outcomes necessary to optimize the performance of the project performers.

What does it take to be prepared for a Conversation for Shared Understanding?

The mood and perspective of the participants in the conversation will impact the ability to successfully perform these conversations. So each participant must have an intention to have a conversation that results in a shared understanding. They should be willing to put in the effort to review or understand any artifacts produced to seed the understanding. They must bring a belief that the other person’s context matters. Additionally, participants need to put some thought into the boundaries of the conversation. The performer will want to think about what they need to understand to be most effective in delivering this request. The requestor will want to consider what parts of the context, what outcomes, and what language is particularly important to ensure they get what they intended to ask for.

How do we approach a Conversation for Shared Understanding?

1. The participants present their expectations and boundaries for the conversation.
2. Each participant explains their understanding of the context, targeted outcomes, and significant language. The other participant(s) will note where their understanding varies.
3. The discrepancies should be discussed, evaluated and resolved. Sometimes, the details of one participant will not be important. Sometimes, more specific discussion is necessary to gain clarity.
4. The participants will agree when they have a shared understanding.

How can we check to see if the Conversation for Shared Understanding has been successful?

At the end of the conversation the participants should be able to present an understanding of context and outcomes in common language. As soon as either participant identifies a gap in understanding they should revisit the conversation. Over time, the participants establish a common background that reduces the effort required to establish a shared understanding.

Today, when my wife asks me to take out the trash I understand what she wants. We also have identified when it may be important to have a conversation for shared understanding. For example, when she sends me to the store for milk I ask her to take a minute and think about what else I should get while I am there. My experience is that she has a lot of background information that I am not aware of. If I go to get milk and don’t get the eggs and butter she needs I will be heading back to the store. Taking the time to have conversations for shared understanding will almost always accelerate the effective pace of the project.

Knowledge based projects, like software development,  are performed by people.  So the way people learn, collaborate and interact is more impactful in knowledge based projects than in traditional projects like building a bridge or a satellite. If Agile software development and Project Management 2.0 have introduced anything new, it is an explicit focus on the social aspects of performing projects. Traditionally project management methods focused explicitly on the processes, tools and techniques of projects.

The traditional tools and processes are still important to the success of projects. We still need to clearly define scope, coordinate project resources, and manage commitments and acceptance of work. But these are social endeavors – and they can’t be accomplished with tools and processes alone. They require an intentional focus on the social aspects of the project. The shift toward the social focus is reflected in the Agile Manifesto’s first value, “Focus on individuals and interactions over processes and tools”. This shift in explicit focus is not an abandoning of processes and tools – rather an intentional focus on achieving these purposes to include people and interactions.

Project Conversations

How do we manage these social aspects? It is through conversation. Conversations are the use of language to exchange thoughts, ideas, or information. Understanding, Coordination, and Commitment within the team arise through conversations. John Searles wrote about how conversations can be defined with clear outcomes and broken into specific series of acts. Gordon Pask wrote in Conversation Theory about how understanding arises based on our interpretation of another person’s behavior.

Using these approaches we can construct ways to improve project performance through improving conversations. But, this isn’t a touchy- feely effort. For each specific conversation there is a specific set of outcomes and a specific set of “speech acts”. Intentionally deciding what conversations need to occur, when they need to occur, and what they look like when they have been completed will  improve the performance of interactions on Agile teams. Over the next week I will be discussing various conversations around understanding, committing, and coordinating. I will present a starting point you can use within your teams to have the meta-conversation to improve these conversations. Then I will build on each of these conversations at each order of scaling (small team, multi-team, program, enterprise).

This is a slightly updated presentation of a talk I gave at Atlanta’s Project Developer Days a few years ago. After attending a two day training session with Jeff Sutherland, I believe that this concept is relevant to the Agile and SCRUM Project Management conversation.  From my experience, improving the performance of the conversations on your projects greatly improves the performance of the project team. When we say we want to get better at communications, I believe we want to improve the quality and effectiveness of the project conversations. The project managers job in leading projects requires us to be good at recognizing what conversations need to take place, and facilitating them to a successful conclusion.