87

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.

emallove
  • 101
  • 4
Smith James
  • 587
  • 1
  • 5
  • 8
  • I'm curious, where is this? What kind of company do you work for? –  Mar 15 '11 at 17:09
  • 76
    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
  • 30
    Well, you aren't doing Agile... – CaffGeek Mar 15 '11 at 17:26
  • "Alright folks were doing agile......are we advanced yet?" –  Mar 15 '11 at 18:14
  • Are you working at my company? I agree this trend has become very popular, and is continuing to. The respect for a developer has plummeted to an all time low. – CMR Mar 15 '11 at 19:08
  • 15
    This is really a speech. Not a question. – JohnFx Mar 15 '11 at 19:20
  • 1
    @JohnFx, I guess the question in the title is enough for most developers in the same shoes to understand the intent. – CMR Mar 15 '11 at 19:23
  • 4
    Granted, a rhetorical question is technically a question. They just aren't idea for a Q&A site. Write a blog entry instead, you have a good start for one. – JohnFx Mar 15 '11 at 19:24
  • +1, especially for "I always thought the agile was supposed to bring harmony in the development teams which results in happy developers". LOL. – CesarGon Mar 15 '11 at 19:36
  • I'm also following Agile trends an abuses. http://programmers.stackexchange.com/questions/57972/does-scrum-usually-involve-massive-overtime – DisEngaged Mar 15 '11 at 21:11
  • Well, intent was to post as a question but became bitter and ended up being this :) – Smith James Mar 16 '11 at 00:58
  • Forgot not wanting to do agile, why would you want to work for a company that employs people that think these kinds of "rules" are a good idea? – matt b Mar 16 '11 at 02:36
  • 1
    @matt! Good jobs are few, won't want to jump the ship for another shitty company, so waiting for a right place :) – Smith James Mar 16 '11 at 02:49
  • That makes sense, just make sure you see this practice for what it is – matt b Mar 16 '11 at 03:00
  • Definitely! this is helping me learn how to identify for "dud agile shops" more easily. – Smith James Mar 16 '11 at 03:11
  • 1
    -1 Not an answerable question. Subjective and argumentative. – Rein Henrichs Apr 13 '11 at 21:05
  • 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 Apr 13 '11 at 21:42
  • Well the thing is that agile was developed _by developers_ and not by _management on high_ to maximize dollars. And in fact in most cases you will see extreme resistance by management to implement agile. Obviously this is not agile being practiced in your org, it's just nonsense. – richard Jun 11 '11 at 00:06
  • 1
    "They are not allowed to talk to other developers by their Scrum master" This is not Agile, certainly. Probably not Scrum either. – Sean McMillan Aug 03 '11 at 15:04
  • By the way, we are not using "Agile" any more. The management's agile fever is over :) – Smith James Aug 04 '11 at 22:16
  • 10
    required reading: **[Half-Arsed Agile Manifesto](http://www.halfarsedagilemanifesto.org/)** "We have heard about new ways of developing software by paying consultants and reading Gartner reports..." – gnat Dec 18 '12 at 06:55
  • Scrum is 100% snake-oil. – Erik Reppen Dec 20 '12 at 06:11
  • 4
    Hmm.. although to be fair, what your Scrum Master was doing there appears to more closely resemble something that involves leather outfits and gimp masks than what I learned about Scrum. – Erik Reppen Dec 20 '12 at 06:22
  • Agile simply means "Short Leashed" - developers no longer can "Surprise" their employer as they have to report daily in a "Standup Meeting" exactly what they done and fail to deliver. – Swab.Jat Dec 20 '13 at 11:00
  • The "new" micromanagement? Not hardly. It's been around since 1997, some components earlier. If they didn't start doing agile years ago why would you want to work there unless you had to? – Don Branson Jan 06 '14 at 21:36
  • 2
    Why is it every time someone points out a problem that people run into when trying to practice agile the standard answer is "well that isn't agile"? Yet, people who promote agile as the one and only way are so quick to say that waterfall has been proven to not work. They make these claims despite thousands upon thousands of waterfall-like success stories. Why don't the agile people have the same ability to look at failed waterfall-like projects and decide that it was the implementation of the process that failed and not the process itself? – Dunk Nov 12 '14 at 21:41
  • 2
    @gnat +1 for the correct spelling of "arsed". – Stephen Apr 15 '15 at 23:34

14 Answers14

99

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.

Sami Lehtinen
  • 722
  • 5
  • 6
  • 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
  • 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. – Berin Loritsch Mar 15 '11 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. – Kevin Cathcart Mar 15 '11 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. – Berin Loritsch Mar 16 '11 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 Mar 16 '11 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. – Erik Reppen Dec 20 '12 at 06:13
48

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

Reed Copsey
  • 1,001
  • 6
  • 7
  • 31
    It is absolutely against the very first principle of the Agile Manifesto: "Individuals and interactions over processes and tools". See http://agilemanifesto.org/ for more information. – Berin Loritsch Mar 15 '11 at 17:16
  • "It is absolutely against the very first principle of the 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
  • @Berin - As I commented below too, from the perspective of the scrum master, the agile team is interacting for their needs within their teams to get the job done, so how's it against agile. They are not being allowed time for casual chat with their buddy 'cause "the master" is watching how much their time is being utilized in the 8 hours period. – Smith James Mar 16 '11 at 02:53
  • @Berin & @Reed - Furthermore, they have tasks broken down into 1,2,4 hours increments, and their progress is being observed in the burned down charts for the team(2 people), if they are on track or not. For that very reason, the scrum master is there to make sure developers are busy doing stuff as I hear. Doesn't this create an invisible pressure on a developer to meet his/her goals? – Smith James Mar 16 '11 at 03:01
  • 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? – Berin Loritsch Mar 16 '11 at 11:51
  • @Smith James, a scrum master's job is pretty simple. The types of distractions they need to protect the team from are related to the management chain and unnecessary tasks. We are social beings, and we need to let our minds rest from what we've been concentrating on for a long period of time. It's a fallacy to think that by cracking a whip and increasing quotas (historical American slavery 101) is going to improve productivity. Many times I get my best inspiration after having been "distracted" for a moment and am getting back into the flow of things. It's because I have a fresh view. – Berin Loritsch Mar 16 '11 at 11:56
  • @Berin Loritsch: I hear you. But the Agile Manifesto, as any other manifesto, is a broad generalisation of a much more complex world. Boldly declaring "Individuals and interactions over processes and tools" and making that a guiding principle is, pretty much, putting on a nice pair of blinders that hide the fine nuances of the real world. That's what cults do: everything is either black or white; you are agile or you are not; there are no greys, no mid-tones, no unlabelled things. C'mon. – CesarGon Mar 16 '11 at 20:02
  • 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 00:30
  • +1 - @Reed Copsey - Very glad to see a developer of your calibre join the PE talks. – P.Brian.Mackey Apr 13 '11 at 20:58
31

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.

Kyralessa
  • 3,703
  • 2
  • 19
  • 20
jjb
  • 444
  • 3
  • 3
27

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.

Tom Anderson
  • 3,022
  • 19
  • 24
  • -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 08: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 Dec 15 '12 at 12:20
  • 7
    @nes1983: I wrote that in 2011. Things were different then. – Tom Anderson Dec 15 '12 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. – Erik Reppen Dec 20 '12 at 06:17
  • 3
    +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 '14 at 20:31
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.

William Pietri
  • 3,060
  • 1
  • 17
  • 20
  • 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](http://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783/ref=sr_1_1?ie=UTF8&qid=1300235670&sr=8-1) and put all the BS behind. These practices are not for IT shops is my conclusion. – Smith James Mar 16 '11 at 00:52
17

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.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • Have them deliver running, tested software to the users, every 2/3 weeks, you mean? – user272671 Jan 07 '16 at 07: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 Jan 07 '16 at 08:29
11

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.

9

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

jwenting
  • 9,783
  • 3
  • 28
  • 45
  • 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? – J. M. Becker 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
7

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.

Ian
  • 5,462
  • 22
  • 26
  • 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 02: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
2

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.

DeveloperDon
  • 4,958
  • 1
  • 26
  • 53
1

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.

Vinod R
  • 381
  • 1
  • 4
  • 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. – J. M. Becker Dec 16 '11 at 10:43
-1

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.

mukunda
  • 1
  • 1
  • see this link.. why Agile projects fail..http://www.brighthubpm.com/agile/55778-why-do-agile-projects-fail/ – mukunda Mar 10 '13 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 Jan 08 '16 at 22:06
-1

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.

JustBlossom
  • 339
  • 1
  • 9
-2

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.

geo
  • 1
  • 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 01 '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 02 '13 at 01: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 Jan 08 '16 at 21:59