Is Agile the new micromanagement?

Question

This question has been cooking in my head for a while so I wanted to ask those who are following agile/scrum practices in their development environments.

My company has finally ventured into incorporating agile practices and has started out with a team of four developers in an agile group on a trial basis. It has been four months with three iterations, and they continue to do it without going fully agile for the rest of us. This is due to the fact that middle management is entrusted to meet business requirements with quite a bit of ad hoc requests from upper management.

Recently, I talked to the developers who are part of this initiative; they tell me that it's not fun. They are not allowed to talk to other developers. Their Scrum master enforces this restriction. And they are not allowed to take any non-business-related phone calls in the work area. For example, if I want to talk to my friend, who is in the agile team, just for kicks -- I am not allowed without the approval of the Scrum master; who is sitting right next to the agile team.

The idea of all this (or the agile, in general) is to provide a complete vacuum for agile developers from any interruptions, and to have them put in good 6+ productive hours. Well, guys, I am no agile guru but what I have read Yahoo agile rollout document and similar for other organizations, it gives me a feeling that agile is not cheap. It require resources and budget to instill agile into the teams and correct issue as they arrive to put them back on track.

For starters, it requires training for developers and coaching for managers and etc, etc... The current Scrum master was a manager who took a couple days agile training class paid by the management is now leading this agile team. I have also heard in the meeting that agile manifesto doesn't dictate that agile is not set in stone, and is customized differently for each company. Well, it all sounds good and reasonable.

In conclusion, I always thought the agile was supposed to bring harmony in the development teams which results in happy developers. However, I am getting the very opposite feeling when talking to the developers in the agile team. They are unhappy that they cannot talk about anything but work, sitting quietly all day just working, and they feel it's just another way for management to make them work more.

Tell me please, if this is one of the examples of good practices used for the purpose of selfish advantage for more dollars? Or maybe it's just us, the developers like me and this agile team, which feels that they don't like to work in an environment where they only breathe work while they're at work.

---

It's a company in the healthcare domain that has offices across the US. It definitely feels like a cowboy style agile, which makes me really not want to go for agile at all, especially at my current company.

All of it has to do with the management being completely cheap. Cutting out expensive coffee for a cheaper version, emphasis on savings and being productive while staying as lean as possible.

My feeling is that someone in the management behind closed doors threw out this idea: agile makes you produce more, so we can show our bosses we're producing more with the same headcount. Or, maybe, it will allow us to reduce headcount if that's the case.

They are having their 5 min daily meeting. But not allowed to chat or talk with someone outside of their team. All focus is on work.

Answer 1

You're describing managerial dictatorship, not agile. Agile is about incremental development in a field of changing requirements, not about dictating people how they individually go about doing their work.

Answer 2

They are not allowed to talk to other developers by their Scrum master and are not allowed to take any phone calls in the work area

This is really not part of Agile practices - and a separate issue.

A large motivation of Agile methodologies is increased communication between developers. Restricting developer<->developer communication is a separate issue from Agile practices. I'm not saying this isn't happening - it obviously is, and it's being labeled as part of the "agile" rollout in your organization, but this is really a separate issue from agile (and somewhat against the spirit of agile development, IMO).

Answer 3

