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 demos 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?
Micromanagement devils
The devil is as always in the details. One might call the above description a micromanagement, but it is very different from the traditional meaning of the term. Micromanagement in Scrum indeed happens if by micromanagement you mean staying in direct control over relevant things at both high and low level of abstraction. The trick is that direct control at different levels is strictly separated, employed by different people and serves the different purposes. Team is micromanaging its daily actions on the daily level and management micromanages the release content on the iteration level. Doesn't look like a traditional micromanagement by a pointed-hair boss telling you when you are allowed to change the function name, does it?
Team level
On the team and daily level there are daily standup meetings, where team members gather to synchronize with each other and figure out how to help the ones with the biggest problems on the way. There is no real reporting and the whole reporting part - "What did you do since the last meeting?" question - should take the smallest part of the meeting and its main purpose it to give context for the subsequent "What are you going to do until the next meeting?" and "Are there any impediments on the way?". There is no commanding boss that makes decisions, Scrum Master plays a facilitator role only. Is it micromanagement then? Yes, if making the team aware of its daily actions and allowing it to take corrective actions is micromanagement.
Your experience
How does it happen in your agile or not so agile team? When the team is allowed or even requested to synchronize with itself on a daily basis, does it feel like annoying micromanagement? Is your Scrum Master perceived as a directing boss or as a facilitating device for help?
More on the micromanagement by Product Owner and not allowing to focus on the long term later. Stay tuned.
(Photo courtesy of D'Arcy Norman @ flickr)
RSS feed
Comments
I have just recently started
I have just recently started a contract as a developer in a scrum environment. I have gone from previously working towards a big picture to now having my activities managed on a daily basis with no long term goals.
This environment is very frustrating to me. I cant see me lasting until the end of the contract...
Self-management
Now, when agile is on the hype and many companies decide to adopt this or that method overnight, I many times see this kind of complains. It's a pity to see how the idea of self management and synchronization is often translated as full micromanagement.
I don't know the details of your situation, Anonymous, however, the reasons you list are actually something that Scrum was invented to cope with. It is a direct product owner responsibility to provide the product vision and show the global project priorities. As for day-to-day micromanagement, it is supposed to be you, who selects tasks and plans team work for the day and sprint (together with the other team members though). And even if these mechanisms fail, that level of frustration just has to be the hot topic of the nearest retrospective - it is not something you'd like to live with whatever process you use.
Could you, please, tell a bit more about your Scrum adoption process? Did it start long time ago? How big is your team? Did you all get the Scrum trainer? Did/do you have a coach to help during the early adoption process?
The Issue is Scope
I think I know where "Anonymous" is coming from. A lot of Agile adoptions look like this:
There is a group of people who have input into the business requirements. This is a collection of client representatives, user interface specialists, business/system analysts, a bean counter, and maybe an executive or executive's proxy. They filter down through one person, and may even have good chicken/pig distinctions. But, they all need to be in any discussion in priority setting, requirements mining, etc., etc.
In addition to that business team, you've got a team of somewhere between four and twelve developers, and usually a few sundry support staff (QA, infrastructure, etc.).
Meetings with a group of people of this size are totally unbearable, and building up/managing a story backlog takes a LOT of time, so a core of a couple developers and a few key other people get tapped as the "planning team". You'll be able to recognize this when you have "architects" or "team leads" who end up spending about a quarter of their time in meetings that the other developers don't go anywhere near.
This planning team then emerges from their planning with a set of very low-level stories: "implement this piece of functionality as designed by the system architects", "implement this design element as mocked by the information architects".
The coders then just pop a story off the stack, work on it, pop the next off the stack, work on that one, ad nauseum. Customer communication, tracer bullet implementations, and other kinds of flexibility still exist down at the lowest levels, but the creativity and problem solving involved in software development is just gone: the developers are really just code monkeys.
I've been a developer in that Agile model a few times, and every time, I've quit before the end of the contract. My key skill and joy is in solving problems, so this kind of assembly line Agile methodology really doesn't work for me unless I'm in that architecture team.
unbearable meetings
"Meetings with a group of people of this size are totally unbearable"
Frankly, I know that often they are, but I don't think they *have* to be. It's a matter of learning the right facilitation techniques and meeting processes, in my opinion.
Post new comment