The Agile Architect
Conflict and Resolution in the Agile World
As much as we'd like to believe that our agile teams work in an idyllic world, there can still be divisive disagreements. How does an agile team resolve these conflicts? As usual, our Agile Architect has his own ideas.
You're in the war room working with your pair at the developer workstation when you notice that the volume in the room is getting louder and louder and louder. You look at your phone. It's only 10:30 in the morning and the fighting has already begun.
Shawn is at the whiteboard pointing at the design diagram that Chris had drawn the day before. "But you don't need a diagram in agile," he proclaims loudly. Yep, he's not arguing about the technical merits of the design. He just doesn't want anyone on the team drawing any kind of design diagram.
Chris counters with "How are we supposed to know where to start if we don't have an initial conversation?"
"I'm not saying you can't have the conversation," Shawn yells. "Listen to me. You don't need a diagram. The code will tell you what to do."
"The diagram IS the conversation," Chris cries, exasperated.
You look at your pair, sigh, and in unison you both get up and head for the break room for a cup of coffee. No one is going to get any work done this morning. Again!
Agile Means Conflict
Collaboration means conflict: Any time more than one person works on a problem, there will be disagreements about how to solve it. Whether you disagree over methodology, philosophy, tools, technology, personality or even the basic understanding of the problem, you will have to work through your disagreements to get to a solution. The more people that work together, the harder it is to get consensus.
Transparency means conflict: Agile practices place a premium on transparency. Transparency allows problems to surface and be squashed. Without transparency, problems can fester, grow and ultimately become insurmountable. But with the good comes the bad. With increased transparency, there is also an opportunity for more disagreements, and conflict within the team and with external stakeholders. The trick is to understand how much of the team's time should be dedicated to resolving the conflict.
For small issues, even an arbitrary decision is better than none. Coding conventions usually fall into this category. Developers love to argue about how to format code. In the end, the only thing that matters is that it is done with enough consistency that everyone on the team can easily read the code without formatting getting in the way.
For larger issues, the team needs a framework that is agreed to in advance for how they resolve conflicts. I touched on this a little in a previous column on Delegated Authority but glossed over details of conflict resolution.
Sources of Conflict
There are many sources of conflict on an agile team. Here is just a sample.
- Vision disagreement: What is the vision for the product, project, or organization you are building? Who holds that vision and how is it communicated to the team? When taking a whole-team approach and asking everyone to commit to the success of the entire project and not just their piece, everyone develops their own ideas about all aspects of it. This is a good thing as it makes ownership personal. However, without a way to come to consensus on the vision, conflicts will arise.
- Feature and story disagreements: Everyone on the team may have a different idea about what a story should be. Even for something as simple as logging into an app, there will be differences of opinion about whether to use a password, a passphrase, a PIN or perhaps biometrics.
- Technical disagreements: Do I really have to give an example for this one?
- Process disagreements: How does the team work together? How are stakeholders involved?
- Disagreements on how to interpret what a customer said: I'm always amazed after a demo to a customer just how many different opinions there are about what the customer said.
- Personality conflicts: Like Shawn and Chris above, people have different value systems and experiences that lead them to handle situations in varied ways. With a strong agile team, everyone wants to do what's right. But what is right?
It is, of course, better to remove the need for conflict by addressing controversial issues preemptively. That is to say, we should not avoid conflict when it is necessary but strive to make it unnecessary. We would prefer to have a collaborative, collegial atmosphere on our teams rather than adversarial.
One of the best ways to minimize conflict is to address pre-emptively the issues that often create it. There are many opportunities on an agile team to do this.
- Create a shared vision for the team: Whether you are building a product, working on a long-running project, or building your organization, creating a shared vision enables everyone on the team to understand where you are heading. The vision can't simply be imposed from above. Everyone on the team needs to buy in to it.
- Maintain a living team charter and stick to it: The team charter is a living document that describes how the team will work, similar to the U.S. Constitution. The team works according to the charter. If the charter isn't working, the team updates the charter. The important thing is for the team to hold itself accountable to the charter.
- Hold regular retrospectives: I discuss retrospectives in more detail in my article Continuous Improvement: The Importance of the Team Retrospective.
- Delegate Authority: See my article Delegated Authority: An Agile Trust Experiment
But, as we've said, conflicts will arise just the same. As much as you may want to, don't marginalize conflict. The topic at hand may not be important to you but it is obviously important to at least some members of your team.
Dealing with Conflict
There are many different techniques for managing conflict. Some important techniques include:
- Understand the roots of the conflict: What do the participants in the conflict really believe? What is their context for understanding the issues at hand? Many times conflicts arise because of a communications breakdown. They may have a different understanding of business priorities. Or they don't understand all of the benefits of a proposed technical solution. Or maybe they are blind (willfully or not) to the deficiencies of their own proposed solution.
- Understand the personalities of those involved: Only by understanding what is truly important to the people involved in the dispute can you get to the core of why they are holding on to their position so passionately.
- Find common ground: Find the areas where there is agreement to help put the conflict in perspective.
- Brainstorm creative solutions: Create a safe environment where the team and stakeholders can think of new solutions to their conflict. Standard brainstorming rules apply. No idea is too dumb or silly. Write every idea down without judging it. This can lead to a solution that makes everyone happy and that no one could have imagined earlier.
- Negotiate a fair agreement: If you can't find a solution that everyone likes, use negotiation techniques to find a solution that everyone can live with. There are many good books on negotiating techniques. One of the classics is "Getting to YES" by Roger Fisher, William Ury & Bruce Patton. I found this book very helpful in writing this column.
- Invoke authority: Ultimately, someone must have the authority to make a decision. This is necessary when a quick decision must be made or when reasonable consensus just cannot be reached. A mature agile team will rally around the decision if they feel like they've been heard.
In order to work through the techniques just described, its important to create an environment where everyone feels safe to talk without being belittled, marginalized or threatened. Bring in a facilitator who can promote a productive conversation while remaining neutral.
Conflicts must be resolved quickly, effectively and fairly lest the team become bogged down in never-ending battles, lowering morale and quickly sapping team cohesion and effectiveness.
However, new conflicts are a sign of a healthy agile team. It means that issues continue to be brought to light and the team cares about them enough to spend time discussing all sides of the issue. When no one cares, no one bothers. When the team takes the time to resolve conflicts, they become proficient at it and can move on to new challenges.
Dr. Mark Balbes serves as Vice President, Architecture at WWT Application Services, and leads multiple Agile projects for Government and Fortune 500 companies. He received his Ph.D. in Nuclear Physics from Duke University in 1992, then continued his research in nuclear astrophysics at Ohio State University. Dr. Balbes has worked in the industrial sector since 1995 applying his scientific expertise to the disciplines of software development. He has led teams as small as a few software developers to as large as a multi-national Engineering department with development centers in the U.S., Canada, and India. Whether serving as product manager, chief scientist, or chief architect, he provides both technical and thought leadership around Agile development, Agile architecture, and Agile project management principles.