Biggest Impediments for Effective Agile Adoption?
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.
This vote is flawed
by
Adam Nemeth
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
Missing option
by
James Nail
CMMi best practises
by
Ian Fleming
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".





Hello stranger!
You need to Register an InfoQ account 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