On the subject of Self-Organisation
“Organise the work, let people self-organise”
Many agile frameworks include the idea of ‘self-organising teams’ as an essential ingredient. For example, Scrum calls for long-life, stable teams where individuals have no titles and there is no hierarchy. With no hierarchy, there is no ‘boss’. When I introduce these ideas in training, most audiences react with incredulity, citing a myriad of objections such as:
- We must have accountability* – a single individual I can rely on to ‘make it happen’
- Junior folks couldn’t organise themselves – they need a team lead or project manager to tell them what to do and make sure they do it
- If someone isn’t in charge, it’ll be chaos…
- How can we make sure people aren’t ‘slacking off’ if we’ don’t have someone keeping an eye on them?
- If people are allowed to decide what they’ll work on, you’ll have people doing work they aren’t capable of and making lots of mistakes
- How do I tell a senior developer with 10 years hard won experience that they now have the same title as the intern?
- We decide on pay scales based on title – we aren’t going to pay everyone the same so how else could we do it?
- Whats a career path without titles and hierarchy? What will motivate people to work hard and do a good job?
- Some people like to be told what to do – they aren’t comfortable making decisions for themselves
- Isn’t no titles or hierarchy just for an ideal world – can’t we be agile without the self-organisation bit?
*See a recent blog post on accountability in agile organisations
So if you take away titles and hierarchy, it leaves a lot of open questions. Lets tackle some of these one by one.
Firstly, do we really need self-organising teams to be agile? Not all of what are considered agile** frameworks require self-organising teams – in fact some like Kanban don’t mandate teams at all. But frameworks like Scrum and XP are based firmly around the idea of cross-functional teams. But why ‘self-organising’? The logic is that teams based on a hierarchy, with power at the top, but most of the detailed knowledge and awareness of the work at the bottom, are two slow to sense and respond to complex, fluid situations. In a traditional environment, people on the front line must articulate the changing context to those up the hierarchy, while decisions must be fed down through the ‘chain of command’ till they reach those that will implement them. To speed up this process, teams can delegate power to the front line. However, delegation implies the person delegating, i.e. temporarily passing the power to another, still has ultimate responsibility. Therefore, delegation is usually carefully qualified and bound. Heavy oversight and a fear of a loss of control can hugely restrict the intended benefits. In self-organising teams, on the other hand, the decision making power is not delegated, it is distributed. That is, there is no one individual with the power who is temporarily delegating it to others. The power is everyones, and everyone on the team is responsible for using it to the benefit of the team objective. So in summary self-organiing teams are not a mandatory requirement of agile, but their ability to be agile (sense and respond rapidly and effectively) is an important aspect of a successful agile organisation.
**What is and isn’t an agile method is highly subjective, but mostly I consider whether it shares the values of the Agile Manifesto
The next question is ‘how do we ensure everyone on the team is contributing in the most effective way’? If we don’t have a ‘boss’ telling us what to do, how do we know what to do? The answer is a shared goal, and commitment to that goal.
‘Make the mission your boss’
The team should have agreed a shared objective that everyone on the team will pursue. In Scrum this may be the sprint goal (short term), release goal (medium term) and company or team strategy (long term). To use a rugby metaphor, the short term goal is to score a try, medium term to win the match and long term to with the championship. It is this shared goal, unattainable by any one team member or subgroup, that causes the team to ‘gell’ in a network of interdependancies and mutual accountability. This is where the transparency agile calls for is so important – so people can see where they can best help the team to reach the goal, where the problems and blockages are, who is contributing what. If everyone is working to a single goal, one that is not too far out (e.g. a day, a sprint), then alignment of activities happens ‘implicitly’ through face to face discussions, the team board, programmers and testers working on the same things at the same time, etc. And since everyone is mutually accountable to each other to do their utmost to achieve the goal, there is no place for people who will sit around waiting to be told what to do. I’ve seen this approach transform a group of shy, junior, fearful engineers into a cohesive, dynamic and super effective team within just a couple of weeks. A good agile coach/scrummaster will create an environment where the mission is the boss, where there is no fear, and where the team has everything it needs to do a good job.
In the next few posts I’ll discuss some of the other questions raised above – e.g. hiring effective team members, career paths, performance management, etc.