BT

Biggest Impediments for Effective Agile Adoption?

by Shane Hastie on Sep 18, 2012 |

This InfoQ Research item, is designed to help our readers understand the impediments and blockers that could be impacting on the take up of agile methods in organizations. By understanding the impediments that are being experienced, people implementing an agile transition in other organizations could plan how to avoid them.

 

 

 

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

This vote is flawed by Adam Nemeth

This vote handles Agile as the Holy Grail and it doesn't even provide the remote possibility that there are places where Agile shouldn't be adopted.

We do know that Agile practices don't fit everywhere.

We do know, for example, that research projects benefit from documentations more than from code (if you don't believe this, try to read the sourcecode of a research project, and decide if you opt for that, or a clean document which summarizes findings so that you could implement it production-ready).

We do know that sometimes adhering to the rules is more important than negotiation (try to negotiate tax laws instead of strictly adhering to them while building an accounting system)

We do know that some projects can't be handled in short iterations well (that's why more and more maintenance projects employ Lean instead of Scrum)

We do know that slow feedback is sometimes imminent (eg. try to build a Mars Rover) and it's more efficient to design for that than to try to change the process (building a series of test mars rovers to see if they fit is less economical than making it right at once, using software models and calculations)

There are a lot of places, circumstances, when parts of Agile, or Agile as a whole just doesn't fit. Not just culture-wise, but really, it wouldn't benefit the project in question.

Sometimes Agile adoption fails simply because Agile is not the right answer for the problem.

And this is really good this way. Otherwise, we end up at the same path when people tried to do full-scale RUP (which it was never intended to do), or strict waterfall with Gantt-charts.

Apply Agile where it fits, and accept that no size fits all.

Re: This vote is flawed by Fredrik Vestin

Why would you take this survey if you already decided that Agile is not for you or your organization? It would like asking a vegetarian if steak taste better than chicken.

Missing option by James Nail

-- IT management is structured around single-function teams, preventing cross-functional and/or self-organizing teams

CMMi best practises by Ian Fleming

It is interesting whenever I suggest to an organization that they should adopt the Software Engineering Institute's SEI CMMi model for Software Process Improvement. The typical answer I get is that 'we don't do waterfall, we are more Agile". CMMi does not specify the process delivery model, but does outline process areas that when implemented will measure the value of any software delivery process (including Agile).

What I am driving at is that any process is not self validating in that external measures, as to the value of the given process, need to be established. In this way the whole Agile process itself can be subjected to process improvement using objective measures as the value criteria, rather than come at it from generalized perceived issues. To paraphrase Deming, "In GOD we trust, others must bring data".

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss
General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT