6 Execution ↑

No. 39 – Self-Organizing Teams

A certain amount of hierarchical control is necessary in almost every development project. After all, some sort of direction must come from above in order to start and direct a development effort. And, by its very nature, the process of decomposition is itself hierarchical: large items on the top are decomposed into smaller items below.

Traditional project management approaches are also hierarchical in nature. Project managers assign work to developers, and developers report status to project managers. Information flows up and down the tree.

However, experience in multiple fields has shown repeatedly that many types of work can be managed more effectively by self-organizing teams.

Let’s discuss what we mean by a self-organizing team.

First of all, such a team should be formed using the ideas of decomposition, cohesion and loose coupling. In other words, the team should be of an appropriate size – let’s say 3 - 15 team members. And the team should contain all the skills needed to perform most of its work without having to draw resources from outside the team. And the sort of work typically assigned to the team should be of some consistent, coherent nature.

Once formed in this way, the team should be given joint accountability for team goals and the code produced by the team.

Such accountability can be reinforced by scheduling the work to be done in brief sprints, or iterations, generally of 1 - 4 weeks in duration. The team should jointly and freely commit to the work taken on by the team for each iteration. Such practices then give the team very clear and actionable and urgent goals.

Such teams can then freely assign work to be done to the team members most qualified to do them, or with the most available time. When trouble is encountered, then such teams can quickly shift assignments to bring more help to bear on the trouble spots.

Such a team will generally use daily team meetings – often known as stand-ups, due to their brevity – to allow each team member to communicate progress, next steps and any issues encountered. If additional assignments need to be made to address issues, then these can quickly be done during these same daily meetings.

Such a team will also typically use some sort of highly visible task board – either a physical board or an electronic equivalent – so that progress towards team goals is always easily available to all team members.

Such a team will also typically work to a common set of completion criteria for its coding tasks, often referred to as a Definition of Done Team members will then hold each other accountable to make sure that whey they say they are done with a task, that their work meets this DoD defined by the team.

Progress of such a team, especially when delivering early and often, will generally be tracked using burn down charts. Charts like these show the general progress of the team as a whole towards meeting its commitments for the current sprint, without getting bogged down in the details of who’s working on what and actual vs. planned numbers for each individual task.

The advantage of such a team is that, by leveraging the skills and wisdom of the team as a whole, and by leveraging peer-to-peer communication, the detailed work can be more quickly and effectively managed than could be done by the traditional hierarchical arrangement of communicating through a project manager.

A self-organizing team also tends to produce higher levels of developer engagement, since it tends to maximize feelings of purpose (meeting team goals), autonomy (freedom to accept team commitments and to move work and resources around to meet those commitments), and mastery (ability to complete challenging tasks on a frequent and regular basis).

Words from Others on this Topic

Next: A Deliberate Approach to Decision-Making