Development is a complex thing. Thousands of little pieces come to life, interact with one another, or refuse to do so for reasons we urgently have to figure out. Code is added, removed, arranged, and rearranged. There is a lot of fancy technology involved, much of which a non-tech Scrum Master can hardly understand. However, development is also about small groups of people, looking for the best solution, disagreeing, arguing, convincing, shaking, nodding, and shrugging. At times, agreeing on how to proceed seems to be the most complicated part of it. So, how can developers come up with decisions together, and thrive as a team?
Learning one: It’s about transparency
Due to its inherent complexity, decision-making in development often is not about being right or wrong, but more about being transparent along the way:
-
Knowledge: Did the team consider the available information already? Can somebody inside the team share information that would be helpful? Can we reach out to somebody who knows more about this thing that drives us crazy?
-
Gaps: What don’t we know? What do we have to find out? What don’t we have to find out?
-
Assumptions: Is a specific argument informed by an underlying assumption we may not be aware of? What experience have we made in the past that influences the way we see and discuss it today?
-
Roles: Different roles in agile teams have different decisions to make. Do we really have to discuss why to do something, or could we just wait for the Product Owner (who, of course, is on vacation exactly in the moment, this nerve-wracking topic comes up)?
-
Opinions: What does the team as a whole think about it? In most teams, there are more and less active speakers. What do those think that are not too eager to express themselves constantly? What is the reasoning behind differing opinions?
-
Reasons: Are we able to identify reasons behind the problem we observe? Maybe we can agree on those? If we could come up with possible reasons, we may already start to talk differently about it, or even change our assumptions and opinions?
-
Options: When it comes to possible actions, what are the options at hand? Have we thought of every possibility? In the discussion, we may answer with a firm “yes”. Deep inside, however, we know, there are always more.
Learning two: Make it visual
It is helpful to visualize all those knowledge gaps, assumptions, and roles, but most importantly opinions, reasons, and options:
-
Opinions: To make opinions transparent you could try a Fist-of-Five vote in which all participants silently state how much they like or dislike an approach. Everybody shows their fist within a scale of zero (you show your fist) and five (you show all five fingers), whereby zero would mean something like “this is the most awful idea in the world” and five would express manic excitement about the suggested path. Such a vote makes subjective positions in a team visual at once and leads to follow up conversations, in which those who gave a very low rating will be able to express their concerns.
-
Reasons: In many discussions, we tend to quickly talk about solutions. What I find fascinating is how helpful it can be to take a minute to visualize potential causes. Quite often in retrospectives, topics come up that are not really interrelated at first, but if the team tries to group the topics together, it is able to identify a common cause.
-
Options: In many conversations, speakers present ideas that go away quickly, if they are not immediately supported by others. Writing down potential action items, for instance on a White Board, can help to not forget suggestions, but also to – eventually – reach a decision. But wait, how will we come to the very decision?
Learning three: Be pragmatic
Maybe we can’t. Maybe we shouldn’t. Maybe this topic we are discussing is something, we should not care about as a team, but individually. Or the extreme opposite: Maybe this thing goes beyond our scope as a team. We cannot save the world alone, can we? But maybe, it is one of those other things and we are just looking for excuses. Maybe we can, and even should reach a decision. In this case, teams may feel comfortable with one of the following principles or follow those without even being aware of it. As a pragmatist, I do not prefer one of these principles over another. To me, it really depends on the situation and the needs of the team:
-
Majority: After all, we are citizens of liberal democracies. Let the majority rule! Just be aware, experienced team members may have tried out already what you would like to vote for. It still may be valid to try again, but the very principle of majority may not fit in situations when only a part of the team has expertise in the topic. Also, it is less transparent than it appears at first, because it does not reflect how convinced this majority is about the thing it is about to push. Fist-of-Five votes can bring some clarity here as well.
-
Expertise: After all, there is always somebody who knows best. Long live our dev kings (and queens)! It just makes sense to rely on the insights of the team member with the greatest experience, especially in situations, in which nobody else has tried something similar before. However, the team as a whole still has to own the decision. Are we willing to do this thing which they consider right, or are there objections we should hear? Also, other team members may be involved in executing what we are about to decide.
-
Consensus: After all, this is tricky stuff, with multiple angles and facets, and we will have to solve it together anyway. We should not proceed, until we are all on the same page! I think, however, teams most importantly need consensus in situations that change the nature of the team. For instance if new team members are about to join or new workflows are established that affect everybody’s work tremendously. In such crucial situations, it makes sense to take doubts particularly seriously. We could explore what all of us need to be able to agree to something that, despite the objections, still would be important. There is less bargaining and convincing in dev teams than, let’s say, in EU politics, but some negotiation towards consensus can still be useful. If the doubts remain, however, maybe it was not the right choice for the team to make from the beginning.
-
Consent: When I prepared this blog post, I tried to remember the underlying principle of most decisions my teams made so far. It was none of the latter, but this one. Often, when we discussed a subject for a while and already reflected on underlying causes, we wrote down what somebody just suggested, as if this was an action item for the next Sprint. Sometimes, somebody objected, sometimes somebody suggested small changes in the wording, sometimes nobody said anything. Consent is reached in this particular moment, when nobody objects anymore. Of course, there still may be hidden arguments and objections we did not explore in-depth. However, it still is a great way to proceed because it prevents us of getting stuck in decision-making – which brings me to my last learning.
Learning four: Do it
If I had to guess percentage wise, then 50% of the decisions in which I took part so far were reached by consent, 25% by expertise, 20% by consensus, and 5% by majority vote, maybe even less. Quite often, it was a combination of the first three. I am not sure, because in the end these principles are less important than what follows next. Since self-organized teams mostly work in inspect and adapt cycles, the scope of potential consequences of a wrong decision is considerably lower than in other work environments. Couldn’t we just try it out in the next Sprint? How big a risk would it be if we did? It is difficult to be empirical in such a radical way. In our mind, we may still be afraid of potential long-term ramifications. Also, we really like to win an argument. However, by taking such an approach, we enable ourselves to make possible outcomes of decisions transparent quickly and inspect and adapt as needed.
About the author
