Succeeding with Agile - Mike Cohn's Blog

Ssssh….Agile Is All About Micromanaging

Sep 13, 2009
by Mike Cohn
42 Comments

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.

Hi Eugene-- I'm sorry you've had a bad experience with what your company is mistakenly calling agile. When it is done right, it should not feel burdensome. I'm about to close this post to all future comments because no one is getting the point that agile is *NOT* about micromanagment. It is about a team managing itself so well that even micromanagers leave the team alone.
Posted by Mike Cohn on 2013-02-02 13:17:00 Hi Mike - Though I work on a few projects as a freelancer, working as a software engineer and lead for almost 20 years, I'm also regularly employed at a place where we have adopted Agile. Before working here, I'd worked in a government capacity as a software engineer where they were also using Agile (Scrum, Sprint Planning). At the current company our PM has directed us to the Agile Manifesto on several occasions, seeking to calm the frustrations of both the development team as well as the stakeholders. The truth is that we find the micromanagement aspects of Agile to be the most frustrating and counter-productive. Backlog grooming meetings, Sprint Planning Meetings, Scrum Sessions, not to mention the meetings that get scheduled as a result of comments voiced during those meetings - it's out of control! To say that Agile is micromanagement, and that's okay is to disregard all past research that highlights the dangers of micromanaging teams. Micromanagement wears on teams - humans are not machines, not robots, and these individuals who work on highly advanced applications don't have the same minds as those in other countries where this style of leadership is much more tolerated. The men and women who excel in their craft will eventually leave the company. This is something that those implementing Agile should carefully consider. Agile shines in the light as the buck poised to liberate disorganized software engineering operations and deliver quality. However, not every company or team will benefit from implementing it - Salesforce may have, but not every company has the capital, leadership, type of customer, or development core as Salseforce does - just because Agile works for them doesn't mean it will work for the millions of other software companies out there, serving thousands of other industries and customers. Bottom-line, it's a little careless to endorse micromanagement (a style of leadership that has proven to fail) as a benefit of Agile; Considering the whole of managment history should lead to more caution or at least a more thorough commentary. I don't argue against using Agile (especially when coupled with Lean practices); I simply believe that those implementing it should work hard to realize how to keep not only the product owner or customer happy, but, and more importantly, the team content - they are the most valuable asset.
Posted by Eugene on 2013-02-02 13:02:10 I won't change my mind either. Agile is micromanagement and professional developers don't need to be micromanaged. We are not overhead.
Posted by Carmine on 2013-01-30 15:24:00 Carmine-- The employees at Salesforce referenced above were the entire development team, so, yes it was developers. You're certainly free to maintain whatever misperceptions you have about agile. I won't change your mind here.
Posted by Mike Cohn on 2013-01-28 14:28:05 I agree with Jay. It's micromanagement at it's core and from a management perspective, NOT a developer perspective. Mike, if all of us veteran developers decided to do freelance, then don't tell me we wouldn't have work because you don't know what you are talking about. When you reach a certain level, there are things you expect and things you won't tolerate. Micromanagement is on the list of intolerable. As far as salesforce.com stats, since you don't say what roles the "employees" had, it probably wasn't developers.
Posted by carmine on 2013-01-28 14:15:13 Jay--You probably should go freelance then so you have more control over your destiny. I just read a report yesterday predicting that 80% of software development will be done in an agile manner within another year or two. (It was a Gartner report but I don't recall the exact source.) So obviously somebody is having success with it (and that success wouldn't have lasted as long as it has if all developers hated it). If your colleagues are coworkers who hate it, it's likely it's not being done well where you're at. Going freelance so you can try to avoid it as long as possible will be your best option I suspect.
Posted by Mike Cohn on 2013-01-16 08:40:12 It is micro-management and that why it sucks so much. I agree with Robby: Most developers are forced into Agile and silently hate it. Well, I actually mean SCRUM because that the Agile component I currently experienced and hate. None of my colleagues like it. This is doing a great harm to the industry. It makes me want to go freelance, because so many companies are using SCRUM now... I feel like a craftsman me when we started chain-producing things that used to be handcrafte: .
Posted by Jay on 2013-01-16 08:20:07 Hi Robby-- I'm sure you gave Scrum a thorough and unbiased try before coming to such a strong opinion. However, you may want to re-look at some of the facts supporting its use. Many are summarized in this presentation on the benefits of agile. In particular in there, notice the data on job satisfaction: - At Salesforce.com, the percentage of employees who were having a "good time" or "the best time" at work went from 40% to 86% after using Scrum. -A study at the University of Calgary revealed 2/3rds less overtime with Scrum The report also shows data from multiple studies that show higher productivity, lower cost, faster time to market, improved quality, and improved stakeholder satisfaction.
Posted by Mike Cohn on 2012-02-27 23:41:12 Scrum is a joke. A tool used by managers to control developers. Scrum projects fail on a long run. Please stop selling ridiculous ideas like Scrum. True innovators do this without enforcing micro management of the projects. It's done at all start-ups minus overhead of so called scrum.
Posted by Robby on 2012-02-27 18:11:51 Hi Kevin-- Yes for Scrum/Agile purposes tracking the amount of effort expended is irrelevant. At the end of each day most teams have an accurate view of effort remaining but not of effort expended. (Effort is expended is essentially assumed to be "you were here 8 hours today so you expended 8 hours of effort.") They capture this in a sprint burndown chart. But it's important to realize this is only the number of hours left. You can't look at a sprint backlog or sprint burndown chart and know how many hours went into a given task or who put those hours in. Now of course consulting companies or contract developers will track their hours because that is how they bill for work but doing so is not necessary for doing Scrum or agile. (It won't hurt to track those; it's just generally not worth it unless it is how you bill for work.)
Posted by Mike Cohn on 2011-02-16 08:53:24 Mike, When a developer leaves aside his task for a while (maybe a whole day or even two) to help another developer with analysis or coding of a task of that other developer... how should they specify the 'actual effort' of the story/task? Should they sum up the hours for both developers and charge the hours of the two and not of one developer since actually the two of them were working together? If the fact that developer A helped developer B with a task leaving his tasks aside for a while, with the risk of the tasks developer A committed to for the sprint being jeopardized, is maybe an issue to rise during the retrospective meeting and clarified there. But my question is more from a project management perspective: assign the hours they worked together, times 2 (because the two of them were working)? Just charge the hours of the developer that owns the task? Is it irrelevant?
Posted by Kevin on 2011-02-15 21:22:50 First of all let's not be coy. It *is* micromanagement of the worst kind; it's attendance keeping for 4 year olds that can't use email to update their team with status. It's a false sense of security that information is being transferred just based on answering 3 inane questions. And it's micromanagement of the worst kind, when not only are you being micromanaged by 1 manager, you are micromanaged by a whole "team" of micromanagers, most of whom are amateurs, most couldn't manage a donut shop, and any one or more could have an axe to grind. Great methodology for the id10t crowd. Software Maestro
Posted by softwaremaestro on 2010-12-09 00:55:06 Excellent post, spot on. Except for the very last bit: "and for their own benefit". If the company flourishes, I will probably keep my job. I may even get a raise. If the company fails I will most definitely lose my job. Stop feeding people horned herbivore dung like that the interests of the company and those of the workers were identical. I'd like to allegorise your post and (part of) the reactions to it: A shepherd dog steers the herd exactly the shepherd wishes it. Therefore, you say with a wink and a nudge, the shepherd is actually micromanaging the dog. But... ssh! "Nay!" others retort; for the shepherd is never seen to actually give any order to the dog. Clearly, the dog is "micromanaging itself". And they are right. The shepherd dog isn't micromanaged. It barks and bites out of its own volition. It has _internalised_ the shepherd's interests. And this is what those methodologies are all about: intensifying the process by which workers identify with the company's interests, so as to be more easily milked. I very strongly suspect that most gains in productivity reported from the use of agile methods stem from this. Agile/flexible: adj. Possessing a state of mind or a stance of the body that allows for deeper anal penetration. The shepherd dog gets the occasional bone to gnaw on. Don't expect much more once the hype has died down and the standards have uniformally reached a new low. The occasional bone is better than what's in for the sheep, you might say. Still, rather than agile, I'd rather be wild.
Posted by AnonWantsToKeepHisJob on 2010-06-04 12:50:40 Hi Lithous-- Yes, that sounds like micromanagement. But, it's also not something I'd call an agile project based on the description you provide. On a well-run project, the team is keeping such a good eye on its self that outside management shouldn't feel the need to micromanage. They should give a team a goal and get out of the way, confident the team will do their best and will, if at all possible, achieve that goal.
Posted by Mike Cohn on 2010-05-27 06:06:16 Mike, I am on my second project to adapt Agile and I quite frankly feel like it is micromanagement for this current particular project. I am currently working on a gov't contract and with a total of about 22 developers and testers (broken down into multiple scrum teams) we have a software lead -> a contractor deputy PM -> a contractor PM -> gov't deputy PM -> gov't PM ->branch chief that are, in some capacity, hands on in running the project. My first Agile project, flawed in many more ways than this, my second, had 6 scrum teams consisting of about 5 developers, a tester, a scrum master (unfortunately no product owner made it to scrums) and that was it. I didn't not mind reporting my status at all to basically just my peers. But then... I move on to my second Agile project and in the daily scrums it started out with all the *management* chain i mentioned above plus the 2 developers and 1 tester and a couple floaters and a product owner proxy. It did narrow down, after some complaints by my and other scrum teams, to now have the core team plus the contractor deputy PM and the gov't deputy PM in every scrum along with the release notes writer who is also the branch chiefs best friend, literally. I stated in our last retrospective that it seems like micromanagement. The two deputy PMs never seem to solve any problems we bring up. When they do speak I don't ever feel it is the right time (like to help solve a problem.) I was told that everyone is invited to the scrums and, of course, there are the chickens and the pigs. That the status is for the team not for management. I said fine, I don't mind telling my fellow developers and the testers that it took me an extra 16 hours to complete a task than estimated because i was working in an area of code where my fellow developer knows is frankly crap but who knows what my deputy PMs are writing in their little notebooks and what the chief's friend is writing as well. My feeling is that the PMs (the two deputy and two full) can at anytime look at our burn down chart that is updated daily and the scrum board. I personally, after this experience don't believe that scrums are productive when they are so open to attendance. I have never worked on a project in 17 years where i report to one much less multiple PMs daily. Actually, to further my point, there is one or more PMs in every TEM (which we do too much but that is another story all together.) So, I should not take this as micromanagement?
Posted by Lithous B. on 2010-05-26 17:57:31 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://www.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
Posted by Gil Zilberfeld on 2009-11-18 07:59:18 @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.
Posted by Ash Tewari on 2009-10-28 23:42:08 @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.
Posted by Ash Tewari on 2009-10-28 23:06:47 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
Posted by Rowan McCann on 2009-10-26 06:43:51 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!
Posted by Andrew Eells on 2009-10-20 06:11:02 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.
Posted by Mike Cohn on 2009-10-20 00:04:52 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!
Posted by Andrew Eells on 2009-10-19 16:35:07 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.
Posted by Mike Cohn on 2009-10-01 09:03:21 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.
Posted by Bethan Davis on 2009-10-01 08:59:58 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.
Posted by Mike Cohn on 2009-10-01 08:51:13 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?
Posted by Christophe Le Coent on 2009-10-01 08:46:52 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!!!!!!"
Posted by Bethan Davis on 2009-10-01 08:27:53 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."
Posted by Mike Cohn on 2009-09-27 21:30:18 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?
Posted by Christophe Le Coent on 2009-09-27 04:31:39 Hi Mike, I do understand your point and I agree with it completely.
Posted by Ash Tewari on 2009-09-24 08:08:09 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.
Posted by Mike Cohn on 2009-09-23 21:33:55 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.
Posted by Ash Tewari on 2009-09-23 21:22:32 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.
Posted by Mike Cohn on 2009-09-21 13:22:35 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.
Posted by John King on 2009-09-21 13:19:12 Yeah, looking forward to see you in Munich.
Posted by Sebastian on 2009-09-17 14:21:34 Good bait and switch, Mike. See you in Munich. Tom
Posted by Tom Mellor on 2009-09-14 17:28:14 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...
Posted by Gerrit Berkouwer on 2009-09-14 13:47:52 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
Posted by Marc Bless on 2009-09-14 09:27:22 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.
Posted by Itay Maman on 2009-09-14 00:23:58 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.
Posted by Denis Miller on 2009-09-13 13:49:16 Thanks, Dan. By the way, I continue to enjoy your Letters to a Junior Programmer.
Posted by Mike Cohn on 2009-09-13 12:34:35 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.
Posted by Dan Bergh Johnsson on 2009-09-13 12:24:41