When developing a software application there are typically several possible solutions for a given set of requirements. Often the “best” solution isn’t immediately obvious causing intense debates among team members with strong conflicting opinions. Rigorous debates are actually a normal healthy part of the creative process. The best solutions often result from the combined analysis of diametrically opposing viewpoints. However for the sake of team morale it is critically important that team members agree to follow specific guidelines while debating. In this blog entry I present some guidelines I’ve found helpful for engaging in intense debates while maintaining team respect and cohesiveness.
The first (and perhaps most important) guideline team members must agree to follow is that debates must always be civil. But what exactly does “civil” mean? This article provides one answer in the form of a “disagreement taxonomy”. In our case civil debate means that members must agree to refrain from comments that could be classified as DH0 (name calling), DH1 (Ad Hominem), or DH2 (Responding to Tone).
Assuming that given practice team members learn to debate at levels DH4 and above, the next step is to help participants remove egos from the debate. It’s human nature for participants to become personally invested in the outcome of a debate. However even with the best of intentions it’s often easy for a participant to become polarized such that the positive aspects of a position are emphasized while negative aspects are minimized. Perhaps there are other issues of which a participant is unaware. Or perhaps a participant has made unfounded assumptions or inaccurate value judgments. In any case it’s important to remember that each participant is working towards the best interests of the project.
What I’ve found as a key to successful debates is to change the debate dynamics away from “my position verses your position” to instead ask “what are the possibilities?” and then “what are the pros and cons of each position?”. The first step is for team members to simply list the various positions without regard for which position is the final answer. Once everyone agrees that the list contains all possible positions the next step is for participants to list the pros and cons of each. Usually the proponent of a position will emphasize the position’s positive aspects; the opponent of a position will concentrate on the negative aspects – but that’s OK. This “adversarial” process will help make sure that both the positive and negative aspects of a position are fully covered. Often during this process additional information will be discovered of which either the proponent or opponent is unaware. In many cases debates will abruptly come to an end as a previously unknown piece of information comes to light. Other times debates are resolved quickly as the positive aspects of a particular position start to significantly outnumber the positive aspects of other positions. However there are times where two or more competing positions have an equal number of positive and/or negative aspects. When an answer is not clear-cut (which in my experience rarely happens) participants agree to abide by the decision of the debate judge, usually the product owner or project chief architect.