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:
My 2 cents in the form of a simple/short filter:
ReplyDeleteOne 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
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.
ReplyDeleteAs 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".