Linking the left brain and the right brain

Managers Manage. Teams Self-Organize. Conflicts Follow.

This is the second in a series of posts on dealing with the impediments raised in “Agile Antipatterns Are Easy to Spot, Hard to Change”. The second antipattern is…

2. Preserving the command and control hierarchy rather than letting the team self-organize

Managers are paid to manage. It’s hard for them to relax their grip and allow an agile development team to self-organize. Yet, self-organization is one of the key tenets of agile development.

Firstly, what does it mean for a team to self-organize? It simply means that the team accepts its share of the responsibility and accountability for delivering the software. This in turn means that the team must be an integral part of the project planning process and must take control of its internal workflow.

If the team can do all that, can we just get rid of the managers? No! The team still needs to rely on managers to establish direction, define projects, set priorities, create work environments, and manage external workflows.

So here’s the problem. Some managers cannot let go of the command and control mentality. They try to control too much. This antipattern may emerge from the manager’s insecurity or it may descend from the top. It is often a symptom that the corporate hierarchy has not accepted agile development. Senior management may be aware that the development team is following an agile approach but they, the senior managers, still insist on following the same old rules and tracking the same old metrics.

This leaves the front-line managers caught in the middle. They want to let the team self-organize yet they are being held accountable for every decision that’s made and every outcome generated. If you were being held accountable for every decision, wouldn’t you want to maintain command and control?

Find a mutually beneficial approach.

Effectively dealing with this antipattern means creating a mutually beneficial work process. The Product Owner (or lead stakeholder), Scrum Master (or project manager) and the offending manager(s) need to meet and arrive at a consensus.

What decisions does the team need control over in order to be successful? What decisions does the manager need to make or have veto power over?

What metrics does the team need to track internally? What metrics does the manager need to report up the chain of command?

Find a middle ground. The team may have to relent a bit and violate a few agile principles. The manager(s) may have to give a little and let the team have more control over its destiny. This give-and-take effort gets easier once the team can demonstrate success via positive stakeholder feedback. Start simple, and perhaps, not as agile as you’d like. Once you get the effort rolling, negotiate for more autonomy.

Always remember that management has the ultimate authority to redirect the team or cancel the project. Self-organization doesn’t mean the team can do whatever it wants, however it wants, whenever it wants. That’s anarchy.

Updated: November 10, 2011 — 9:39 pm
© Damicon 2014 Frontier Theme