What do you not like (or even hate) in Agile development? I mean SCRUM, XP or any other light process.

+20  A: 

I hate the expectation that it will solve all problems.

Amen. Agile doesn't solve problems: it exposes them so you can fix them yourself.
Or the argument that because it doesn't solve all problems that it (and any part of it) is useless.
Bruce McGee

I, personally, don't think there's anything not to like. Unlike a more rigid process (see CMMI), you aren't required to do everything to be "Agile" or be using "Extreme Programming" or so on. If something doesn't work in your organization, then you either don't have that step in the process or you replace it with something that does work.

However, that said, I think the biggest problem with the agile methodologies is not the agile processes themselves, but the people who don't get them, and think that an agile process alone will save the world. Well, it doesn't. It's just a process.

Thomas Owens
+58  A: 

The zealots.

No process is perfect, but zealots won't listen to any criticisms of their preferred methodology. If you try it, and it doesn't work, it's got to be a problem with you; it can't be a limitation of the methodology.

In this sense, agile methodologists are no different from other methodologists, but to me the agile zealots are just a little more shrill than the more traditional zealots. Agile proponents claim to care about people and results more than formalities and procedures, but they will scream at you if you don't follow their rules to the letter. This makes them seem a little more hypocritical than other zealots.

Because agile methodologies are relatively new, there are a lot of pro-agile people who have not been in the industry very long (if at all). They have never worked in a non-agile environment, but they are sure anything other than agile can't possibly work. They really have no idea what they are talking about, but they are sure they have all the answers.

There are also a lot of fake zealots. They claim to be following an agile methodology, but are really not following any methodology at all. They ignore the planning, scheduling, testing, documentation, and management aspects of the methodologies. To them, "agile" means "Just bang out code and ship it as quickly as possible. We can always fix it later."

BTW, I am a pro-agile person myself. I just hope I never become one of Those People.

Kristopher Johnson
Really? The traditional Java zealots from '96 and OO zealots before them were much shriller, in my experience. At the height of the OO hype, you couldn't suggest there was something good without putting it under the OO umbrella first. I've been thinking the Agile movement is relatively tame.
Alan Hensel
Well, I was an OO zealot, so it didn't seem shrill to me.
Kristopher Johnson
"BTW, I am a pro-agile person myself. I just hope I never become one of Those People." - we all hope not to become one of those people.
David Basarab
Amen. +1 I refused to be 'converted'. My 28 years of old-fashioned coding methods have never failed me. When they do, I will reconsider.
Optimal Solutions
I am back in school doing a MS in IT and focusing on project management and business analysis within software development. In my classes the Waterfall Zealots coming from gov't suppliers are surprisingly vocal. I would never have guessed this ahead of time. They are VERY dedicated to waterfall.
Scott Alan Miller
"What's the difference between a terrorist and a methodologist? You can negotiate with a terrorist." So yeah.
+28  A: 

The assumption that if you are not using Agile you are using some 1970s form of "Waterfall".

I'm so sick of reading about how much better Agile is compared to Waterfall, where the classic waterfall example they use is only seen in some strict and obscure military project somewhere.

I'm back in school doing a Masters in software management and the classes are filled with military contractors doing 70s waterfall projects. Many of them swear that that is the only viable way to do a project and that iterative methodologies are unprofessional. AAAAHHHH!!!
Scott Alan Miller
The "classic waterfall" example is an example of a software development methodology that DOESN'T work -
Scott -- proof positive that "many things worth learning, cannot be tauhgt."
Aaron F.
That's like saying your make and model of car is the best, because it's better than a horse...
Bob Moore
Are they writing in ADA?
Warren P
+3  A: 

Pair programming and standup meetings.

