Collaborative Decision Making and the Impact of Scrum

Team self-organization is one of the key principles [1] of Scrum and its introduction to an organization raises a number of interesting questions around decisions and decision making. Specifically, the introduction of Scrum leads to consensus-based decisions by the team. I believe that the consensus model of decision is superior the an authoritarian model and results in superior decisions and better information.

What does “Team self-organization” mean?
It generally means that the team is given the authority to make decisions on what to do and then to act on those decisions. In other words, it means that decisions are delegated down the corporate hierarchy and are made by the same people who do the work.

“It is solely and utterly the team’s responsibility to figure out what to do, and to do it.” -Ken Schwaber [1]

As an example, whereas I might have said to the team, “You need to use a Model-View-Controller (MVC) pattern to build the application,” I now need to leave that decision to the team. There may be a very real and valid reason why the team may consider another pattern.

This delegation of decision making can have unforeseen consequences in an organization. There are frequent concerns which are often expressed by the question: “How can teams be relied upon make the right decision?”

This question itself needs exploring. Firstly, what is meant by the “right” decision? When I, as an individual, say that a colleague made the “right” decision, what I’m saying is that, given similar circumstances, I would have made the same decision as they. When I ask, “How can we be sure that the team makes the right decision?” what I’m really saying is “How can I be sure that they make the same decision as I?”

Quite simply, I cannot.

While asking this question might give me some comfort, it is not a productive question for a number of reasons: It assumes that I have all the data that the teams has access to and that the team will collectively follow the same logical steps that I have. Both of these are unlikely, if not impossible.

Trust but verify.
If asking “How can I be sure that the team makes the right decision?” is not a productive question, then what is? I personally like the question: “Is the team adding value to the final product at the end of very sprint?”

“Trust but verify” -Ronald Reagan

Scrum requires a great deal of personal trust, but at the same time that trust must not be given blindly. I trust that the team will do their best and make the best possible decisions that they can with the information that they have. At the same time, I need to verify that the teams actions are congruent with the information they’ve given me.

I trust that the team is making the “right” decision, but I reserve the right to verify what they claim to be true.

Consensus decision making.
Not only does Scrum introduce a different view of the rightness or wrongness of decisions, it also impacts the decision making process itself.

Teams are typically consensus decision making environments. This is important because consensus decision making has characteristics that are different from authoritarian decision making.

“Consensus decision-making is a decision-making process that not only seeks the agreement of most participants, but also to resolve or mitigate the objections of the minority to achieve the most agreeable decision.” -wikipedia [2]

Detractors to consensus decision making often refer to it as groupthink[3]. Although groupthinking can occur with teams, there are simple and effective ways to ensure that this doesn’t happen. Supporting an open environment where all points of view are given due consideration or appointing a Devils Advocate [3] are two such methods.

The strongest criticism of consensus decision making is that it’s inefficient.

Is consensus decision making inefficient?
Authoritarian decision making can be very rapid. In contrast, consensus decision making can take a substantial amount of time, especially if there are well informed but differing opinions. I have observed, however, that discussing the different positions increases the general understanding of the whole team resulting in higher quality decisions and better information.

But let us consider the question more closely. What is meant by “efficiency”? If by “efficiency”, we simply mean the time between making a decision and acting upon it, then I believe the answer is clearly “Yes, consensus decision making is more inefficient.”

If, however, by efficiency we mean “making well informed decisions based on a wider set of knowledge to best meet the current conditions,” then I believe that the team-based consensus approach is a far more efficient (and robust) model.

Summary
By introducing Scrum to an organization, principles of team self-organization are also introduced. The consequences of doing this are not always immediately obvious and will eventually impact not only how an organization makes decisions but also how those decisions are viewed and verified.

Given the opportunity to self-organize, a Scrum team will naturally trend towards consensus decision making, enabling them to make higher quality and better informed decisions.

References
[1] http://www.controlchaos.com/download/Self%20Organization.pdf
[2] http://en.wikipedia.org/wiki/Consensus_decision-making
[3] http://en.wikipedia.org/wiki/Groupthink
[4] http://en.wikipedia.org/wiki/Devil%27s_advocate

