“The best architectures, requirements, and designs emerge from self-organizing teams”so it must be true.
A lot of Agile teams see improvements in productivity and quality. But how much of this comes from people working in self-organizing teams? And how much comes from better control and focus: from breaking work down into smaller pieces, working in timeboxes, holding frequent reviews. From faster feedback and more transparency with the customer. And how much from following disciplined technical practices, like developer testing, and code reviews or pairing, and refactoring.
How far do you need to go to get good, or even exceptional, results? Do you need to flatten down your organization, change your culture, change your management structure, change your HR practices and compensation model, change the way that you work with and communicate with the customer and with other teams… do you really need to change all of this to get better software out faster?
Learning from Survivor
In self-organizing teams, people are supposed to make decisions together, through consensus. Consensus works if you have a team of equals, or near-equals, and nobody (or buddies) can dominate the others. In reality, teams are dominated by stronger personalities or, if they are big enough, cliques.
We can learn some simple lessons from the TV show “Survivor”. Leave some people on an island, and pretty soon you will get politics. Some people will avoid responsibility, retreat from conflict: they don’t want to argue, they just want to get to work. Or they want to find ways to avoid working. Or they just don’t care. Some people will leave if they can find a way out. Others look forward to a good fight, get energized by it, but don’t have staying power or don’t know how to follow-up and get what they want done. So power and influence will go to people who are more articulate, more politically savvy, more confident, better at selling. Or to people who are more determined, more passionate about how work should be done, more willing to push for change, who have more to gain or less to lose. Or to people who are more manipulative and controlling.
These people will emerge as leaders in the group, and now you have replaced the role of management in the organization with new leaders who realize their agendas through cajoling, conning, convincing, ignoring, bullying, pressuring, outwitting, outplaying or outlasting the rest of the team into decisions.
I think that this is why some consultants are so strongly in favour of Agile teams and Agile methods: because in an Agile environment they can exert more influence, have more control over the outcome in a shorter time, play a bigger role on a team and have a chance to dominate it; rather than accepting, fitting into the existing organization and culture and “playing a role”. And if your team is having problems self-organizing and self-managing, well, there are consultants to help you with that too.
Swarm Intelligence?
I’m not convinced that the team needs to, or should, make all decisions together, and that the best decisions are always made by a “collective mind” or “swarm intelligence”. There is an important place for technical leads and experienced designers and technical specialists with valuable experience and skill. And there’s a good reason to let them do what they are good at. Even when you get a consensus-based democratic and fair decision from a team, as John Sonmez points out in When Scrum Hurts: Mob Architecture you tend to get average results, not exceptional results. If you have an expert on your team, why not let them make these kinds of decisions, so that you can aim for something better than average?
Management and Anti-Management
A common argument is that managers are not needed with self-organizing teams in Scrum – instead you have coaches who guide the team through their decision-making. This is part of what Uncle Bob Martin calls the anti-management bias in Scrum
“Scrum carries an anti-management undercurrent that is counter-productive. Scrum over-emphasizes the role of the team as self-managing. Self-organizing and self-managing teams are a good thing. But there is a limit to how much a team can self-X. Teams still need to be managed by someone who is responsible to the business. Scrum does not describe this with enough balance.”Martin Fowler captured the importance of this balance in The New Methodology
“Such an approach requires a sharing of responsibility where developers and management have an equal place in the leadership of the project. Notice that I say equal. Management still plays a role, but recognizes the expertise of developers.”The emphasis on equal is his, not mine.
Many people in the blogosphere take the position that if the teams are not self-organizing self-responsible self-directed (good), then the only alternative is hierarchical exploitative bureaucratic Command-and-Control (bad). But we need, and can have, a reasonable, middle path between extremes, a real-world and practical way of working.
Managers, good managers, respect and trust people to care about what they are doing and to do a good job, while still staying actively engaged. They offer direction, help define goals, help set priorities, step in and help when things are going wrong, handle conflict, and take responsibility when the business demands it. Good managers can help a team solve problems – or avoid them – because they have been in these situations before, and learned the hard lessons. A good manager understands that there are decisions that can be made and should be made by the team or by individuals on the team – and that there are other decisions that aren’t the team’s responsibility. That’s what managers get paid for.
Decisions about how to structure teams and how to get work done shouldn’t be about fear, or lack of trust. Or an organization’s culture, or inertia. Or politics. Or the current fashion. Instead, these decisions need to be about what’s best for the business. How to take advantage of all of the skills and capabilities that an organization has to offer – including management. And maximizing this advantage to the benefit of the team and of the customer.