Pair programming is a little overrated, I think, but standup meetings a nice, in my limited experiences with them.
Thomas Owens
Pairing depends heavily on who you're pairing with, and how "pairable" the task you're working on is. Stand-ups should take 15 minutes or less, so that can't be a big complaint.
Alan Hensel
I like how standups are always justified only by how inoffensive they are. :P
Standups are good for making sure everyone is on the same page for the day's tasks, along with anything that came up during the day yesterday that might put a kink into those plans.
Thomas Owens
On a couple of recent projects of mine using standups, there have been few interpersonal dependencies. Development would have proceeded just as well without standups, and I could've come into work later. :PIt provides something for people's egos, or they just assume it's good. I think it depends.
Comments are 300 characters. With more space I would have made a more spirited defense of stand-ups. Sometimes it seems pointless, but then to some extent it is preventative, against a developer spinning his wheels. It also raises team awareness. And managers and stakeholders like getting status.
Alan Hensel
In a project with a good tech lead, code reviews, and a mailing list, standups are totally redundant. I can imagine other types of projects where standups are a necessity, but I'm glad I don't work on them. :P
In the defense of standups, some people need a forum where they are "forced" to talk about what they are doing. I am naturally an introvert and sometimes need a little coaxing. Pair programming is very effective when two devs of different skill levels are placed together. My experience
All for standups here too, but never had a good experience pair programming. I just don't think us programmers play well with others :)
+11  A: 

The only problem I have is with poor implementations of agile. :)

Too often, people/groups/management/whatever use agile development as an excuse to forego important pieces of the software development puzzle. Specifications and documentation are often the first things sacrificed in an "agile" environment. Unsurprisingly, many of the agile projects I see in my company are several months behind schedule.

Gabriel Isenberg
+1 - I hate the cherry pickers who pick out the practices they like (no documentation) and ignore the practices they don't (testing/CI).
Mark Roddy
I see a lot of self-described "agile developers" who do no planning or scheduling at all. All the agile methodologies have planning and scheduling phases, and those are important for managing expectations and risk, but they are not fun and so they get thrown overboard.
Kristopher Johnson
+10  A: 

I don't like dealing with naysayers, or the fanboys, or the grizzled verterans who think there's nothing new under the sun, or basically anyone who does not approach it pragmatically. Agile is a tool, but it is also a paradigm shift to many, so it will take a generation for this to settle out.

Alan Hensel
+3  A: 

Agile is a tool that lends sanity to what is normally a chaotic development process. However, it's simplicty can be deceptive - you have to work just as hard, and the problems are not any easier. But when applied correctly through SCRUM meetings, story sizing, appropriate inter-team communication, and other proven development practices, it's the best thing out there. The other required piece that most developers fail to recognize, is that Agile has to be something the entire business subscribes to. For example, the CTO must understand the benefits and risks and support the movement and application of the process, the team managers must do the same and the product owners must understand their piece and what the Agile process means for their customer interactions. Developing software is a very expensive process, so time to market for any software product can make or break your business.

Agile foundations for developers mean solid application of design patterns and principles. Write good code so that you can adapt it quickly (Agile), you can test it quickly (Agile), release it quickly (Agile). Open-Closed principle, MVC, coherence, cohession, seperation of concerns, etc. You must know these things and you must apply them to be able to fulfill your obligation as a productive software engineer on an Agile team.

Agile is not the end-all-be-all. It is a powerful tool for any development organization that needs to respond quickly to market trends. Coupled with solid practices and skilled developers, it really can do wonders.

And, there's nothing I don't like about Agile.

+56  A: 

I don't like seeing people focus on "what" and missing "why". The big issues--accountability, responsibility, empathy--often get short shrift compared to the more inflammatory (and I suppose temporarily more entertaining) "Pair Programming: The One True Way or a Fundamental Assault on Programmer Rights?"

What matters in all of this is what we're trying to accomplish, each in our unique way in our unique context. If I'm striving to be accountable and transparent, certain kinds of techniques are likely to arise, but the techniques aren't the point, the big goals are the point.

Kent Beck
But that's going the be the case in any methodology. The whole point of Agile (read the manifesto) is that it's about people and getting the job done as opposed to a process.
I don't think I could argue with Kent Beck, but I must say that I really like the logic. I'm guilty of forgetting the big picture myself, and it hurts. A lot.
Thomas Owens
Frew, if this really is Kent Beck, chances are he's more familiar with the Agile Manifesto and its underlying assumptions and intentions than we're ever going to be. Regardless, he's making a very good point.
Jason Etheridge
Frew, that guy did sign the manifesto....
"We're not worthy...." Just kidding, but Kent has definitely taught me a lot.
Charlie Flowers
@Frew: "it's about people and getting the job done as opposed to a process"; that was (and is) *always* the point. Sometimes we're not smart enough and we screw it, but that doesn't mean that "getting the job done" has ceased being the point, ever.
+2  A: 

