Micromanagement, often has a negative connotation associated with it. It is a management style where a manager closely observes or controls the work of his or her subordinates or employees. Usually Agile development and micromanagement may seem to be opposite ends of spectrum however, they are more related than what meets the eye.
Mike Cohn suggested that it is the dark secret of Agile that it is all about micromanagement. Mike mentioned that all practices of Agile support micromanagement. He suggested,
- The daily scrum is about micro-managing the team’s daily work plans and making sure that everyone is doing what they say they’ll do.
Continuous integration is put in place so that the minute some developer screws up and breaks a build, it becomes known.
Pair programming is about making sure that programmers don’t lose focus, don’t goldplate, don’t work on only the fun stuff, and that they clean things up.
In support of the above argument, Artem Marchenko added,
There are quite many people to whom agile processes look like a lot of micromanagement: developers have to report on their actions every single day, management picks its nose to every feature, wants the team to report with demo's every two-four weeks and has problems allowing to spend a couple of months on thinking through and building a good architecture. Sounds like micromanagement, doesn't it?
So, who is doing the micromanagement?
As it turns out, it is the team. The team is doing micromanagement for their own benefit. Team is micromanaging its daily actions on the daily level and management micromanages the release content on the iteration level. When the team discusses their daily tasks, they are micromanaging for the benefit of the team and the organization as a whole.
However, there are situations in which the team members might feel micromanaged.
The scrum master might be too focussed on the progress of the team. This includes going around the team and asking for remaining tasks and challenging team estimates. There are also situations when team members fear making everything transparent for the lack of technical skills or certain weakness which they want to hide. Other factors include,
- Managers want constant updates by asking you often in addition to lengthy status reports, emails and meetings
- Managers try to talk technical details with you that they do not understand
- Managers change what you are doing on a whim and break your flow
Such micromanagement is typically true in organizations trying to make a shift from traditional software development to Agile. As Jurgen Appelo suggested,
Some managers are not comfortable with the idea of allowing a team to make decisions together. They feel they lose control over what's happening when teams make decisions without them. Managers assume that decisions must be enforced, or otherwise anarchy unfolds. But that same anarchy has constructed an entire universe, all by itself. So it cannot be all that bad.
Micromanagers must understand that they are “in charge” but not “in control”. Attempts to “control and contain” usually don’t work, and sometimes even have counter-productive consequences.
Thus, though Agile is all about micromanagement, the difference is that the team is doing it . The micromanagement must be delegated from the manager to the team which practices it on a daily basis for the benefit of the project and the team.