Self Organizing Team
In our previous posts, we have emphasized the importance of a self organizing team. Self organization is a simple concept.
- A team is formed and a deadline is worked out.
- The team picks up what it can do in this deadline and off they go building what they committed and at the deadline, they demonstrate working software.
- During the time period between commitment and deadline, the team works together, finding out how they want to track progress, develop, collaborate, divide tasks and everything else that needs to be done to meet the deadline.
The key question is why would this work? It does because the commitment is team’s commitment. In traditional management styles, the management negotiates a deadline, commits the same, decides what all should be done in this time and then tells the team to go do it. This is a bit counter intuitive. The people who are doing the work should know the best on how to do it and how much time it will take to do it. Another reason why this works is because the team has a deadline to deliver quality working software. This means anything that does not contribute towards this end mission [any practice, any team configuration, any team member] is gradually taken out. This also works because the feedback loop is now directly between the team [responsible for building the right product] and the product owner [responsible for constructing the right product feature set].It is important to understand what does “Left Alone” mean here. The team is Left Alone in the sense that no one tells them what methodology to use to transform the requirements into functionality and there is no one but the team to blame if the team fails and also there is no one to bask in the glory other than the team if it succeeds. It is solely and utterly the team聮s responsibility to figure out what to do, and to do it. However, there are some basic checks in place - they have to deliver what they commit or let the product owner know if they won’t be able to [and this should happen less and less as the project progresses] and they can ask the management for help in meeting their target [more people, training, removing obstacles etc.] Other than that the team collectively brainstorms and works to meet its commitment. The team self-organizes.
Now that we have discussed, what self organization is, it is important to note some Scrum and XP practices which help foster this self organization.
- Whole Team - The whole team is “whole team”. Everyone required to be involved in converting the features into functionality is a part of the team. If it means copywriters, designers, developers, testers and business analysts all have to be in one team - then that is it. The team also includes the Process Coach or Scrum Master. There may be a a manager as well who would be responsible for logistics, communication and coordinating activities. The idea of the Whole Team comes from eXtreme Programming. XP in fact goes a step forward and also includes the customer as a part of the Whole Team.
- Generalists - A team with Generalists [sharp, efficient, collaborative people] tends to better at self organizing. Why would this be so? This is because the team picks up work, identifies what is needed and sometimes something would be needed and on other times, something else. For instance, on some days, you might need more testers and on some days more analysts and on still others, more programmers. Specialists are unable to change gear while generalists [assuming your hiring practice is good], are able to change gear and collaborate to get things done. This is in keeping with the notion of creating a champion team rather than team of champions.
- Daily Stand Up - The daily stand up is opportunity for the whole team to collaborate and check the progress. They also identify where the most effort needs to be put in and if they are on the target to achieve their goals.
- Big Visible Charts - This is not something we have discussed so far. However, this is a powerful unifying tool. The team sees at all times, what is pending, what has been done and what is still pending to do. This allows them to plan their work better and also volunteer for more work and see who needs help. It is useful to note that if the team knows that either all of them fail or all of them succeed, big visible charts help the team see the tasks that are still to be done and plan for them.
- Flat Hierarchy - It is pretty obvious that if the team is left all to itself but one or two people are deciding what they should do and how they should do it, the team would fall into command and control again. Rather, the team has to be like a crack sports team which can organize itself beautifully depending on the current match situation.
Now that we have discussed about self organizing teams, it is important that we understand when is the team self organizing.聽 As per Wikipedia, self-organization is a process of attraction and repulsion in which the internal organization of a system, normally an open system, increases in complexity without being guided or managed by an outside source. Self-organizing systems typically (though not always) display emergent properties. A key characteristic that is generally overlooked is that “something is self-organizing if, left to itself, it tends to become more organized.” A team would not inherently become more organized if left “totally” on its own or without components that we talked about earlier. Without proper leadership or an organization structure that does not support self organizing teams, this would not be possible. Also, the move towards self organizing teams is an ever evolving theme and any equilibrium would be temporary. A single most important fact which management in Agile needs to learn is how to create such self organizing teams/ units. We will touch on this in our next post.
Popularity: 49%
Posted on April 21st, 2008 by admin
Filed under: Collaboration, Maturity, Practices | No Comments »
