We can't do agile because...

Question

What's the most often used reason for not being able to do agile, and is there an argument against it?

Answer 1

The most common argument I've heard is that it's the first thing to go out the window once time and cost pressures arise.

Answer 2

Sometimes the environment you're in precludes you from doing agile development. E.g. you're only able to meet with the client at rare intervals, or major portions for each release are on different teams and the overhead of putting together an interim build is very high.

I for one love agile style development, but in the past those are some reasons where it's not been possible to have nearly as much iteration to it.

Answer 3

Because it involves learning a billion new practices.

Yes there are many facets to what is generally called "Agile Development" but your company can still get plenty of benefit just by implementing pieces of it. Just don't only implement the easy ones for laziness sake, implement the ones that help in the areas your company is having problems with.

Answer 4

I think that even talking about Agile in most organizations is putting the cart before the horse. The problem with most organizations is that quality is the last thing that they care about. It's always schedule driven development, and the developers never have ample access to domain experts and stakeholders.

If these are the problems in your organization, then implementing Agile, or any other methodology, is like, for lack of better terms, putting lipstick on a Pig.

Answer 5

It seems that "changing everything all at once" is a common reason for agile failure. As the prags have talked about several time, baby steps are more likely to succeed.

For instance, if your shop is not doing version control, then add version control to the mix and work with that for a while. Once people are comfortable with it, add testing, then nightly builds, then ... you get the point. One step at a time.

Answer 6

Also remember that if you want to implement agile methods, it should be implemented in a controlled fashion. I mean, not everything that sounds "agile" is part of Agile methodology. If you go to an organization and mention the word "agile", then if not the developers then at least the management might get the idea that "alright, now we don't have to pay attention to documentation so much." You should make clear that Agile is still a controlled way of developing.

Agile method uses lots of face to face communication though. (See Agile-software-development) But you should still make sure that the documentation stays up to date. Its important to have good documentation, because you might add other iterations later instead of programming something ready in one go with more or less good specification.

Answer 7

I have found that often "management" don't understand it, and are addicted to a waterfall style of thinking.

That said you can use agile development techniques to increase the quality of what you are delivering (TDD, continuous integration, occasional pair programming etc etc).

You can then be faced with "management" contributing to such discussions with:

"why are there 2 people sat at one computer, it must be inefficient"

"agile practices were responsible for the dotcom bubble bursting"

"we must gather detailed requirements up front before we start developing"

"i need a ticklist to ensure something has been done properly"

Answer 8

In a consulting environment clients often demand a predictive approach to projects during the proposal, pricing and early stages. Thier desire to be predictive doesn't align with an adaptive methodology such as Agile.

This means you need to transition away from a pure agile project to some middle ground, keeping the things you can.

Answer 9

We were told that Agile isn't a process and that it is essentially "Cowboy Coding."

No amount of evidence could convince management otherwise.

Answer 10

Agile has been given a bad rap by people doing it wrong. Using the term "agile" to mean, I'm just going to start coding with no discipline or direction. These people should have been beat nearly to death with their bad code. When done correctly, an agile methodology is very structured and disciplined, but also flexible. The most important stuff gets in the code based first. I guess it's important when trying to sell something like SCRUM or XP to management, is to try and convey this fact. I was very successful in an corporate environment that used a failed waterfall method, which caused the success rate of projects to be around 30%. I created what I called an "SDLC" wrapper, and used resources like interns to do the documentation, forms and "TPS" reports necessary, to give the illusion that we were following the failed process, while my programmers, utilized a scrum based approach, allowing 100% success, which was unheard of where I was working.

Answer 11

Senior Managers are people who are usually scared of new ideas.

make "Agile Methodology" more that just an idea or a buzz word.

There's Nothing like good education.

Get a good agile workshop, have senior management as well as dev and QA people participate.

When Senior Managers sit in a good workshop, they get reassured about the new ideas, they can hear about success stories, and they might actually wipe the dust off and recall the excitment they once felt when they were developers.

Answer 12