Download the PDF version: Collaborative Decision Making blog

Posted in Agile
4 comments on “Collaborative Decision Making and the Impact of Scrum
  1. Anonymous says:

    I am making the assumption based on my epxerience, that in most organizations, management at the execution level tends to use Consultative decision making rather than consesus decision making. Consultative decision making, in my opinion, helps especially because businesses are living on the edge of leading technology and to reach consensus to make a decision in such a case, it will take a lot of time and hence to loss of window of oppurtunity to act.

    Also, I am not sure the team is aware of all the information for the best informed decision making in consesus decision making. Especially a team developing a sub-system of a super-system, or a development team that delivers to a manufacturing team, is not aware of the business case. In this scenario, a scrum team’s consensus based decision making will not be right. Here again consultative decision making may be better.

    Also, consensus based decison making, in most cases spends time in resolving or mitigating the differences of the minority. Generally, in an organization, ability of a team member to make the decision and make it stick depends on the authority, trust, respect or combination of the 3. Of the 3, authority appears to solve the problem faster (in time), especially with the organization cultural value of “disagree and commit” (a give-away phrase for where I work). This again can be achieved by consultative decision making easily and also leads to faster decision time.

    Just to note from the article, the article has left the question of inefficient decision making with respect to time through consensus based decision making unanswered. But this is the crux of the probelm, especially because technology changes fast and hence organizations have to be on their toes. They cannot be spending time in consensus building, but in action, be it right or wrong. And the right or wrong decision making will be better made in consultative decision making.

  2. Kane Mar says:

    Thank you for the comment. I don’t often receive comments that are really, really difficult to reply to, so I appreciate the opportunity to revisit my thoughts and think them through more concretely.

    To summarize my response [so that you don’t have to read all the gory details if you choose not to], I absolutely agree with your position that consultative decision making is effective; it’s an approach that I frequently recommend.

    At this point, I have to make an assumption. The assumption that I’m making is that, in your current organization, it is management who seeks out the consultation and eventually make the decisions. I would encourage the *teams* to seek out the consultation and eventually make the decisions.

    Here is my full response:

    >I am making the assumption based on my experience, that in most
    >organizations, management at the execution level tends to use
    >consultative decision making, rather than consensus decision making.
    >Consultative decision making, in my opinion, helps especially because
    >businesses are living on the edge of leading technology.

    I would certainly agree that “… in most organizations, management at the execution level tends to use consultative decision making rather than consensus decision making.” This has also been my experience with the existing decision making structures within companies.

    I believe that Consultative decision making is very important and I often recommend it to Scrum teams. The important point is that the *teams* are seeking that advice and they are the ones who make the decisions.

    >and to reach consensus to make a decision in such a case, it will take a
    > lot of time (and hence a lost window of opportunity) to act.

    This is only true if the decisions are made by a select group (e.g., Management, Architects, etc.), in which case you are probably quite correct. However, it’s been my experience that, if the information and authority is made available to the teams they will absolutely make informed and timely decisions. Once they realize that they have the [decision making] authority they will absolutely exercise it.

    In practice, I have never seen an opportunity lost due to a team’s failure to make a decision. I have, however, seen opportunity lost due to an organization’s inability to respond quickly [to that decision].

    >Also, I am not sure the team is aware of all the information for the best
    >informed decision making in consensus decision making. Especially a
    > team developing a sub-system of a super-system, or a development
    > team that delivers to a manufacturing team, is not aware of the business
    > case. In this scenario, a scrum team’s consensus based decision making
    > will not be right. Here again consultative decision making may be better.

    I would suggest that this is an excellent point on which to execute Scrum’s inspect-and-adapt strategy. I would ask questions such as “Why is the team not aware of all the information? What is the reason for not presenting this information to the team?”

    In addition, why is the team not aware of the business case? I’ve often asked a team’s Product Owner to present his or her business case to the team as part of the planning meetings. In fact, one particular team did this *every* planning meeting (we were using two week sprints) as the business case was evolving. It forced the Product Owner to articulate his needs and it forced the team to consider how their work fit into the larger business context.

    >Also, consensus based decision making, in most cases, spends time in
    > resolving or mitigating the differences of the minority.

    Indeed, there is far more to consensus decision making than simply resolving or mitigating the differences of the minority. Allowing [and resolving] differences help a group to explore more options and develop better solutions. When these differences are suppressed it takes the group longer to become cohesive (“Norming”).

    Consensus decision making is essential if you wish to encourage highly collaborative, high-performing teams.

    >Generally, in an organization, the ability of a team member to make the
    > decision and make it stick depends on the authority, trust, respect or
    > combination of the three. Of the three, authority appears to solve the
    > problem faster (in time), especially with the organization cultural value of
    > “disagree and commit” (a give-away phrase for where I work). This again
    > can be achieved by consultative decision making easily and also leads to
    > faster decision time.

    I absolutely agree with this paragraph. The issue, I suspect, is the company culture which puts the authority on an individual rather than the team. One of the hardest facts about Scrum is that it absolutely disrupts the existing culture. This is well recognized and Ken [Schwaber] wrote a short paper called “Scrum is Hard and Disruptive” that highlights this. (You can access it via this link: http://www.danube.com/Scrum_is_Hard_and_Disruptive)

    The “answer” is to re-shape the organization and this is a seriously difficult undertaking, as I’m sure you are aware.

    >Just to note from the article, the article has left the question of inefficient
    >decision making with respect to time through consensus based decision
    > making unanswered. But this is the crux of the problem, especially
    > because technology changes fast and hence organizations have to be on
    > their toes. They cannot be spending time in consensus building, but in
    > action, be it right or wrong. And the right or wrong decision making will
    > be better made in consultative decision making.

    That’s because the nature of how decisions are made and who makes them changes the question of “efficiency” to become meaningless. If teams have the authority to make their own decisions and act upon then, then there are many issues that will simply not be presented to management to decide upon. The team will identify the problem and resolve it themselves. What is the “efficiency” if the problem is resolved before management even knows that it exists?

    Best regards,
    Kane

  3. Mark Jean says:

    Around the Los Angeles basin, it’s clear a number of people who’ve adopted “Scrum” do so out of frustration with a senior manager or a company’s current development methodology.

    Several times I’ve heard that Scrum represents an “egalitarian” or “meritocratic” approach – that a team can use to overcome their idiot manager or out-dated processes.

    This has come up multiple times in conversations at geek “network” functions. Clearly, some people perceive Scrum as an “equalizer” of sorts.

    But – does Scrum truly represent a utopian vision of equality? Where we can all “collaborate” ourselves to success?

    Do “collaborative teams” – ones without a bozo calling the shots – work?

  4. Kane Mar says:

    There are some interesting philosophical questions here. I’m not a philosopher so I’m not going to even attempt a generic response. Instead, I’d prefer to reply in a very specific way.

    Firstly, does Scrum truly represent a utopian vision of equality? Where we can all “collaborate” ourselves to success?

    Scrum isn’t a silver bullet. It won’t solve your problems for you. It is only a very simple process for highlighting what your problems are, and raising the visibility of these problems so that they can be addressed. Many teams find that Scrum makes visible some problems that they would rather keep hidden, and aren’t willing to do the hard work necessary to adopt Scrum fully.

    Secondly, Do *Scrum* teams work?

    My experience is “Yes, absolutely.” And I believe there is sufficient evidence in the industry to suggest that Scrum is now a well accepted approach. Indeed, there is a larger body of evidence, if you wish to look further than software. The roots of Scrum come from the Toyota Production System (TPS) as describe in the article “The New New Product Development Game” [Hirotaka Takeuchi and Ikujiro Nonaka] and has been used successfully for some 30-40 years.

    Best regards,
    Kane

Leave a Reply

Your email address will not be published. Required fields are marked *

*