What is the Agile Methodology?


“What is the Agile Methodology?” is a questions I used to get asked all the time at my old job.  I used to get annoyed and say, “There is no such thing as the agile methodology, its a framework”  Mostly because the word methodology was so very overloaded in that particular environment.  I didn’t want the political implications of that word to end up wrapped up in what I was trying to do (Pure Scrum).

Wikipedia says methodology is “the systematic, theoretical analysis of the methods applied to a field of study, or the theoretical analysis of the body of methods and principles associated with a branch of knowledge” <-if the shoe fits!

I think there the application of the word methodology starts to break down, particularly with respect to Scrum, is that the analysis and systematic study are not encoded in the framework itself.  Just because a person has applied the framework doesn’t mean they are applying the systematic empirical study of the framework, and that’s where some adoptions go off the rails.

So, in terms of Agile, there is no “methodology”

There are a suite of methods and practices borrowed from other production disciplines that all fall under the umbrella of Agile.  You can apply these methods not understanding how they work, and the empiricism is assumed by the application of the methods, but it is completely possible to apply them with no empiricism then complain they don’t work.

One advantage I see over traditional (predictive) methods is that predictive methods assume you already know everything there is to know about the work, thus you plan everything up front

In large traditional software projects, there may be a post mortem, but the lessons tend to get lost in the shuffle as the project staff quickly move to wrap up one project as they prepare for the next, as opposed to the lessons getting encoded into the execution along the way.

Another advantage is that agile methods don’t assume every team is the same

This is another mistake I see being made by predictive methods in that they assume that a team is a team is a team and if it took one team 10 days to do something, it will take another team 10 days to do the same thing.  People are not resources, they are people.  Software is not assembly line work, its creative work, and the ways to get better performance out of a team is to treat them like a team.

As more companies look to adopt agile methods, there will continue to be confusion about “The Agile Methodology”.  Hopefully we can get more competent coaches into the market to help people transform organizations the right way.

There was an issue loading your timed LeadBox™. Please check plugin settings.

Leave a Reply