"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
"The best architectures, requirements, and designs emerge from self-organizing teams."
These are the two Agile principles that emphasize the importance of self-organized teams for the success of a project and team. Numerous studies and research projects prove this as well. But forming a self-organizing team (or, to put it correctly, allowing a team to self-organize) is not that straightforward. Especially when the team was previously commanded and controlled, the general tendency is to wait for instructions than figuring out ourselves. If we have such a team in hand, what do we do? Can we safely assume that after educating them about Agile principles and practices, they will automatically align themselves?
As is often quoted, Agile needs a servant leader who serves the team, rather than the other way around. She only needs to nudge the team when required, rather than directing them at every turn. Ultimately, we want to be there — but self-organizing may not be the right starting point for a team that is new to Agile. This team would want direction, perhaps due to the aftereffects of the previous command-and-control structure. This team could be afraid of Agile and the changes it prescribes. Most important, this team may still think that big up-front documentation, working in batches, and strict segregation of duties are the best ways to go.
If we ask this team to organize itself, chances are that it will slip back to its old way of doing things. For example, team members may think that software development should still follow a linear approach within an iteration. Although results from immediate iterations would prove them otherwise, they may still see this as a failure of not executing the linear approach correctly, rather a failure of the approach itself. In some cases team members may customize the practices so that they don't get dragged out of their comfort zones. This makes a breeding ground for most anti-patterns. Old habits die hard, and the leader can't take chances by just giving some advice and letting the team correct itself. The team definitely needs a leader who guides them through the details.
This is where the analogy of Shu-Ha-Ri of martial arts can give us a better understanding. A student would go through three stages of learning:
- Shu: This is the initial obedient stage, when the student just follows the rules.
- Ha: The student questions the rules, understands their importance, and makes innovations within the rules.
- Ri: The student breaks the rules and creates his own rules, thereby escalating to the master level.
In new Agile teams, there will be a lot of directives and hand-holding during the initial period of learning. The team may be asked to simply follow the practices for a while and see the benefits for themselves. Old habits need to be broken, previously anxiety-producing work (for example, builds) needs to be done often, tests should drive development, and so on. The leader guides the team through its decisions and subtly demands that they try to practice with intent at least once before giving up or customizing the methods.
After a few iterations, the team may now question the practices and validate earlier beliefs about Agile. The team can customize a few practices to its needs, as team members now have firsthand experience. This pure experience provides the right knowledge to customize, without reeling off into anti-patterns.
The later stage is where the team is fully ready to embark on the self-organizing journey, which requires defining its own rules. The team can now let go of some practices and invent something new to meet its goals.
Self-organizing teams are our destination. However, the journey to this destination requires guidance from a leader who understands Agile and how to influence team behaviour so that it doesn't stray away from Agile principles for too long, and so that it recovers more quickly in the journey toward attaining its goals.