If Agile isn’t a methodology, what is it?

What is a methodology?

A methodology is a process taxonomy designed to govern a work domain (e.g. software development). Each process is defined in terms of a set of prescriptive formulas or rules. Rules generally take on forms similar to the following:

Under these circumstances, do these activities. When you get to this point, do this activity. An activity is defined by executing this task sequence. The input of this task is “X” and the output of this task is “Y”. And so forth…

At the highest level, a methodology is a structured set of processes that otherwise is light in content. The meat of the matter is generally in the rule and task descriptions. When you adopt a methodology, you subscribe to the rules. The good news is that by adhering to these prescriptive activities, you may increase the likelihood of successful outcomes. It’s also true that if you follow the rules and don’t have a successful outcome, you can blame the rules and claim it’s not your fault. This is because the methodology is in charge, not the practitioner. The practitioner only “follows orders”. Whether the ability to escape accountability when things go belly-up is good or bad news depends upon on your point of view. In short, methodologies are rules-driven.

Agile practices

Like the leaf nodes of a methodology, Agile practices also comprise prescriptive rules and task descriptions. For example:

In test-driven development, you always write the unit test first. The Standup in Scrum is done daily, and limited to describing what you did yesterday, what you will do today, and any impediments that are blocking your activity. The definition of done is a checklist that the team output must conform to. And so forth…

However Agile is not a methodology because, even though you could organize Agile practices into a taxonomy, that is not what Agile does. Consequently that is not what Agile is.

What is Agile?

In Agile the practices don’t roll up under a methodology, they point to principles. Here are examples:

When in doubt, defer decisions to the last responsible moment. Only do what you need to do and no more. Organize your work to leverage the power of collaborating teams. Organize projects to get into production as quickly as possible. Expect and embrace change. Get started as quickly as possible and learn as you go.

In a methodology, the practices are part of the methodology by definition. However, in Agile the practices are only part of Agile when and if they embody Agile principles. If you apply what is commonly considered an agile practice but without applying the principles, it’s not Agile. On the other hand, if you apply any practice (even if it’s not recognized as an “agile” practice) while applying the principles, then it’s Agile.

The good news is that when you apply Agile practices you frequently increase the likelihood of your success. However, unlike a methodology, if you apply an Agile practice and fail you don’t get to blame the process — you have to blame yourself. With Agile, the practitioner is in charge not the practice. It’s the practitioner’s responsibility to make sure that the practices comport with the principles. This is not always easy. Sometimes it requires interpretation, arriving at agreement, or making a tradeoff decision or a judgment. Agile is designed to make it impossible to escape responsibility and accountability. Whether this is good news or bad news depends upon your point of view. In short, Agile is principle-driven and not rules-driven. And what does that make Agile?

Agile is a philosophy.



This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.