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.

  • 79
    I have seen more abuses in the name of agile than I care to comment on. Many times "we're doing agile" means "we're throwing away all semblance of process and doing what we want, Yeehaw!" (for the obvious cowboy reference). A quiet environment definitely helps, but you have to allow for developers to talk to each other and hammer things out--without scrum dictator approval. Commented Mar 15, 2011 at 17:20
  • 31
    Well, you aren't doing Agile...
    – CaffGeek
    Commented Mar 15, 2011 at 17:26
  • 16
    This is really a speech. Not a question.
    – JohnFx
    Commented Mar 15, 2011 at 19:20
  • 9
    2 days on the certified scrum master course does not make manager a scrum master, just like 24 hrs with teach yourself c++ in 24 hours doesn't make you capable c++ programmer. They're just doing it wrong.
    – Matt
    Commented Apr 13, 2011 at 21:42
  • 10
    required reading: Half-Arsed Agile Manifesto "We have heard about new ways of developing software by paying consultants and reading Gartner reports..."
    – gnat
    Commented Dec 18, 2012 at 6:55

14 Answers 14


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.

  • 7
    The only thing close I could find was a "Joel on Software" post on the top 12 things every company should provide for their programmers. One of the 12 was a quiet place to work. I doubt Joel Spolsky meant this, though. Commented Mar 15, 2011 at 19:12
  • 5
    A quiet workplace would be one where if you are not having a conversation, things are generally quiet, and where you can have a conversation without disturbing others. That means no culture of paging people over the intercom, and use of white noise generators or other methods of minimizing the apparent level of sound in areas where many people work. A no talking rule does not make a quiet workplace. Commented Mar 15, 2011 at 19:58
  • 6
    @Kevin Cathcart, we are in violent agreement on that one. Now, I've been in a company where the opposite was true. We had ~40 people in a bullpen with open tables and no cubes. The only team that could get anything done was the one that made the majority of the noise. That's the type of environment you want to protect against. Commented Mar 16, 2011 at 11:59
  • 8
    @Kevin - My development department is an open cubicle farm, right next to an array of three bells labelled "Sale", "Big Sale", and "Huge Sale". A few times a day, sales people ring those and yell "wooooo!". :-\
    – Dan Ray
    Commented Mar 16, 2011 at 12:30
  • 3
    @Dan I had a string of interviews a few years back where three startups told me they had to move the sales guys away from the devs because they were too !@#$ing loud. Commented Dec 20, 2012 at 6:13

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).

  • 31
    It is absolutely against the very first principle of the Agile Manifesto: "Individuals and interactions over processes and tools". See agilemanifesto.org for more information. Commented Mar 15, 2011 at 17:16
  • "It is absolutely against the very first principle of the <XXX> Manifesto"; replace anything for XXX, and you'll have your choice cult. ;-) Seriously, doesn't this make you wonder?
    – CesarGon
    Commented Mar 15, 2011 at 19:37
  • 5
    @CesarGon, in this case we are talking about the principles of what makes agile work. If you can't ascribe to the core principles of agile, then maybe you don't want agile. Pretty simple. I'm not saying "convert to the faith", I'm saying "do what you say you believe". Seriously, doesn't that make you wonder? Commented Mar 16, 2011 at 11:51
  • 1
    @CesarGon, what the OP described is about the polar opposite of the intent of that guideline as you can get. At what point do you consider your mid-tone close enough? The way you are talking it sounds like a 95% difference between tones is close enough. C'mon. And give me some credit. I've been working in the real world and defining processes in corporations for a long time. I understand quite well what's close enough--and what the OP described is not it. Commented Mar 16, 2011 at 20:09
  • 2
    @Berin Loritsch: I do give you credit; it wasn't my intention to appear otherwise. My initial remark about cults tried to sound partially joking, actually. The point I am trying to make is that we don't need a few lines on a manifesto to defend something that is blatantly against common sense. The OP describes a situation that makes all alarms ring. I hope you take it nicely; sorry if I was too harsh. :-)
    – CesarGon
    Commented Mar 17, 2011 at 0:30

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.


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.

  • -1, I don't agree. Agile development also means that you purify and ease processes and also the ability to adapt to changes. Which happens to be exactly what Scrum is about. Scrum is also about requirements and planning, just differently.
    – Falcon
    Commented Jun 11, 2011 at 8:04
  • 6
    Eh, c'mon, this is 2012. Quote Kent Beck's public writing or leave it. Doesn't matter if he flatulated on your couch.
    – nes1983
    Commented Dec 15, 2012 at 12:20
  • 7
    @nes1983: I wrote that in 2011. Things were different then. Commented Dec 15, 2012 at 13:00
  • 3
    I never heard the term "technical debt" until scrum popped up on my radar. I've been to the training. Easily sold Snake Oil meant to appeal to management at the expense of long term product quality considerations. 100% bullshit. Although I would totally swallow it if Scrum Masters got to carry a Conan-style sword to womp people who threatened the integrity of the process with. Commented Dec 20, 2012 at 6:17
  • 4
    +1 for the Scrum rant. I think of Scrum as the "Agile" methodology for people who like waterfall so much they want to do it every two weeks.
    – Kyralessa
    Commented Nov 20, 2014 at 20:31

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.

  • 4
    +1. Agile/scrum/xp or whatever are just "mumbo jumbo" terms for IT shops that are not actual software companies. As you said, no one to make radical changes while burying their head in the sand with these practices. All one needs to read is this great Lean Software Development: An Agile Toolkit and put all the BS behind. These practices are not for IT shops is my conclusion. Commented Mar 16, 2011 at 0:52

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.

  • Have them deliver running, tested software to the users, every 2/3 weeks, you mean?
    – user272671
    Commented Jan 7, 2016 at 7:59
  • 2
    @user272671 NO. Have them deliver running, tested software to the user regularly. Not on a stupidly arbitrary schedule like 2 or 3 weeks. If the users or the software complexity is such that a 6 week cycle work, then do 6 weeks. If it can be done on an "when completed" then do that. Do not hamstring yourself with artificial constraints. Such is not agile.
    – gbjbaanb
    Commented Jan 7, 2016 at 8:29

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.


