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?
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