The problem I saw when we went Agile was that while most developers caught the gist of it pretty quickly, middle management had a much harder time adapting to their transmogrified responsibilities. With all the new-found "free time" on their hands, they swung erratically between playing solitaire and running around like headless chickens micromanaging random people in the pods, while at every scrum meeting praising the team and the Allmighty Agile.

Agile doesn't necessarily solve problems inherent in your organization, it just shines a different light on them.

+8  A: 

It becomes a farce when you've got a fast-paced production environment and the business expects you to fix certain problems immediately instead of waiting until the next scheduled release. It throws everybody for a loop. All the planned release dates get hosed. Sales freaks AGAIN because not only are customers affected right now, but their promised dates are messed up. Meanwhile, devs, qa, and deploy staff all get thrown into this moment's notice mentality. Sloppy code, poor testing, and deploy mistakes abound. Then they're busy trying to still make the original dates only to find out that after all of Sales' bitching, the customer was okay with the delay. But guess what, since yr code sucked and and qa missed the issues... you've got a new prod issue that must be fixed asap!

Seven sprints later, you're really wondering why you still work here and how Agile is supposed to handle this.

(Cause when you suggest a second, prod support team that operates in a non-Agile way, they look at you like you're crazy.)

I've seen this too, and the important thing to note is that in any of the agile methodologies, there can be NO change in scope DURING an iteration. It's like changing the engine in a car - you can't decide half-way through that you'd rather just have new hub-caps without affecting anything.
If that is the kind of environment you are working in, no methodology is going to work except code and fix @MadKeithV - I respectfully disagree. If a client wants to change task priorities and swap tasks with a different iteration, then go for it provided it takes ~same amount of time, hasn't been started, and doesn't affect other tasks. Changes in scope are not ideal but agile seems to handle them during an iteration reasonably well
@i8abug - IMHO, if scope isn't fixed during an iteration, you aren't doing an iteration, full stop. You can keep calling it that, but you'd be deluding yourself: your team will *not* know what delivery is expected of them at the end of the iteration.
+5  A: 

Disclaimer: I have only seen one application of the agile methodology, so please take my observations with a grain of salt.

I think the biggest problem is that agile promotes short-sightedness. There seems to be a tendency to achieve the goals of the sprint at any cost, which includes applying "quick and dirty" solutions, which are in fact poor design decisions, which come back to haunt you in the future.

I have observed that typically the goals of a sprint include implementing new features, as opposed to thinking through the design, code review, or refactoring. As a result, the quality of code suffers. The quick and dirty fixes accumulate, and virtually no time is allocated to rethink the design and clean up the code, because the next sprint is dedicated to implementing the next feature.

You may say that this is because agile is applied incorrectly. However, I think that the habit of focusing on the small short-term tasks, and quickly moving on to new tasks makes it very easy to lose sight of the big feature and to never look back, which in turn allows crappy code to accumulate and rot.

You really don't need to do agile to get into a "features features features!" mode of thinking. Your management will NEVER ask your developers "hey guys, why don't you spend a few thousand more in man-hours making that code beautiful?"

I've given almost all of my votes on this very question! I just like the way I develop software. The way I have been doing it for 28 years. I have never had a problem. Not until someone tries to 'convert' me to some new-fangled idea. Then the sparks fly. I have turned down jobs that force me to code in such ways.

Optimal Solutions
+3  A: 

I've seen the same kind of crap they use in American sales teams crow-barred into things like Scrum and perhaps its my Englishness but I don't buy into the idea of forcing everyone to accept particular social norms.

People are different, yes you come together to produce a product so you have to follow some conventions but forcing things like stand up meetings or pair programming upon people doesn't always work. Your management has to adapt to the team you are working with, the team shouldn't always be forced to adapt to the system. It's a process of influencing in two ways, with Agile you endeavour to influence the developers in the team to adopt certain practice but by the same rule the process should be influenced by the character of the development team. One size does not fit all.

The irony is that some Agile implementations are not actually very Agile in reference to their implementation of Agile itself (the whole: "OMG you have do ALL of Agile 110% to be Agile"). In this scenario the aforementioned influence just becomes one-way traffic from the process to the group. As a developer in the group you have to adapt to the process or you become alienated. That isn't a pragmatic approach and can lead to higher staff turnover and low morale amongst certain members leading to a cliquey situation (those who buy in vs those who don't).

