Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Common Agile Objections

DZone's Guide to

Common Agile Objections

· Agile Zone
Free Resource

Speed up delivery cycles and improve software quality with TestComplete. Discover the most robust automated testing tool for end-to-end desktop, mobile, and web testing. Try TestComplete Free.

Last time (“Waterfall works when…”) I promised to discuss some of those common objections to “Agile.” (Actually, reading back this this post I’m struck by how like my “12 Myths of Agile Development” which was originally a blog post 2 years ago called “11 Agile Myths of 2 Truths”.)

(Apologies by the way, “Waterfall works when…” was misposted the first time, I’ve just fixed that.)

“Waterfall is most appropriate because our requirements are known and stable”

So what? Agile works brilliantly with stable requirements, it also works pretty well with changing requirements.

“Scope cannot be flexed”

See above.

If scope can’t be flexed than so be it, you will do it all. Scope is flexed all the time on traditional projects. No matter how much traditional projects say “scope is fixed” once they get near the end and no more money, people or time is available scope always flexes.

“We work on multiple projects at the same time”

And? Its all work to do. If you want a full discussion see Xanpan.

I think some of the Scrum texts talk about “dedicated” or “ring fenced” teams. I’ve never yet met a team that doesn’t have some baggage. As John Lennon might have said: “None project work is what happens to us while we are making plans."

“The thing that is being built cannot be decomposed into smaller pieces”

Well have you tried to decompose it? - many teams jump to this assumption without trying to decompose it. Decomposing work is a skill, just because you tried once and it didn’t magically happen doesn’t mean it can’t be decomposed.

If you couldn’t did you ask for help? Did you ask someone (like myself!) to help? - breaking things down isn’t always easy, it might help to have some help.

What if you can’t break it down but your competitor does?

I believe almost everything can be broken down if you approach it right. And if you can’t break it down then perhaps it isn’t something that can be implemented in software.

“Agile works on greenfield projects but we have a legacy system.”

and

“Agile works on legacy systems but we are building something new.”

(Now I really am repeating myself - see “11 Agile Myths of 2 Truths”)

They both can’t be right? I’ve seen Agile work on both new and legacy development and I’ve heard both sides say “It won’t work because…”.

The grass is always greener on the other side.

“Our project finance model does not allow Agile”

So what? There is plenty you can do which has not finance implications.

Stop pointing at other people who stop you, do what you can and take one problem at a time.

Release quality software faster with TestComplete. Discover how to decrease testing times and expand test coverage with the most robust automated UI testing tool. Try free for 30 days.

Topics:

Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}