Why are you discussing or proposing Agile?

Joshua Milane started an interesting discussion on LinkedIn “When introducing a Methodology, did you start with the Manifesto, or with the “(Insert Method Name) How-To Guide”?

Kevin Schlabach (http://agile-commentary.blogspot.com/
http://twitter.com/kschlab) touched the core of the question with this response…

“Remember that Agile is an umbrella covering several groups (Scrum, XP, Crystal, DSDM, etc) that are collections of best practices. Agile is more of a philosophy and a culture. The best practices are sometimes a methodology (like Scrum). This makes your question a very loaded one based on your choice of words.

“If explaining what Agile is, I start with the manifesto. People need to understand that there is no end to improvement and that XP, Scrum, et. al. is a starting point, not an ending point. (Mike Cohn had a good post about this recently.)

“If solving a real current problem (the better approach), I explain the pattern/practice that will help solve the problem. Over time, this will build up to a curiosity about the larger Agile umbrella.”

The key points to consider here are…

1. There is a fundamental difference between a philosophical manifesto like Agile and a methodology like Scrum.

2. There is a need to understand whether your communications about Agile (or applicable methodologies) are in response to curiosity about Agile or the need to address a particular issue.

The latter is a very important point. Why are you discussing or proposing Agile? Over the years all sorts of methodologies and philosophies have been thrown at problems without considering their applicability. There has to be a stage where the root causes of a problem are investigated before throwing the current fad process at it. If there is a problem that repeats with many different projects, you can be sure that the current processes haven’t been reviewed. They are being applied in a cookie-cutter fashion that isn’t working. Throwing new processes at the problem is simply choosing a different cookie-cutter.

Without analysing the root cause, the problem could simply emerge in a different form in the new process. If the problem does go away, there is nothing to prove that it was the new process that fixed it and the problem could be back to plague subsequent projects.

So, be sure you understand the details of the problem you are trying to fix before jumping to Agile.


This entry was posted in GonzoPM and tagged , , , , . Bookmark the permalink.

Leave a Reply

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