What don't you like in Agile development?

Question

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

Answer 1

I hate the expectation that it will solve all problems.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

Pair programming and standup meetings.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

I think agile becomes Fragile in the wrong hands!

Answer 16

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

Answer 17

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.

Answer 18

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

Answer 19

1. I don't like the misconception that it's a "methodology". Agile is really, to my mind, a philosophy (http://www.agilemanifesto.org) 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.

Answer 20

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.

Answer 21

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

Answer 22

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.

Answer 23

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.

Answer 24

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!

Answer 25

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.

Answer 26

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.

Answer 27

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

Answer 28

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

Answer 29

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.

Answer 30

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.

Answer 31

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.

Answer 32

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.

Answer 33

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

http://agileinaflash.blogspot.com/2010/03/personal-objections-to-agile-process.html

http://agileinaflash.blogspot.com/2010/02/organizational-objections-to-agile.html

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

http://www.agileadvice.com/archives/2006/09/agile_challenge.html

Enjoy.

Answer 34

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!

Answer 35

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.