That said, Agile does have some serious awesomeness and if applied pragmatically is totally the way to go.

No. Its not your "Englishness". I totally agree. :-)
Optimal Solutions
+13  A: 

I think agile becomes Fragile in the wrong hands!

John Cleese
Argh, can't decide whether to upvote or downvote the bad pun! (so I'm doing neither :p)
So does traditional methods (waterfall, anyone?). The difference is probably that traditional methods are already embedded in most companies. Agile is not and it's usually not philosophically or HR in tune with Agile flat model, etc.
+3  A: 

When your CIO refers to it as "nimble" instead of agile because it is just a buzz-word to him.


I suppose this applies to pretty much any methodology or framework but taking what it says in the book as the only way to do it leads to a lot of failures and is something I don't like in many peoples implementations of Scrum and a host of others.

With Scrum (as with any method/framework) you need to look at what it is recomending and then tailor it to your particular situation, product, company style and people. This is at least as hard as actually using it successfully but if you don't do it, you are making life even harder for yourself.

+1  A: 

The name. It's not "agile". Used to be called 'lightweight methods' till this brand name was chosen. I prefer to call it 'reactive programming'.

The cheap managers who cherrypick the advantages of the method (no/little documentation, informality) without wanting to pay it's price (no fixed price, increased communication).

I thought it used to be called RAD :-) (RAD nowadays seems to mean Excel development in Front Office banking applications). Or maybe DSDM...
+10  A: 
  1. I don't like the misconception that it's a "methodology". Agile is really, to my mind, a philosophy ( and a set of practices that are consistent with that philosophy (XP, scrum, et al).

  2. I don't like the binary nature used to interpret efforts to implement agile. It's not "I'm agile and you're not". Agility is a continuum - not a destination. If you start doing stand-ups, you will probably increase communication, which should increase your agility. It doesn't make you agile. Nor does pair programming. Or continuous integration.

  3. I don't like efforts to constrict practices in the name of agile. "Sprints must be 4 weeks. I read it in the book !". Agility is about rabid inspection and adaptation to find the best way for YOUR team to deliver working software.

Adrian Wible
Totally agree with you, it's a philosophy which can be applied in various situations. It's the way you look at the world. It's not a prescribed practice.
Igor Brejc

Your QA has very little to set a test plan against.

There is no documentation from projects done a year ago.

Software is not slam dunk for applications, maybe for a fix.

I know it is just a patch for terrible requirements.

Bulletproof requirements are rarely useful in this climate of rapid change. If you code to a solid spec, there's a good chance the problem will have changed enough by the time you deliver to make what you implemented a poor solution. agile attempts to account for that. Think machine gun, not mortar.

I tend to be undisciplined and if the process is not "set in stone" I will take shortcuts. Agile methodologies seem to allow for more flexible interpretation of the process that is software development.
For example it seems that you can mix scrum and xp and end up with "scruxp" and then anything goes. Every dev introduces their version of their favorite agile methodology.

No methodology is a methodology

+1  A: 

Extending Mr. Beck's response (If I had a penny for everytime I see this.)

  • Picking whatever you like from the basket of practices,
  • ignoring the principles underneath,
  • sweeping under the rug the grave cultural and discipline issues
  • complaining this thing is overrated or doesn't work.. without making a real effort or trying to understand why you're doing something
  • the 'Reap before you Sow' miracle expectations from agile
  • Not getting the important pieces of the agile jigsaw. Planning and People.
+6  A: 

If I wanted a house built for my family I would:

  1. Talk to my wife and agree what we wanted
  2. Go to an architect and tell him what we wanted. He might give advise on why some of what we wanted wasn't feasible. He might also give advise that we could get an extra bedroom for little extra effort/time/cost.
  3. The architect would hopefully be up on all the latest building technologies and so know what's possible, what building standards to adhere to, etc. If he wasn't he might talk to somebody who was.
  4. The architect would draw the plans of our house. We would review them and together rework until we had agreed what we were getting.
  5. We would commission some builders, ask if they could build to the plans we had, how long it would take and how much it would cost.
  6. If it cost too much, we could get quotes from other builders. Or, if we weren't prepared to pay the cost, discuss with our architect about trimming down the design - concentrating more on the bare essentials.
  7. Once we knew what were going to build, how long it would take and how much it would cost, we would enter into a contract with the builder.
  8. The would build the house. We would review his work as he went along. If he seemed to fall behind, we would ask questions and escalate. If he did a lousy job, we would ask questions and escalate.

Call me old fashioned but you'd be mad to do it any other way.

And I know you're going to say a software solution isn't like a house because you can live with half a software solution but you can't live (realistically) with half a house... but (a) a lot of the time that's just not true and this analogy is a good one and (b) even if it is true, it's just resigning yourself to delivering half of what the customer actually wanted.

If you've ever built a house, you know that those are never delivered on-spec, on-time and on-budget unless your budget was insanely inflated in the first place.
"it's just resigning yourself to delivering half of what the customer actually wanted". Yes, but in half the time (continue dividing until you readch your iteration length).
Jim Arnold
One place your metaphor fails is that requirements for a house can be fairly well spelled out at the start. That is rarely the case in software. There are many examples of software that was built exactly on spec but is worthless because by the time it was finished the target had moved significantly.
Also: houses can't change so easily as they're being built. Want a bathroom where you might have had a bedroom? If you've got the plumbing in the wrong place, forget it. The methodologies that don't need big-up-front-design recognise that software is more tractable.
Jeremy McGee
The main problem is that you can look at an architect's specification (picture and plan) of a house and know what to expect. I don't think it's so easy (there's no equally compact notation) to specify software.
+2  A: 

