Bulldozer00's Blog

Assume that you’re actively working on a successful software development project before the Agile manifesto was created/signed and before Scrum was formally defined by Sutherland/Schwaber. The timeline and parameters of your project may look like this:

The number of managers and developers involved in the day-to-day work is most likely fixed and no executives directly meddle with the team’s internal affairs. In addition, the average number of hours worked per week per team member and the average stress level felt by the team is most likely constant. Most importantly, status reviews aren’t conducted on a daily basis. Once or twice a week is the norm. Because of the lack of a mandated daily status meeting, some healthy slack is available to the team for learning and doing things directly applicable to the project but not enumerated on the schedule/backlog. All is well, a healthy and sustainable pace is being maintained.

Now, imagine that at some point in the future of the project, someone in the executive suite decides (either rationally o irrationally) that the project is either behind schedule or over budget or, most likely, both. When that fateful day arrives, you will be suddenly transported into…. The Micromanagement Zone (TMZ):

The project timeline will most likely transition to this:

The consequences of transitioning into TMZ are never good for anyone involved (developers, managers, executives, customers):

• The frequency of status meetings will rise – most likely to at least one per day.
• The number of managers assigned to “oversee” the project will rise.
• One or more executives will get intimately involved in the day-to-day execution of the project.
• Some additional number of newbie developers may be suddenly injected into the team, bringing progress to a crawl.
• The number of hours worked per week per developer will rise.
• “Sustainable pace” will never be uttered again. The workaholics on the team will brag about toiling late into the night and on weekends.
• The average stress level will rise and the average physical health of the team will deteriorate.

The worst thing about entering TMZ is that it’s like a black hole: once you’re in, you can never escape. Well, that’s not quite true. You can leave of your own free will or the project may get cancelled.

So, how does Agile and/or Scrum solve this stubbornly entrenched and globally ubiquitous MZ problem? It doesn’t. In fact, every Agile/Scrum project is poised from the get-go to glide into the MZ as soon as the project is “deemed in trouble“. The fact that daily status meetings (promoted innocently in the Agile world as informally loose “standup” meetings) are required from day one points every Agile project directly toward the MZ abyss – all signed up and ready to jump. In the pre-agile days, daily status meetings were only initiated after the project was deemed in trouble, they weren’t required from day one.

The agile folks will say that the purpose of the daily standup meeting is to provide early warning detection of a project that is heading for trouble – and they can be right. They’ll also say that early detection will allow actions to be taken to get the project back on track – and they can be right. However, the specific “actions” taken to reign in the project may actually be those that will thrust the project squarely into the MZ .