Agile is Micromanagement

Posted by Vikas Hazrati on Nov 10, 2009

Community

Agile

Topics

Agile in the Enterprise

Tags

Management

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.

1. Back to top

   Some teams like Micro-Management

   Nov 10, 2009 12:35 PM by Srikanth Shreenivas

   I see that article kind of hits about two styles of management: Team-led micro management (True to Agile Processes), and Manager-led Micro-Management (Teams trying to transition). First style of micro-management may be pre-valent in a relatively mature team, teams that have embarked on 2nd or 3rd Agile project. First-time agile team may have cultural barriers (speaking-up in team stand-ups, or getting used to be told what has to be completed by when) that may unknowingly enable/encourage manager-led micro-management. Second style of micro-management can be more often experienced in Indian IT companies where culturally team like to be told what has to be accomplished and will probably be some time before they attain the maturity needed to attain first-type of micro-management.

   Reply

2. Back to top

   Re: Some teams like Micro-Management

   Nov 10, 2009 12:53 PM by Erwin Vervaet

   Funny how I was discussing the exact same thing just yesterday. Indeed, agile processes seem to be a form of micromanagement.

   Reply

3. Back to top

   Ah, but don't forget...

   Nov 10, 2009 6:14 PM by Howard Deiner

   There is a difference between the transparency that Agile seeks versus micromanagement. Agile teams need to be craftsmen when it comes to their code if they are to harvest the benefits of lowering the cost of defect remediation by detecting defects early and fixing them. Also, the team collaboration that occurs in the daily standup is different than the daily (or even hourly!) status that micromanagers would like.
   
   Agile is different than predictive processes that managers use because the leaders that work for Agile teams get behind the notion that enabling teams to do the best things to generate the business value that their software produces is what requires enablement, rather than brow beating a schedule into a team, and forcing the team to duck and cover, lest management find out some inconvenient truths.
   
   Transparency is necessary. Managers who think that they know how to do the software, in addition to knowing what needs to be done are usually only fooling themselves and their superiors. They need to become leaders for their teams, and let the guys who are experts at producing software get their jobs done.
   
   There's a certain amount of courage that is necessary to do Agile properly. Trust that your team is capable of doing the right stuff. Trust that given enough rope, the team won't hang itself, but will in fact tie together a great solution. Trust that letting go and doing what the team says needs to be done is a better way to go. Trust that issues that arise from the transparency of CI related information, pair programming, and the loss of hiding will be used to create ever better levels of craftsmanship, and that great code will ultimately pay off big time for an organization.
   
   Transparency is different than micromanagement, and is basic to the Agile way of doing things.

   Reply

• Older >