Methodologies are a tool box, use the best one for the job at hand. Don't try to force a solution onto a problem because you happen to like it better.

As far as Agile is concerned, I like most of it. It tends to work in smaller IT shops than larger ones in my experience.

However there is one aspect of it that I absolutely hate (though I've never actually witnessed anyone do it). Agile states that you should have 2 developers to each workstation. One coding and one watching, with the idea that 2 sets of eyes can code better. There's no way I could write software with someone looking over my shoulder all day, I think the premise is ludicrous and doesn't take into account human nature (a person's need for personal space). If someone ever tried to get me to code like that I'd quit the job immediately!

+1 for the first point. However, pair programming is not necessarily a part Agile; it is usually associated with eXtreme Programming, just one type of Agile.
+2  A: 

I dislike the perception, and occasionally the practice, that documentation, specs, and architecture are "bad things."

I like a lot of the practices of Agile and XP both, but every once in a while it's a good idea to get an overview of the entire project and get some of it written down from that standpoint, or do some planning for the future, or leave notes for the people who will come after original developers, and sometimes this gets discarded or denigrated, which has a habit of turning "agile" into "fragile" and worsening management's view of those practices.

J.T. Hurley
Agile never said documentation is bad. It says HEAVY documentation is bad because of the maintenance cost over the value. That's fuzzy definition I agree, and to be clarified. What it says is that you should definitely write it, but more concise and possibly in another way (like some documentation as unit tests in a specially written form, see PHPUnit).

When the term "agile" is used to hide laziness. Some will try to go too far with the avoidance of documentation to start building and look busy without a clear enough plan. Sometimes this can also happen when the developers are "drinking from a firehose" with respect to receiving requirements.


I don't like people using it as an excuse to write code wild west style.

Stephane Grenier
+1  A: 
  1. People thinking 'Agile' type methodologies are all that new. (some of us been doing what used to be called 'RAD' [amongst other things] for nigh on 15 years...)
  2. Not realising that the most important bit is, as ever, talking in the right way to the right users about the right things.
  3. Not enough consideration given to whether it suits the development staff - i.e works really well when people are good - but then so will almost anything....
  4. When it's a poor fit for the larger organisational bureacracy - and you have extreme (he, he) trouble getting you project through the institutional processs (e.g. project milestones...).

