Agile Gone Bad?

Agile ain’t agile no more when adopted as the official enterprise software development process. The problem with agile is “agile != flexible”.

Agile was born in the world of contractors who have to show something for the money at every status meeting. For a while clients let themselves fooled with use cases written on many hundreds of pages but this doesn’t work no more. They smartened up and demanded to see something working, for a change. Agile came in handy because it allows to show a prototype early on. As long as you keep adding features to it and you are able to demo them there is a good chance your contract will be extended.

While in theory the Agile methodologies tell you to be flexible, the cruel reality is that most people that apply them don’t think a lot before taking the manual and enforcing every bullet point with a thick stick.

via Software development dogmata – good practices gone bad | Little Tutorials.

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.
Share This!Share on Google+Share on FacebookTweet about this on TwitterShare on RedditShare on LinkedIn

2 thoughts on “Agile Gone Bad?

  1. Flexibillity hurts, flex. pains, flex. is out of the comfort zone. Most enterprises sit in their comfortzone and expect to stay there and get flexible through agile methods. That is a wrong assumption.

    Agile, in all of the processes i learned and used (XP, Scrum mostly) means walking that extra mile, carrying that extra weight, doing what is required and that comes for a price.
    Most people do NOT realize that flexibillity is not the no.1 factor they need or the y have a wrong concept about it at all. Some sentences i have heard over the years:

    * All is prio number one
    * We cnat stick a business value to it
    * There is a high prio AND there are vertain things that are important, i have learned that on project management seminars
    * High risk? Do it anyway
    * There is 3 Sources fo priority you have to follow

    Yes, technical teams make mistakes, when it comes to offer the right instruments for leaders here. But as we say in german “The fish stinks from the the head”, not every company has leaders that adhere to the decisions made before. Luck you are when youre in my position and all of the comapny is still in a mode where everybody KNOWS that IT still means: Trial and Error, learning and in our case: Inspect and Adapt.

  2. Time Ago I heard someone say:
    “If you are doing Agile by the book, after two months then you aren’t doing Agile.” (Arlo Belshee)

    This was an interesting point. What this person explained is that during their Scrum meetings, or Release retrospective, or whatever… People should come up with the new procedures or methods, to improve their practice.

    This isn’t different from Deming’s Quality Circles were the workers and supervisors work to find systemic solutions to problems.

    Any self respecting continuous improvement system such as Lean, Six Sigma or Theory of Constrants Have a mechanism to improve the system itself (recursion).

    Agile has it too (through retrospectives) but maybe the Agile evangelist haven’t made it clear that practitioners must keep improving the Agile process/system itself not just the code.

Leave a Reply

Your email address will not be published. Required fields are marked *