Skip To Content

Agile Experiments in Self-Organization | Project Research Institute

Agile Experiments in Self-Organization

T Mengel's post Leadership in Project Environments suggested teams self-organize to cope with the increasing complexity of projects. For some time the Agile community has been experimenting with self-organization and empowerment generally. In this post describe some of the agile experiences with self-organization and highlight the danger of it becoming simply anarchy.

The first value of the Agile Manifesto states that, although processes and tools are valued, individuals and interactions are valued more. One of the Principles Behind the Agile Manifesto elaborates on the focus on individuals:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

At the heart of this principle is empowerment of the individuals on the team and in the Agile community empowerment is often equated with self-organization. The Principle Behind the Agile Manifesto mentioned self-organizing teams but it is compulsory part of the Scrum method (Schwaber, & Beddle, 2002). Scrum was inspired by the paper The New New Product Development Game in the Harvard Business Review (Takeuchi & Nonaka, 1986). Takeuchi and Nonaka commented on the self-organizing nature of the top product development teams they studied. The founders of Scrum took the Takeuchi and Nonaka observation and made self-organization mandatory for Scrum teams.

The founders of Scrum are also quite explicit what they mean by self-organizing and this is perhaps more extreme than some companies would be comfortable with. According to the article Agile Processes and Self Organization to be self-organizing means to be:

Left alone! No one to tell the team what to do? No methodology to tell the team how to transform the requirements into functionality? No one to blame if the team fails? No one to grab the glory if the team succeeds? That is right, left alone.

Self-organization is meant to result in high team morale, teams taking responsibility, faster decision making, empowerment, and buy-in (Hoda & Derby, 2011). What is less clear are the realised benefits of self-organizing Scrum teams. Unfortunately researchers of Scrum often take the benefits of self-organization as self-evident and instead focus on how to facilitate self-organization (see for example Hoda, R., Noble, J., & Marshall, S., 2010; Moe, Dingsøyr & Dybå, 2008; Moe, Dingsøyr & Kvangardsnes, 2009).

The Poppendieck's (2010), themselves respected Lean-Agile authorities, have observed that self-organization does not necessarily lead to successful agile projects. In fact there are known down sides of Scrum self-organization. Hoda and Derby (2011) listed four undesirable outcomes: poor performers hide, lack of context leads to poor decisions, teams churn, and managers feel left out of the loop. In addition, in a self-organising team, where people are interchangeable, employees may end up doing jobs for which they are unprepared or disinterested in (Buckingham & Coffman, 2001).

Scrum gives managers an insignificant role reflecting a general anti-management theme within the Agile community (see Esther Derby on “We don’t need no stinking managers”). Formal leadership roles within a Scrum team, such as they are, are meant to be Servant Leaders; this, broadly speaking, means supporting the other members of the team in getting the work done and reflects the general trend in management away from command and control. The big difference is for managers outside the Scrum team. As mentioned above, these managers are meant to leave the team alone. No wonder that "Mangers feel left out of the loop" and there is Lack of context leading to poor decisions.

Jim Highsmith (2009), another agile authority, believes this style of leave-the-team-alone self-organisation is anarchy in a more palatable guise. Jim thinks anarchic self-organisation misses the original point which is really about empowerment. In his article No More Self-organizing Teams Jim argues that empowerment comes through delegation of decision making to the lowest level. Agilists believe in simplicity (Principles Behind the Agile Manifesto) and Jim's view of delegation may be the simplest route to empowerment.

Lewin (2000) argues that although managers have to give up the illusion of control they cannot stand back and wait for the right solution to emerge. Too little control is as bad as too much control. In other words leaving the team alone isn't the answer. Even in the study by Takeuchi and Nonaka (1986) that inspired Scrum management exerted "subtle control" including selecting the right people for the project team and managing the difference in rhythm through the development process.

In fact senior managers may need four control levers in the context of empowered employees defining the way they work (Simons, 1995):

  • Diagnostic control systems ensure goals are being achieved efficiently and effectively
  • Beliefs systems communicate core values
  • Boundary systems establish the rules of the game
  • Interactive control systems enable pro-active responses to threats and opportunities

Generally Lean-Agile's emphasis on people and empowerment is commendable - the focus on interactions and willingness to delegate responsibility where it belongs. However, in part this post is a cautionary tale. Self-organizing teams, although topical, are a two edged sword and may not provide the benefits hoped for if taken too far.

References and Further Reading

Agile Manifesto

Agile Manifesto: Principles Behind the Agile Manifesto

Derby, E. (2011). Rethinking Managers Relationships with Agile Teams. Author.

Highsmith, J. (2007). No More Self-organizing Teams. Cutter Consortium.

Highsmith, J. (2009). Agile Project Management (2nd Ed.). Addison-Wesley.

Hoda, R., & Derby, E. (2011). Self-organizing Agile Teams beyond the buzzword. Proceedings of XP 2011. [Available on-line]

Hoda, R., Noble, J., & Marshall, S. (2010). Organizing Self-Organizing Teams. ICSE '10 Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering, 1. NY: ACM.

Lewin, R. (2000). Complexity: Life at the Edge of Chaos. University Of Chicago Press.

Mengel, T. (2011). Leadership in Project Environments. PRI.

Moe, N. B., Dingsøyr, T., & Dybå, T. (2008). "Understanding Self-Organizing Teams in Agile Software Development". Proceedings of the 19th Australian Conference on Software Engineering, 76-85. IEEE: Australia.

Moe, N. B., Dingsøyr, T., & Kvangardsnes, #x000D8;. (2009). "Understanding Shared Leadership in Agile Development: A Case Study," 42nd Hawaii International Conference on System Sciences, 1-10.

Poppendieck, M. & Poppendieck, T. (2010). Leading Lean Software Development: Results are not the Point. Addison-Wesley.

Schwaber, K. (n.d.). Agile Processes and Self Organization. Control Chaos.

Schwaber, K., & Beddle, M. (2002). Agile software development with Scrum. NJ: Prentice Hall.

Simons, R. (Mar-Apr 1995). Control in an Age of Empowerment. Harvard Business Review, 80-88. [Available on-line]

Takeuchi, H., & Nonaka, I. (January–February 1986). "The New New Product Development Game" (PDF). Harvard Business Review

The Institute

The newly created Project Management Research institute provides a focus on collaborative research excellence in project management. Read more..