In general, I dislike people getting hung up on any particular methodology....


I don't like it when agile zealots won't let you adapt Agile to your environment and business needs. No approach should be static or will fit all circumstances. One should focus on the management (SCURM) and engineering (XP) practices and adapt them where needed to do what is important, deliver working software.

If your team is highly functioning, collaborating, value driven and managing sustainable and frequent delivery of working software with quality then you have meet the Agile Manifesto. If someone losses site of the value being delivered focused and nit picks the way you are doing something, ignore them, remained focused on your business partner and continue delivering working software.

On the other hand, I don't like it when someone who has not done Agile suggest picking away at the engineering practices. They suggest not to pair, or do we really need to automated the test, or can we not do Test Driven Development to save time. The agile practices have a greater net benefit when practiced as a whole. That is, all the practices have an amplifying effect on one another. Furthermore, the engineering practice make it possible to maintain a sustainable pace of delivery over just practicing the management practices (SCRUM) alone. While, in the short term there may appear to be a time savings if you skip a practice or two, the increase in defects and the impact to later productivity will cost you more than if you did the practices to being with.

So agile, practiced one way is not the solution for all environments. Nor is picking away at agile at the edges a way to save money or time. Allow agile to adapt but don't take the discipline out of the engineering practices.

Cam Wolff
+1  A: 

I don't like that teams with no methodology at all, always call it "agile" and know very little about what it really is supposed to be.

Richard Hein
+3  A: 

The insistence of some people that certain practices must be followed to a T (even when it makes little or no sense to do so). Saying you are "agile" means nothing. Rigidly following a process and sticking to scores of rules is pointless

If it helps, do it. If it hinders, change it. Don't just do it because you read it in some book or other.

Mark Simpson

Trying to educate the customer/client/business that we need their feedback in order to do our job well. What I mean is that after showing some functionality, there should be some remarks or discussion on if what was done is complete and if not what is missing that would make it better. I understand how from my perspective feedback somewhat fuels what we do and is thus very important but I'm not sure how well those using the system we're building understand that they have a part in this and if that means their remarks and comments come later, that's fine as long as they come rather than trying to interpret silence. If they say nothing, does that mean all is fine? All is crap? We should just do our thing and hope for the best?

The last is what we usually do here but I would like to have a better idea of "how are we doing" from those outside my department to see if other groups like what we are doing or think it is an incredible steaming pile of doggie doo-doo.

JB King

Independently, Jeff Langr and I have developed two cards/articles on objections to agile development based on our shared experiences.

Separately, i found an article from a while back with some of the same observations.


+1  A: 

I find that no matter what methodology you use--waterfall or agile--it all depends on the people you have. If you have sucky people, you'll have a sucky project!

+2  A: 

I don't like the certification rackets and the way agile is being hijacked by project managers as a way to transform themselves into "business consultants".

I hear a lot of rubbish about "agile not being about software", despite the full title of the agile manifesto being: "Manifesto for Agile Software Development" and the first line reading:

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

A lot of these "consultants" don't actually know anything about software. They're just administrators. Agile has always been about developing software.

I don't like the way that it takes months for a competent developer to acquire good agile development skills yet "air programmers"(*) that have no idea how to create useful, working software with their own hands can acquire merit badges with the phrase "certified scrum master" for two days of merely sitting in a class.

These air programmers are often extremely patronising to developers that have spent years learning how to create software products, yet they often have no experience, qualifications or technical understanding. These "air programmers" often have the power to make technical decisions about things they have no hope of understanding... and when you look at things in context it's quite amazing how much confidence they have considering the fantastically superficial grasp they have of the subject.

I also don't like the way that these people assume that technically competent developers know nothing about the business, or the bigger picture. That's just an insulting stereotype. Having a tech job doesn't say anything about what else you might or might not know. Some developers have run businesses and others are qualified accountants. Making developers out to be obsessive nerds is a great way to deflect attention from people that are in a business that they know nothing substantive about...

(*) An "air programmer" is somebody that has never programmed in their life and have no concept of what's really involved. Often they have no interest in technology or understanding of it. They're often in our industry just for the money.

+1 Exactly my feelings
Viktor Sehr