Agile Zone is brought to you in partnership with:

Daan is a software developer with a strong focus on interaction design. Mainly developing in Java. He likes Agile methodologies, and has worked many years with Scrum. Besides work, he absolutely loves experimenting with new (or old!) technology. Daan's blog can be found at http://stuq.nl. Daan has posted 8 posts at DZone. You can read more from them at their website. View Full User Profile

3 risks with Agile decision making

06.24.2010
| 2395 views |
  • submit to reddit
Agile teams are generally cohesive and are empowered and expected to make day-to-day decisions. A large part of empowerment in Agile methods is that the team makes the decisions, not the project manager. However, there are some risks involved with this type of decision making. In this article I describe some possible risks.

Group think

The first risk in decision making is group think.

Group think has the following symptoms:

  • Little or no consideration of alternate plans
  • Risk is not assessed
  • No review is taken of rejected plans
  • Advice from outsiders is not sought
  • Facts that support the plan are acknowledged, facts that do not support the plan are ignored
  • Contingency plans are not created

Surprisingly, synergy and loyalty to each other and to the team leader are a team’s greatest qualities, however, they are the same factors that lead to group think.

Abilene Paradox symptom

The second risk in decision making is the Abilene Paradox symptom.

The Abilene Paradox symptom has the following symptoms:

  • Members, as individuals, privately agree on the correct decision to make. This is not shared with the group.
  • Members, as individuals, privately agree on how the problem or situation being addressed can be resolved. This is not shared with the group.
  • Instead of communicating their views, members keep their views and reservations to themselves, agreeing with views they are opposed to. As the individuals have not presented their views and reservations, a collective decision is made that is actually contrary to the views of all members.
  • Members feel frustration, even anger, at this and find someone, or some people, to blame.

The Abilene Paradox is real. How often have you agreed to a suboptimal solution? What if every other team member felt the same way about this solution?

Decision hijacking

The third risk in decision making is decision hijacking. This happens when for example a developer implements features that are not needed right now. The developer hijacks the decision to implement these features.

Example during daily stand-up:
Developer: The customer databases will be used by several applications, so I have implemented support for dealing with various technologies, including Oracle. It took a lot of time. Scrum master: Did we not agree on postponing this? Developer: We need this later and now it is done.”

Decision hijacking is a big problem because the decision making itself is removed from the team as a whole. This behavior has a big impact on trust within the team.

Solutions

Conflict in Agile software development projects can be beneficial to both process and product.

The literature proposes some solutions to the problems with decision making described above. These solutions are based on the existence or stimulation of intra-group conflict:

  • Separate groups should be formed, under different leaders, to propose solutions to the same problem (groupthink)
  • A devil’s advocate should be appointed (groupthink, Abilene paradox)


For the decision hijacking risk, make sure that developers are on the same page. Working together as a team means taking decisions together.

Sources:

  1. McAvoy, John, en Tom Butler. “The role of project management in ineffective decision making within Agile software development projects.” European Journal of Information Systems 18.4 (2009): 372-383. Web.
  2. Moe, Nils Brede, Torgeir Dingsøyr, en Tore Dybå. “A teamwork model for understanding an agile team: A case study of a Scrum project.” Information and Software Technology 52.5 (2010): 480-491. Web.
References
Published at DZone with permission of its author, Daan van Etten. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)