BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Research Biggest Impediments for Effective Agile Adoption?

Biggest Impediments for Effective Agile Adoption?

Bookmarks

InfoQ's research widget has been deprecated and is no longer available.

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.

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

Community comments

  • This vote is flawed

    by Adam Nemeth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • CMMi best practises

    by Ian Fleming ,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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".

  • Circular logic

    by Ciarán ÓNéill,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Saying that "Most agile adoptions fail because the organisational culture is not aligned with agile values" is like saying "most obese people find it difficult to lose weight because they are fat".

  • Circular logic

    by Ciarán ÓNéill,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Saying that "Most agile adoptions fail because the organisational culture is not aligned with agile values" is like saying "most obese people find it difficult to lose weight because they are fat".

  • Circular logic

    by Ciarán ÓNéill,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Saying that "Most agile adoptions fail because the organisational culture is not aligned with agile values" is like saying "most obese people find it difficult to lose weight because they are fat".

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

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

BT