September 7, 2014

The Self-Organising team is at the heart of Agile

From XP (1) and Scrum (2) we have the concept of self-organising teams. A self-organising team doesn’t need to be commanded or controlled to get its work done. This page is a discussion on self-organising teams and the opposite of the command and control top down approach.

Self-organising means that the individuals within the team organise themselves on their own. That doesn’t mean to say managers don’t play an important part in the process just that that they don’t need a manager to organise them.

How can this be?

This is a great example to show how the principles of Agile weave together to make a complete picture. Agile principles support each other and when followed together often have surprisingly good side effects.

To be self-organising, a team needs to have courage,communication and respect for each other. These are from the core values for XP (1).

To be self-organising a team must put the people in the team above their process to find what works for them. A new process can be invented to support the team but the team comes first. This means we must adhere to the first principle in the Agile Manifesto (3).

To be self-organising the team needs to know what it is organising for. It must understand the problem area and the value it is generating well enough to organise around the problems and to solve them. Therefore the team must have all of the skills needed or the ability to get those skills. Only when all areas of the problem can be dealt with by the team can the team organise without outside help. This means the team must be cross functional.
A cross functional team, or the practice of ‘Whole Team’ also comes from XP (1).

From the Scrum Primer:

“Since there are only team members, the Team is not only cross-functional but also demonstrates multi- learning: each person certainly has special strengths, but also continues to learn other specialties. Each person will have primary, secondary and even tertiary skills, and is meant to “go to where the work is”; individuals take on tasks in less familiar areas to help complete an item. For example, a person whose primary skill is interaction design could have a secondary skill in automated testing; someone with primary skill in technical writing might also help with analysis and programming.”

The problem area must also be understood from a business perspective. The team must include a representative of the business to be cross functional and to achieve self-organisation. We therefore have a Product Owner in the team from the Scrum Framework (2). Fulfilling this requirement also meets the 4th principle behind the manifesto “Business people and developers must work together” (3).

The Product Owner organises work items to highest priority order and explains their content. In a collaborative way, the team discuss the items to determine when and how to complete the work. We have the concept of a work item or story being a placeholder for conversation (5). We also have the concept of breaking down work items to low level detail at the last responsible moment. This leads us to the EPIC and high level planning and at subsequent ceremonies lower level detail (4). As the team are present at each stage, each task is a collaborative effort. Thus the team is better placed to organise itself to complete the tasks with these concepts in place.

The team commits to the delivery for each iteration as a team because the team is present at all of the ceremonies. The team collectively can commit as the team collectively has the knowledge to deliver. It is the team that decides how much it can deliver in a sprint. Estimation is more accurate because a wide range of views are present during the estimation process. This can be facilitated by the use of games such as planning poker.

The team succeeds or fails together.

The team eliminates bottlenecks from individuals being absent by all taking responsibility of delivering work items (6). Capacity may be reduced but knowledge should be shared between team members.

A self-organising team needs to keep improving and to keep motivated (7). For this reason a team should provide a forum for all members to contribute to the team’s direction. We get this forum in the retrospective ceremony from the Scrum Framework. For more details on retrospectives I strongly recommend Esther Derby’s book ‘Retrospectives – making good teams great’.

In a self-organising team, there is no hub of control to keep the team updated as to what is going on. Thus we have the ceremony of the daily stand-up from Scrum and the Practice of ‘Sit Together’ from XP. We also have concepts such as the wiki, centres of excellence, brown bags and the information radiator.

Self-organising teams do not replace a command and control management structure with a dictator developer or cliché of strong minded individuals within the team. The team can use agile games to guard against this as well as having a good coach on hard to address imbalances in strength of personalities. Examples of agile games are planning poker and turn the tables.

I hope this brief article has shown that a self-organising team follows many agile principles and all of these principles are needed to truly support the team. The more I experience agile, the more I fall back to first principles. If you are having problems being a self-organising team, review the first principles and see which ones you are not following.

References

1. From Kent Beck’s ‘Extreme Programming Explained 2nd Edition
2. See Scrum Primer
3. Agile Manifesto
4. From Robert C Martin’s ‘Agile estimating and planning
5. From Mike Cohn’s ‘User stories applied
6. See ‘The role of the manager
7. From Scrum Alliance community article

 

Simon Powers

Simon Powers is an Agile Coach specialising in large scale transformations and agile adoption. He has a background in very large enterprise architecture which has led on to organisational design and agile process refinement. Simon is the founder of Adventures with Agile.