That sounds like a pretty perverse implementation of agile. Agile, if anything, should reduce micromanagement, not increase it. The team makes a commitment and part of the process is that management trusts that the team will accomplish it. The daily scrum is a way for the developers to communicate with each other and a way to inform what they did, not how they spent their time (which is a mistake I've seen in a few places). Even the estimation process should remove explicit time keeping from the estimations, since you should be estimating relative complexity, not how long a story will take (another common mistake). Controlling the time spent by developers is the hallmark of micromanagement, and removing time from the process is one of the core tenets of agile.

Answer 4

This isn't agile.

Firstly, Scrum is not agile. Scrum, frankly, is bullshit. I was raised in an Extreme Programming house (literally - i have had Kent Beck sit on my dad's sofa and talk to me about testing), and i can tell you straight up that Scrum is not it. Scrum is a project management tool - a defined rhythm for a development project. But it has nothing to say about the development itself, and very little to say about requirements, planning, and the relationship with the customer. XP has a lot to say about all that; any other methodology which wants to call itself agile has to have something to add to the conversation. Scrum proponents have described it not as a process, but as a wrapper for a process. A wise man once pointed out that a wrapper is the thing you remove and discard to get to the good stuff.

Okay, scrum rant over!

Secondly, a founding principle of XP, which i believe is fundamental to any agile process, is that it is centred on the developer. It's a way of giving developers the power to do the job they know they need to do, and are so frequently stopped from doing. An agile team may be structured as a democracy or an autocracy, but the leaders are developers. There are roles for project managers and so on - vital roles - but it's not one of team leadership. Having a manager - sorry, 'scrum master' - sitting there bossing people around is a sure sign that the team is not doing agile.

I feel like there should be a thirdly. There isn't.

Answer 5

The environment you describe sounds like garden variety pseudo-Agile bullshit.

I got involved with Agile before it was Agile. Circa 2000 I was burning out on coding, heard about Extreme Programming, tried it, and liked it. It gave me as a developer a context where producing solid software was the most important thing, and it gave me tools to minimize a lot of the bullshit that was making me crazy. I loved it.

The problem today, which I explain in detail elsewhere, is that most of the people "adopting Agile" these days are not interested in improving anything if it makes them uncomfortable. So for them, "Agile" is just a new stick to beat the developers the same old way. As opposed to, say, a way to radically increase productivity while removing all the bullshit that is slowing development down.

Right now. I'm starting a company, and I'll be using a lot of XP, plus a bunch of other tricks I leaned in the Agile world. But precisely because of stories like yours, I flinch whenever I heard about an Agile adoption these days.

So to answer your question directly: Agile shouldn't be the new micromanagement. It should be about empowering the people doing the actual work to get shit done. But in your case, Agile sounds like the latest lie they're telling you while they indulge their own bad instincts. For which I am truly sorry.

Answer 6

Scrum is the bastard child of Agile. Its the most waterfall-style of all the agile methodologies, and that's why its the most popular amongst managers.

All agile methods are about producing working code without crap getting in the way. Read that again. And again.

Anything that gets in the way of that goal, regardless of the "agile rules" is bad. If the rules get in the way, change the f** rules! That's the agile way, that's what makes it relevant and effective.

The best example of this is given by Alistair Cockburn (one of the originators of the agile manifesto):

“Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, tested software to the users every one or two months, and otherwise leave them alone.”

If that works for the quality of guys you have, then that's all you need. You don't need a scrum master or any "agile" methodology. If sitting down in a daily scrum works for you, then f*** do it. Making you stand up is just pathetic abrogation of your ability to think for yourselves.

There's a response to the kind of agile you're doing. Its this. Print it out and pin it up somewhere when no-one else is around and let them discover it for themselves.

Answer 7

The current Scrum master was a manager who took a couple days agile training class paid by the management is now leading this agile team.

That's your problem. Managements want some Agile, they don't really know what it is, and they impose it to the teams. That's pretty much what to do when you want to decrease significantly the productivity of your developers ;)

The new process proposal should come from the developers. Or at least be reviewed & approved by them if it's a management's idea.

In any case, if the developers refuse it, don't implement it! Or it will be the disaster you describe.

Answer 8

"Agile" and every other "management methodology" is frequently abused to force micromanagement on people. OTOH it's also sometimes abused to defend poor workmanship.

"we're Agile" is the most frequent excuse I hear for lack of planning, lack of thinking about design, features, quality, release cycles. This usually from developers and lower management. It's madly also the most frequently used excuse I hear from middle managers, architects, salespeople, etc. for micromanagement, ever shifting deadlines and featurelists, forcing massiver overtime on people (the ever shifting deadlines and featurelists ensure that of course), etc. etc.

The two of course are often in direct contradiction, and can happen on the same project.

Answer 9

To answer your original question, is Agile the new micro management, I'd say no.

First, go read this (Agile manifesto) and you'll notice that not talking to your co-developers isn't listed.

Actually "Individuals and Interactions" is exactly the opposite of not talking to your co-developers.

Answer 10

Agile should be the new self-management. If agile is practiced correctly, many of the decisions are made by a customer and developer working a reasonably scoped user story that is added to the backlog as tasks are identified.

The daily scrum is about communication, not management. There will be some discussions about priority and load balancing, but the person managed at the scrum is hopefully the scrum master. AS a developer, I attend, say what I did, what I am going to do, and what help I need. Then the scrum master should roll into action clearing impediments to my progress.

Agile teams must not feel like day to day work is managed hierarchically. If decisions are made from afar by someone at the top of a hierarchical organization, it is time for the decentralization of decision making! For some people and some organizations, this may be a bridge too far. If the following is not true of your organization:

Live the Agile Manifesto

"We are uncovering better ways of developing software by doing it and helping others do it."

Avoid "Meet the new boss, Same as the old boss." Originate Agile from within the team as much as possible. Sometimes this happens by picking a coalition of the willing to be on a trial project using Agile. If you can form your Agile team from volunteers or invited members who have a track record for good teamwork, they can work it out. Use a small team on a short project, maybe for an in-house or highly accessible customer.

Embrace the change. Perhaps you can take some training, but maybe your budget is tight and the money just isn't there. Other opportunities can provide improvement as well. Do some reading, have members of the team learn what they can about Agile and teach each other. You may be able to find new or existing staff qualified to model and lead in Agile adoption.

Answer 11

Agile teams are like football teams working towards a commonly understood goal. I have been part of agile teams for some years and the key is effective and efficient communication across all stake holders. Managers/Scrum masters are mere facilitators of the team and traditional management/micro management will kill the team's spirit.

In the teams I have worked, we are encourage to play team games after work hours to improve the camaraderie within the members. I have collected those thoughts here.

Answer 12

Original Author Smith Janes might have given experience. But these are the typical problems I found in Agile project.

1. Most of the organizations, developers are supposed to work in multiple project, in Agile/scrum.. Sprints are never considered this fact. your Scrum Master assumes you should be done with your stories at the end of the sprint.. Your Scrum master might be dedicated to only one project, but not the developers.. THIS IS THE DISTRACTION-- need not be just taking a phone call or allowing a phone call.
2. I have seen Agile projects where Sprint is planned, Stories included in Sprint, without being huddled..at the half way or middle of the sprints.. developers finding dependencies not resolved, requirements or story is not completed narrated..... This is one of the Abuse in most agile projects.
3. Testing : TTD.. yes it is very good.. but I have seen most of the Agile projects totally relying on TTD... no scope or time allowed for Functional or Human testing.. Another Abuse... Lot of Scrum Masters also do not know or understand the importance of Functional testing. Your piece of code might be working perfect, if does not serves the business need.. it is of no use.. This happens when business do not participate well ahead.. or participation is there... but not reflecting the business decision making.. At the end, developers are blamed, you did not deliver the functionality..or it will end up with last minute change... extra long hours because your Scrum master do not want to take blame for story not completed.

Abuse here... either low participation of business or participant not fully knowledgeable or business person dropping out in middle of sprint.

1. Not All projects are suitable for Agile ... Most of the managers or scrum masters do not know this.. Maintenance projects .. A defect might be initially assumed can be done in 8 hours, accepted in the sprint. After spending 4 hrs, found this is Java/another product... (I recently faced dealing defect related to Quartz Scheduler..inside our project) and this defect could lead to upgrading of product/package..deal with bureaucracy,approval,funding, new version or upgrade should be approved by Internal Engineering etc., 5.Retrospection : only handful of Agile projects does this step.. If at all done..Management, Scrum Master never taken any responsibility of the failed stories..
2. Pairing .. Lot of developers treats pairing as venue to abuse co-workers.. criticize other design, coding practices.. rater treating as team work., learn from each other... Another way of Abusing Agile/Scrum.

Agile is definitely good methodology.. Unless your organization does not follow completely or not trained.... It is Abused.... side effects 60+ work hours/week, blame game, low moral.

Answer 13

To answer your question: No. Agile isn't a form of micromanagement. But like any tool, people can use it incorrectly. Agile is wonderful when implemented properly and when people are consistent with it.

My thoughts on the "Devs not talking to anyone but the scrum master" topic:

I've worked in a place where that was a rule before. HOWEVER, the rule was related more to asking people to complete tasks. For example, I can't randomly go up to a dev tester and ask them to do some testing for me in the next few hours. I need to talk to the scrum master so they can discuss with their team member how that work will fit into the sprint if it's an emergency (or if it needs to be pushed to the backlog for a future sprint).

In that case, I understood the concept of "devs not talking to each other" because it really translated to funneling tasks through one checkpoint so a particular developer isn't overworked or is so busy doing emergency tasks that they can't get their planned work done.

Otherwise, devs SHOULD be talking to each other. Always. It helps you work through problems quicker, become closer as a team, and deliver faster.

Just to offer another perspective: I've also been in an environment where people thought devs "talked too much". After a sit-down, we found out that actually translated to "devs aren't independent enough to get their own work done. Because everything is so fragmented, devs have to go to three other people to complete on small task."

So, when the managers decided to move to agile, they expected that to help bring information to the right places and stop a lot of the fragmentation within the organization. Some people were kind of disappointed that after Agile was implemented, devs were still running back and forth to each other. But, what they didn't realize is that was happening less and less. It took time though. So, maybe if that is what's going on in your organization, it could be that people expected agile to fix things overnight. That's just not the way it works.

Answer 14

Agile is micromanagement in disguise. There is no place for initiative or creativity in Agile, it has removed the fun from programming to allow incompetent managers to keep control even without having a clue from the technical point of view.