"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.

  • 1
    In my experience.. I have only ever heard agile (always scrum) introduced to explain micromanagement. I won't deny, It is a Different and unique style of micromanagement. I've never heard a dev say they are agile, and explain a short coming. What kind of management forced scrum have you experienced? Commented Dec 16, 2011 at 10:48
  • 1
    whenever I've encountered scrum it was introduced because a manager (usually higher than project manager) had heard about it as being "the thing".
    – jwenting
    Commented Dec 16, 2011 at 11:01

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.

  • Well, "Individuals and Interactions" are what they are doing right now within their team. How is it going against agile manifesto, if you look from the Scrum master point of view? The issue right now is that they are Not to have any interaction with other teams so to keep up their productivity, which is the cause of complain of the agile group. Commented Mar 16, 2011 at 2:36
  • They aren't interacting. That's the problem. Sure a developer can abuse privilege and talk about meaningless stuff for hours. However, most good developers want to deliver a quality project. It's a matter of pride. Everything the scrum master is doing undermines that, and instead makes it a matter of repression. This is not what agile is about. A scrum master should enable the team to be productive, not crack a whip and tell them to be productive. They already want to be productive. Commented Mar 16, 2011 at 12:08

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.


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.

  • 1
    Develop work relationships after work, We should develop our often neglected friend and family relationships after work. Considering Co-Workers are rarely friends, and take most opportunities to help themselves at others expense. The company yes-men, cronies and tools just don't realize it, because the opportunities are infrequent. XP might have some value, I have no experience to say otherwise. Scrum has become different version of micromanaging, at least at the 3 or so companies I've known it. .... Ya know what, I hate Corporate America far too much to be even slightly objective. Commented Dec 16, 2011 at 10:43

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.

  • see this link.. why Agile projects fail..brighthubpm.com/agile/55778-why-do-agile-projects-fail
    – mukunda
    Commented Mar 10, 2013 at 20:38
  • I happen to agree with the information presented in that article there too. I understand that there are those who think Agile is infallible, but the reality is Agile leaves little or no room for the introduction of new and more effective ideas. is..brighthubpm.com/agile/55778-why-do-agile-projects-fail
    – user272671
    Commented Jan 8, 2016 at 22:06

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.


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.

  • 2
    You couldn't be more wrong. In agile, teams should have a very large amount of creative control. Agile requires an extreme amount of initiative, since it is the team that decides how to implement every story. Management actually has very little control over the agile process. Personally, the three different agile teams I've been a part of have been extremely fun. It sounds like you've experienced some severe incompetence that self-identified itself as agile without being anywhere close to agile. Commented May 1, 2013 at 23:23
  • add some reasoning to support your assertion (which makes certain sense to me but that doesn't matter), and I'll remove the downvote
    – gnat
    Commented May 2, 2013 at 1:41
  • 2
    I agree with @Geo. To date, that is the impression I have of what "Agile" is, in the real world. When you have such a setting on the factory floor- it is simply a form of micromanagement. Now the Manifesto tries to tell us it is not. But project after project, I am led to believe even more that is it is simply another name for "Micromanagement". And it does kill creativity.
    – user272671
    Commented Jan 8, 2016 at 21:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.