Common Agile Objections
Common Agile Objections
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
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”
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.”
“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.
Published at DZone with permission of Allan Kelly , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.