Agile is not a set of techniques

Posted on October 11th, 2006 in Agile, Methodology by siddharta || 5 Comments

A few weeks ago, Steve Yegge had a post on Good Agile, Bad Agile which caused a huge flutter in the blogosphere. The reactions on the Extreme Programming list went from “this is the usual ‘I don’t understand agile, so I’ll bash it’ crap” to “listen to your enemies. They’ll tell you things about yourself that your friends never will.” with a whole bunch in between. The post even turned up on Slashdot and Joel. Wow. Steve then posted a followup titled Egomania itself.

I personally think that both the articles have some good parts and some bad parts. He correctly points out that agilists can sometimes be loud and dogmatic.

Having said that, I really do think that agile principles from the Agile Manifesto have a lot of value. Most of the problems associated with agile come from the 5 pitfalls list. Just to summarize, here is the list in short:

  1. Unfamiliarity
  2. Top-down thinking
  3. Culture change
  4. Incomplete implementation
  5. Silver bullet syndrome

When something starts to get popular, there are any number of managers who want to implement it to get immediate results. “This book says that if we write requirements on index cards instead of an excel sheet, we will be more successful.” Obviously that is nonsense, but for a number of people, that is the take away message from agile. “Do X and you will be more successful,” where X can be test first, pair programming, daily standups or what have you. You then have the manager forcing the team to have standups everyday, its 45 minutes long (Standups are supposed to be short, not more than 15 mins), and naturally everyone just hates it. The result? The engineers hate it, and the manager is disillusioned.

Don’t obsess over techniques. If pair programming doesn’t work for you, that’s perfectly fine. Don’t do it. Do what works. Maybe you are having a lot of success with daily standups. Continue to do it. A confession: I don’t do pair programming either.

Techniques do not exist in isolation. There are a number of factors that contribute to the success of a technique: the people, the environment, the culture, the management. A technique might work great for Google, but be terrible in your environment. A technique that is terrible for Google might work great for NASA.

So if you are not going to focus on techniques, what do you focus on? I prefer to focus on principles. Being agile is not about writing requirements on index cards or doing test first development. To me, being agile is about valuing people, working collaboratively, improving continuously and delivering consistently.

Now, that is a lot easier said than done. A comment on Steve’s post goes like this (the company mentioned is Google):

I worked on a team (at the same company as you) where we were essentially “forced” to use Scrum. I don’t think a single engineer on our team found it useful, and I personally found it annoying, but we didn’t really have a recourse for evaluation: I gave feedback that I didn’t like it, but I’m not sure that everyone else was comfortable doing the same, and there weren’t any of these wonderful double blind weekly evals. I also think its results were mis-used. The data that was derived from it (how much our team could accomplish in a week) was tainted and it shouldn’t have been turned around and used to make decisions.

If the engineers didn’t find it useful, the practices should have been changed. Continuous improvement of the process by the team is a cornerstone of agile. This is a perfect example of following the techniques and ignoring the principles.

Agile is not a set of techniques. It is the principles that matter more than the techniques. Focus on the principles, and do the techniques that work in your environment.

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

5 Responses to “Agile is not a set of techniques”

  1. Silver Stripe Blog » Blog Archive » Getting into the agile mindset Says:

    […] said before that more than practices or techniques, agile is often about a mindset. It is about understanding the values and principles behind the practices that really enable you to […]

  2. Introduction to Agile: Agile Chennai 2007 Presentation » Blog Archive Says:

    […] This is the intro to agile presentation from Agile Chennai 2007. It was done jointly by Bala and myself, although Bala did most of it. I just spoke for five minutes at the end of slide 83 about how agile is not a set of techniques. […]

  3. Sunny Says:

    It’s much easier to unnarstedd when you put it that way!

  4. kfw studentenkredit login Says:

    IJWTS wow! Why can’t I think of things like that?

  5. itzeho auto versicherung ändern Says:

    Maureen, I trained the butcher at our local Publix grocery store, which is found in the Southeast and Florida. But i tell him to use sirloin tip or lamb if reasonably priced, and i go there in the morning when the store opens. I enjoy these emails and the advice. Please tell your Mom hello for me. Gregory

Leave a Reply