Something that hasn't been mentioned yet, a very common reason is Security. (yes, Security with a Capital S).
While there are legitimate concerns regarding implementing secure, agile software (yes, yes, I know), and it is far from trivial to implement, it IS possible to do so.

We are actually currently working on this topic ("we" being HPC/security consultants), and it is possible to do nicely. We've developed a modified SDLC (the S in this case is security) that integrates with, and complements, the Agile process and techniques.
We've had some experience in this area - though not a lot, because orgs that HAVE gone *A*gile are usually scared of putting anything else into their process.

The places we have done so, though, have been wildly successful - so in answer the OP's question, it is possible to overcome this hurdle too, using a properly designed Security Development Lifecycle that takes the Agile family into account.
(Let me know if you want more details on this.)

---

I actually just gave a talk on this subject, at the local OWASP branch, with (what I believe) are some interesting insights, both on the reasons for the (apparent) conflict, and on the possible resolution and improvement towards secure agile.
When the preso gets online, I'll post a link...

Answer 13

If your company often does contracts, then the client usually wants some kind of specification tied to the contract, agreed at the start with an agreed price.

This makes it difficult to do agile because the client often doesn't want to hear about dropping features because of how hard it turned out to be to implement the previous feature. Not that this will stop them from asking for additional features as time goes by.

To get past this you need to develop a good relationship with that client. One way through this would be to have a contract at the start with a list of features, but to have some clause saying that some features listed may be swapped for new features subject to sign off by both the contractor and the client. Then if they decide they need extra features part way through, you can talk about which of the original features will be dropped. If you do take this approach it is important to talk this process through with the client before signing the contract and to manage client expectations throughout the project.

A different problem is that the client is busy and doesn't want to spend time giving feedback during development. This is hard to deal with, but one approach that can limit the damage if you really can't persuade your client to give feedback is to have someone in your company be a client proxy. They should not be working on the project in any other capacity, and should attend meetings with the client so as to get a good as understanding as possible of the client's requirements. Then the client proxy can attend internal meetings and give you feedback. It is surprising how useful it is to just get feedback from someone who is not up to their neck in the project. But it is still far from ideal.

Answer 14

See the sections titled "it won't work here" and "they won't let us"

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

Answer 15

Real "reasons" (excuses really) why "they" can't adopt agile that I've heard:

"test-driven development doesn't find all the bugs so we shouldn't bother trying it"

When you start doing TDD you gradually learn to get better at it. Perfectionism just stops you from making any progress. Isn't it better to make a substantial amount of progress than none?

"I have to allocate budgets up front for the year so I need an up-front plan."

You can still allocate budgets for developers and time because that doesn't require an absolutely detailed plan of exactly how each thing is going to be built or even exactly when.

"I have to give the business a detailed schedule of deliveables for the whole year in advance"

This is much less of a problem if you can describe outcomes e.g. Problems the team will solve and things the users will be able to do rather than describing exactly your best guess of how to implement it.

"We don't need to pair program because that's just for teaching juniors..."

Funny how some of the most experienced people in our industry still pair - with other experienced people. They're helping each other design and think through what they're doing rather than just coding madly in silence.

Answer 16

One major problem we faced in implementing Agile development at my last job was in how the stakeholders interpreted what it meant. We held a couple seminars with them explaining how this process would allow the developers to make more efficient use of their time. They took that to mean "stuff will be completed sooner." Naturally, quality suffered as we tried to meet their new deadlines and they blamed Agile.

So I guess the point here is that the stakeholders need to be reminded that good software takes time. Agile can speed some things up (such as determining that a project isn't worth the investment before too much investment is made), but the overall development process takes a certain amount of time no matter how you arrange the steps to completion.

Answer 17

Beware anyone trying to sell you a silver bullet. Agile is no quick fix and it's not even the best way to do things, depending on how your team and project are set up, especially if you try to implement every part of it. I doubt many projects are 100% strict and those that are would worry me for taking a system out of a book and not modifying it to their needs.