Subscribe to The Agile CEO via email

Your email:

Charlie Rudd

Charlie Rudd, SolutionsIQ CEO I’m Charlie Rudd, CEO of SolutionsIQ, an Agile company. I’m interested in learning better and better ways to unleash the power of teams by applying Agile management principles and practices throughout the enterprise.

Subscribe to our Newsletter

siq newsletter 180

The Agile CEO: A Blog About Agile Leadership

Current Articles | RSS Feed RSS Feed

Why Agile is Not a Methodology

  
  
  

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:

  1. Under these circumstances, do these activities.
  2. When you get to this point, do this activity.
  3. An activity is defined by executing this task sequence.
  4. The input of this task is “X” and the output of this task is “Y”.
  5. 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.

Why Agile is not a methodologyAgile practices

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

  1. In test-driven development, you always write the unit test first.
  2. 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.
  3. The definition of done is a checklist that the team output must conform to.
  4. 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.

Agile practicesWhat is Agile?

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

  1. When in doubt, defer decisions to the last responsible moment.
  2. Only do what you need to do and no more.
  3. Organize your work to leverage the power of collaborating teams.
  4. Organize projects to get into production as quickly as possible.
  5. Expect and embrace change.
  6. 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.  

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

Comments

Not sure I can agree on it. Agile gives a set of processes which try to give you a Done outcome.  
 
The rule people over processes doesn't mean abandon processes and let's go Rambo. 
 
I wanted to write a longer comment but there is blog post which is better in explaining it: 
 
http://herdingcats.typepad.com/my_weblog/2012/05/planning-plans-and-execution-of-the-plan.html 
Posted @ Tuesday, May 22, 2012 2:44 AM by Geert Theys
Geert, 
 
Thanks for the comment and the reference to the post. I certainly agree with you that the rule of people over processes should not mean “going Rambo.” I also agree that to obtain value from Agile practices you need to follow the procedural constraints. My point is that with Agile the expectation is that the practitioner is always in charge. This means people over process and planning over plans, collaboration over contracts. When things go wrong on the outcome side, the practitioners are accountable for making the necessary changes and reaching new agreements, whether or not they used Agile practices. The blog post references Jeff Sutherland’s story of making critical decisions in the cockpit of a jet fighter. I have heard that story in reference to the practice of deferring decisions (e.g., the decision to eject) to the last responsible moment. This captures my idea that the pilot (not the operations manual) remains in charge and in control.  
Posted @ Tuesday, May 22, 2012 10:02 AM by Charlie
Thank you for this blog post. It cannot be said enough - Agile is a state of mind, and we should all embrace the fact that it is a state of mind.
Posted @ Tuesday, May 22, 2012 11:38 AM by Patrick
Comments have been closed for this article.