Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 4 developers in an agile group on a trial basis. It has been 4 months with 3 iterations and they continue to do it without going fully agile for the rest of us. This is due to the fact that management's trust to meet business requirements with a quite a bit of ad hoc type request from high above.

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 by their Scrum master and are not allowed to take any phone calls in the work area (which maybe fine to an extent). For example, if I want to talk to my friend for kicks who is in the agile team, 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 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 stones and is customized differently for each company. Well, it all sounds good and reason.

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 a very opposite feeling when talking to the developers in the agile team. They are unhappy that they cannot talk 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 feels that they don't like to work in an environment where they only breathe work because they are at work.


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

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

My feeling is that someone in the management behind the door threw out this idea, that 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.

share|improve this question

migrated from stackoverflow.com Mar 15 '11 at 17:09

This question came from our site for professional and enthusiast programmers.

59  
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. –  Berin Loritsch Mar 15 '11 at 17:20
19  
Well, you aren't doing Agile... –  CaffGeek Mar 15 '11 at 17:26
8  
This is really a speech. Not a question. –  JohnFx Mar 15 '11 at 19:20
6  
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 Apr 13 '11 at 21:42
6  
required reading: Half-Arsed Agile Manifesto "We have heard about new ways of developing software by paying consultants and reading Gartner reports..." –  gnat Dec 18 '12 at 6:55

13 Answers 13

up vote 76 down vote accepted

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.

share|improve this answer
    
There are many practices (like pair programming, automated unit testing, etc.) that support Agile. "provide a complete vacuum for ... developers" isn't one of the practices I've ever heard of. But maybe it's a recommended practice somewhere. –  S.Lott Mar 15 '11 at 18:54
5  
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. –  Berin Loritsch Mar 15 '11 at 19:12
4  
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. –  Kevin Cathcart Mar 15 '11 at 19:58
3  
@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. –  Berin Loritsch Mar 16 '11 at 11:59
6  
@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 Mar 16 '11 at 12:30

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

share|improve this answer
26  
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. –  Berin Loritsch Mar 15 '11 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 Mar 15 '11 at 19:37
4  
@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? –  Berin Loritsch Mar 16 '11 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. –  Berin Loritsch Mar 16 '11 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 Mar 17 '11 at 0:30

That sounds like a pretty perverted 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.

share|improve this answer
1  
+1 estimating relative complexity –  flamingpenguin Mar 15 '11 at 17:25

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.

share|improve this answer
3  
+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. –  Smith James Mar 16 '11 at 0:52

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.

share|improve this answer
    
-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 Jun 11 '11 at 8:04
3  
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 Dec 15 '12 at 12:20
2  
@nes1983: I wrote that in 2011. Things were different then. –  Tom Anderson Dec 15 '12 at 13:00
2  
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. –  Erik Reppen Dec 20 '12 at 6:17
    
+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 Nov 20 at 20:31

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer
    
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? –  TechZilla Dec 16 '11 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 Dec 16 '11 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.

share|improve this answer
    
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. –  Smith James Mar 16 '11 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. –  Berin Loritsch Mar 16 '11 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.

share|improve this answer

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.

share|improve this answer
    
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. –  TechZilla Dec 16 '11 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.

share|improve this answer
    
see this link.. why Agile projects fail..brighthubpm.com/agile/55778-why-do-agile-projects-fail –  mukunda Mar 10 '13 at 20:38

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.

share|improve this answer
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. –  Bryan Oakley May 1 '13 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 May 2 '13 at 1:41

protected by ChrisF Dec 20 '13 at 11:14

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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