When not to use Agile?


Agile pills do not cure all diseases. These are most effective if applied to the RIGHT projects, teams, and organizations. Review the following Agile Helpline Rule Of Thumb. Enjoy reading and don't forget to share your feedback. Is Agile meant for you?


RULE OF THUMB: AGILE is NOT appropriate for a(an):
  • PROJECT without significant urgency, complexity and novelty (uniqueness).
  • TEAM, which is not self-organizing and does not believe in inspecting and adapting.
  • ORGANIZATION, which improperly invest in good engineering practices (e.g. TDD, CI etc.) and cross-functional teams.

Here is a visual aid for your slide deck. Don't remove "Agile Helpline" from it though.


Here is non-software specific view of agility:


Reference:
  • Agile Rules of Thumb [rules
  • Deciding What Kind of Projects are Most Suited for Agile [article
  • Self-Organization: The secret sauce for improving your team [video]

2 comments:

  1. My 2 cents in the form of a simple/short filter:
    One line version:
    If you can gain no significant value from early feedback in your project, do not use Agile methods

    Three "line" version:
    If your'e customer knows exactly what they want, and you understand what they want
    _and_
    If you know exactly how to build what the customer asked of you
    _and_
    If you have no changes in priorities and contents during the lifecycle of the project
    _then_
    Agile principles and practices will not help you. They were built with the reverse of the above in mind
    _however_
    keep in mind that in complex environments you will need to complement them with something along the lines of CCPM

    The reverse of the above is, for better or worst, the reality we deal with in most of software development today

    ReplyDelete
  2. Great comment Elad. I completely agree with your one line version. Three line version options some door for perception and pretension e.g. what customer want is influenced by lot of factors. Even if they are certain about what they need then still iterate and ask at the end of every iteration if you really want to implement rest of the backlog as it is. You will be surprised with their answers.

    As a real experience, one of the business unit gave me a list of "must-have" features, which needed over an year to complete. I asked business folks to stack rank all the features so that we can give some options for faster delivery. Based on the stacked rank list, I told them that let's do 2 quarterly release for top features in the "must-have" list. Business approved the plan as they had nothing to loose in this approach. We almost completed our first quarterly release and I asked business again that can we implement remaining top "must-have" features we planned for the second release? Not surprisingly, answer was"no". Business had a changed list of features they needed for the 2nd release. They hardly wanted any "must-have" feature they requested earlier for the second release. I asked why are changing scope and answer was.... our business priorities changed.

    Isn't it interesting that list of "must-have" features changed just in 3 months. I am glad process allowed business to adjust with given realities, instead of bounding them under a long term contract called "Signed-off Requirement Document".

    ReplyDelete