The Push-Me-Pull-You Paradox: Self-Organizing Agile Teams

Get back to Agile basics by taking a look at these things to remember when forming self-organizing Agile teams.

Characteristics of Successful Self-Organizing Agile Teams

Ranging from 5-9 members, Agile teams are typically small. Even outside of Agile, sizing of teams is recognized as a critical consideration to the success of any endeavor that requires collaboration. For instance, when researching what makes effective teams, Wharton Business School conducted a study across academic, sports, and business teams, and concluded that 6-7 is indeed an optimal group size for best performance.

Extending this further into the Agile world, not many people realize that our most popular framework, the ubiquitous Scrum, is based in part upon the academic paper “The New New Product Development Game," written by Hirotaka Takeuchi and Ikujiro Nonaka.1 In large part the resultant paper sought to collect and codify the most effective attributes of a collaborative team.

The Self-Organizing Agile Teams MindsetSelf-organization is an important attribute of Agile teams. We often refer to this trait without fully understanding that this will emerge out of a team’s natural evolution. The goal is to leverage team spirit and practices to reinforce this approach. (decisions to info)

The Agile Manifesto is the closest thing that the Agile community has to a standard for Agility. It outlines the key Values and Principles that Agile adopters need to focus on and adhere to. It emphasizes the importance of collaboration and direct interactions that act to build a sense of team.

Reinforcing Collaboration Through Practices & Roles

Swarming commonly describes situations where the team will automatically throw themselves collectively at a problem. This manifests itself in an environment where trust has been established and the team has a common understanding and capability to work on a problem or opportunity without the need for caution or expressions of ego getting in the way. Balanced communications across the team helps establish collective ownership and sets norms around how we behave within the Team. Likewise, ensuring that needed information is visible and radiated across the Team promotes better orientation and confidence in the purpose and direction of work.

In the Agile universe, we often pay lip-service to the notion of “Servant/leadership.” This concept is most often associated with the role of the Scrum Master (SM), but it may equally apply (to a lesser degree) across the entire team. In essence, we are looking to cultivate an environment where the SM subordinates their personal interest, biases and ego to the interests, and well-being, of the team. Often the SM will increasingly adopt the role of a team coach by constantly encouraging members and relentlessly seeking opportunities for improvement. Perhaps the real goal for this important role is to act as the living embodiment of Agile values.

Building a Collaborative Culture

In concert with the team, the Scrum Master should foster and build a safe environment that is conducive to open communication. Of course, this cannot be dictated, it has to develop overtime as trust is built within a team. Effectively, the goal is to strive for a sense of “Ba” across the team. This term comes to us from Japan, and roughly translates to the idea of sharing a sense of purpose and trust in each other. Again, this cannot be mandated, it should be an outcome of the team’s journey through storming, norming, and performing.

Avoiding the Push-me by Getting to Pull-you

During the implementation of Scrum within an organization it is not unusual to see Definition of Ready (DOR) either misapplied or absent. DOR is one of the key enablers of self-organization. It is important because, when applied correctly, it can ensure that teams control which work may be included in an upcoming Sprint, and which work needs further refinement (or grooming to use the old term). This helps underwrite a healthy pipeline system where the team “pulls” work to them, rather than have it “pushed” at them by a manager. After all, it’s in nobody’s interest to force work on a team when they don’t clearly understand what is needed or expected.

So, that’s it. Not rocket science, but some recasting of very important fundamentals that underpin any successful Agile adoption. Don’t be a stranger - let me know what you think, consider using our Enterprise Agile Maturity matrix to start setting a baseline for your team, and explore how Eliassen Group can help Agile teams.

1. Ikujiro Nonaka and Hirotaka Takeuchi. "The New New Product Development Game." Harvard Business Review, 1986.