Leadership on a Self-organizing Team

Self-organization is at the core of a successful Agile/Scrum team. When a team is transitioning from a traditional team structure (hierarchical) to self-organizing team (flat), I have seen the team not sure how to accommodate traditional roles like team lead or architect.

Let's delve into how a traditional team works. The single point of accountability lies with a team lead who is expected to ensure the success for the team. He/she decides who does what and delegates work accordingly. Even though, a team lead may involve team in making these decisions, more often than not it is a one way street. When we are accountable for the outcome, instinctively we feel compelled to force our way of doing things. And the rest of the team takes a back-seat in the whole process.

In a self-organizing team, on the other hand, each team member is accountable for his or her work and collectively accountable for the success of the team. This collective accountability takes the center stage in a self-organizing team. There really is no single person to point finger to. As a result, the team collaboratively decides who gets to do what. It may be driven by the current skills, experience, as well as the need for cross-training and self-interest to learn new things. The leadership is not bestowed by a title, rather is earned over time through performance. In fact, the leadership becomes distributed based on specific expertise. For example, a team member might show a lot of interests in database technology. He/she establishes himself as the SME (subject matter expert) by voluntarily solving database related complex issues facing the team. Similarly, another person may show greater understanding of OO design and programming and the team might start to defer OO matters to him. By effectively bringing these individual expertise together, a team as a whole, could work as an architect and come up with a good architecture. This may not happen with a team that is working together for the first time. The Scrum Master will need to help the team become self-sufficient and self-confident to fill in the traditional roles of an architect or a team lead.

So, am I saying the need for an architect or a team lead is gone? The answer is "Yes." A team may choose to make the SMEs the spokespersons for the team for topics. The topics could be technology, or business. The SMEs will handle all questions/queries related to their own topic. It needs to be published to all stakeholders. Each SME will need to keep the responsible enterprise architect in the loop for his or her area of interest. For example, if the issue at hand is security related, the team SME for security will work with the enterprise architect.

I know you might be thinking that this is not possible on a real project. I agree it may not be the case when a project team is working together for the first time. We may need help from a solution architect who could help the team to weave all discplines into a cohesive solution. However, the goal of the solution architect should be to help the team get to a point where they can collectively drive the solution forward. The first step towards achiving this "team nirvana" is to put together a team with a collective knowledge and experinece covering all aspects of the project.