Sometimes when I’m teaching a Certified ScrumMaster class, I let the attendees in on the deep, dark secret of agile: It’s all about micromanagement. Almost every principle and practice of agile is there to support micromangagement.
- 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.
Ah, but who is it that is doing this micromanagement?
It’s the team.
Yes, agile is about micromanagment, but it’s about the team micromanaging themselves and for their own benefit.
Tags: agile phobias, agile teams
Well put. Turned the other way around, it is about responsibilities. In agile, responsibilities are described as _team responsibilities_ (code ownership, sprint commitments etc) which is often misunderstood as “there are no personal responsibilities”. That is only half true: towards management, product owners etc, the team is responsible, not individuals. But within the team each member is personally responsible for her/his actions: responsible in front of the team-mates. That peer control and pressure creates the “micromanagement inside” of the collective responsibilities of the team.
Thanks, Dan. By the way, I continue to enjoy your Letters to a Junior Programmer.
and what about practices in FDD, AMMD and so on.
there are a lot of practices which cover a lot of things during development: vision, release planning and etc. so micromanaging is a part of agile.
It’s true that Agile practices delve into the fine-grained activities of development. Nonetheless I don’t think it is micromanagement: Ultimately, at the very code of the developement process Agile is giving the programmer a tremendous amount of freedom.
Let me explain.
Agile processes impose all sort of restrictions/practices/etc. However when it gets to the code that the programmer writes there very few restrictions, which typically boil down to something like this: use the team’s coding standard, write tests before code, refactor.
In non agile processes the restrictions go much deeper: the programmer is told exactly what classes he needs to write, how should he implement his current task, what design pattens he should use, etc. This is because the design is dictated by some higher authority. Bottom line: programmer has much less freedom over the code he writes.
I recently used this micromanagement arguments against an agile sceptic. The guy was an old fashioned “projects need heavy control” manager who expected to get progress trackings every week. After some explanation how we do Scrum he just was astonished of such granular management.
Read my blog post on “Daily Tracking” for details: http://marcbless.blogspot.com/2009/09/daily-tracking.html
True. Planning almost becomes fun
! Being rather new at introducing scrum as a projectmanager in my government environment it amazes me still: every sprint I see people planning their work every day. Those are the same people who find it very difficult to plan for a total project in the past (which is hard, I agree with them). And interaction between multi-disciplinary team-members is another thing: you get this as an extra, almost without effort. Great stuff…
[...] Cohn elaborou uma interessante idéia da qual concordo, mas que pode parecer uma heresia para muitos agilistas: Agile tem tudo a ver com [...]
Good bait and switch, Mike. See you in Munich.
Tom
Yeah, looking forward to see you in Munich.
[...] MicroManagament (por el equipo, como en Scrum) -> NanoManagament (control en tiempo [...]
Hmm, I too agree that agile is not micromanagment in the general since. The usual way is to have the BIG plan document that takes lots of time to come up with. It will always have holes and they needing more documantation and possible re-nagotiating of the BIG plan – and micromangement of the BIG plan. Agile is finding the hole and fixing it fast. I will agree that there is micromnagement but it is the developer doing it by very quickly documenting the hole, find resolutions, presenting to team and/or client for alternatives, selecting the correct path, then fixing and marching on.
Hi John–
“There is micromanagement but it is the developer doing it” is my point. When it’s us micromanaging ourselves, it’s not a bad thing. And when we “do it very quickly” (your point), we don’t even notice we’re doing it. Thanks for reading and sharing your thoughts here.
This issue has implications on long-term developer productivity and morale, especially for large scale Scrum adoptions. If the team members feel that they are being micromanaged, then the team is not alligned with the basic agile principles.
I will be discussing this in SoCal CodeCamp at U.S.C. in November – http://www.socalcodecamp.com/session.aspx?sid=095564b7-394b-48cc-b455-2fdc449dc0d5
Please attend if you will be in the L.A. area after P.D.C.
A previous slide-deck is here – http://www.tewari.info/2009/06/30/is-scrum-bad-for-developers/. The slides will be updated for the November’s presentation.
Ash, thanks for reading the blog posting, but you perhaps missed the subtlety of it. I do not actually think agile is about micromanagement except to the extent that it is about the team “micromanaging” themselves.
Hi Mike, I do understand your point and I agree with it completely.
Hi Mike, I had the same problem: some (experienced) engineers thought Agile was about micro-project management. So I am just wondering whether this is just because engineers were not trained on Agile? In other words, Agile can be perceived as micro-management methodology mainly because of lack of Education on Agile?
Hi Christophe–
“Agile is about micromanagement” is a common complaint. I think it comes from people having been micromanaged in the past and so they become hypersensitive to it. So when a team sees the visibility/transparency that agile creates into the software development process they worry that it is again micromanagement. It isn’t. Agile is the furthest thing possible from micromanagement. On a well-run agile team, agile is about helping a team learn what they can commit to doing and then providing help to them so they can achieve whatever it is they commit to. There are tools in agile so that the team can “micromanage themselves” (if we want to call it that, which I’m joking doing in this posting) but that isn’t a bad thing.
So, Christophe, yes I think some education could help the team but I don’t think much more than a conversation is required. I’ve had that conversation with many teams by making the points in this post: “Yes, if you want to think about agile as micromanagement, that’s fine. But it won’t be me [your coach or ScrumMaster] micromanaging you. It’ll you managing yourselves.”
Hi Mike,
I have to say I whole heartedly agree with you…. It really is about Micro managing yourselves and not someone else dictating your every move. I particularly find this useful to prove in the retrospectives where the team decides the areas to focus on improving next sprint. It gives people in a team a sense of power and control over their own work destiny without having it rammed down their necks that added old question “why haven’t you built everything yet!!!!!!”
Thanks Mike for your comments! It is spot on. I just remembered one thing that could help the whole team get on board: it is to run the project using Agile methodology w/o ever mentioning this word. The first team I used Agile with, I never mentioned the word Agile and I had no problem, not a single problem. Second team I did mention Agile and wanted to explain what it was quickly: I started having so many questions and problems. I could not believe it. Would you have similar experience? If so, would you recommend to introduce some of the technics prior to talking about Agile?
Hi Christophe–
I call that a “stealth approach” which I contrast to a “Public Display of Agility” (PDA) in the new Succeeding with Agile book (chapter three). Yes, there are some cases where you’re better off introducing a new way of work without naming it at all.
Hi Mike/ Christophe
I have had similar experiences myself. As soon as I mention the name of a method, you get people already looking for ways to get out of it before trying it. Coaching people to try some agile methods (actually not just agile anything) before telling them what its called really helped with buy in on the approach.
Absolutely, Bethan. There’s a good book called “Nameless Organizational Change” by Glen Allen-Meyer that is built on exactly that concept. I always caution people against naming the agile adoption effort, even if they name the process. That is, it’s OK to call the process “Scrum” or “Crystal” if people already know that’s where we’re headed. But avoid silly labels like “Agile 2010″ and “Be Agile Now!” for the change process.
[...] Scrum significa que o micro-gerenciamento fica por conta dele (falo sempre isso em minhas turmas, e recentemente o Mike Cohn também publicou algo a respeito), e a Daily Meeting nada mais é do que uma ferramenta para o micro-gerenciamento! Se o time não [...]
Hi Mike, that’s a good point thanks, and I agree with you, although it takes a little bit of time and effort to get such a point in my experience.
Assuming a well-integrated or -performing team, do you think it’s possible to dispense with some of the more formal processes and metrics or management techniques that have grown up around the basic concepts of Agile?
I mention this briefly as part of thispost, but if the team is ultimately able to micro-manage itself then my belief (and experience) is that some of the management and tracking or measurement tasks of Scrum or XP etc can safely fall by the wayside.
With caution of course… Not to mention a fair amount of dedication and discipline. So perhaps best if the team has reached the performing stage of it’s development.
But still, it would be good to hear your opinion if you extend your post given the assumption of a well-drilled team.
Thanks and regards!
Hi Andrew–
Without knowing specifically which processes, metrics or techniques you are thinking of when you ask about dispensing with them, it is hard to comment on whether I agree in those specific cases.
However, it’s quite clear to me that each great agile team in the world will be slightly different from every other great team in the world. There will be a small set of core things that those teams do that overlap among them all but I suspect that will be a very small list.
For my part, this is why I like Scrum as a starting point for becoming agile. The few rules that exist in Scrum are *generative rules*. That is, they are rules that generate the right behavior from the team. For example, I know teams who have gotten to the point where they don’t have a ScrumMaster. The team itself takes on that role. To use a sports analogy I’d equate that to a team with a player-coach. Yes, some teams do that but it is extremely rare and I don’t know how many player-coach combos have led to championships (Bill Russell might have been the last in 1969). So even teams with great success with a player-coach (or acting as their own “ScrumMasters”) might have better success with an identified person in the role.
Thanks for that Mike, you’ve hit the nail on the head really!
I didn’t want to name particular instances of processes, metrics or artefacts and thereby offend anyone as many people have their own preferences and what works for them doesn’t necessarily work for others.
But I like your point about *generative rules* that don’t stipulate exact requirements. I have experienced a well-run project without a formal ScrumMaster in place but we were organised and embedded by this point.
From personal experience though I’ve found it difficult to migrate away from the documented approach or initial guidelines (so as to streamline the effectiveness of the team) when operating in a large organisation. But then I think that’s probably more a question of culture rather than process.
Good to hear your thoughts, thanks very much!
In my experience, companies hardly spend any time on people skills and nothing on the even more difficult concept of what people need to do to ‘self-manage’ into a high-performing team. Let alone a micromanaged team
Rather than let agile teams try to reach high-performance by trial and error it seems to me that the first thing to do is for everyone to understand the behavioral characteristics of their team members. One of the important features of this is measuring individual work preferences and harnessing these to the tasks that need to be undertaken.
To help agile teams prepare for the road to high-performance Bright Green Projects has teamed up with the Team Management Systems organization to provide a free 8-page assessment of what you think about your current (or future) agile team. We think it’s really valuable, I hope you think so too:
http://quiz.brightgreenprojects.com
@Rowan : You highlight a very important point. Scrum demands a different kind of attitude from team members. Attitude that comes from openness and trust as well as from confidence and mutual respect. A typical team composition can make it challenging to reach the ideal team dynamics.
Also, much of existing scrum training and advice is directed at Scrum Masters (read Project Managers/Leads) not at individual team members.
On the bright side, I see that there is a whole section (4 chapters) in Mike’s new book addressing individual contributors
I am looking forward to reading it.
@Christophe : I interviewed someone who had over 4 years of Scrum experience. He said “Scrum is bad for developers .. but good for the company”. As we discussed further .. it became clear that their team members were not doing their own estimates. Estimates were coming from outside the team.
The point is that in many cases people believe that they are doing Scrum, (because they are doing iterations and they have a burndown chart), but they are not.
[...] 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 [...]
Hi Mike,
We do a webcast on testing called “This week in testing” and this week, we talk about this post of yours (I really like the perspective of daily scrum as micro-management).
You’re welcome to watch and comment (http://learn.typemock.com/this-week-in-test/2009/11/18/episode-4-animals-that-talk-back.html) and if you like what you see, please tell the whole world.
Thanks,
Gil Zilberfeld
Typemock
[...] it, is my advise!Alexandre Magno talked about it on Adpatworks blog post, Mike Cohn too, on his "Ssssh….Agile Is All About Micromanaging" blog post.Share on [...]
[...] Sometimes, that leads to poor morale and turkeys crashing through the windshields of parked cars. Sometimes, that leads to a team embracing a more acceptable form of micromanagement called agile development. [...]