Why I Don’t Care About Agile, Lean, Kanban, Scrum, and XP

Lately there has been quite a donnybrook in the Agile community. Is it time to leave Agile behind?

As it turns out, the suits have taken over, taking all that great Agile goodness and turning it into just more command and control, top-down, recipe-book dogmatic nonsense.

So some folks say we should just “return to REAL Agile”. Some folks say the brand Agile is dead: it has been killed by entities intent on adopt, extend, extinguish. Some folks say that Agile was never any good to start with — either it was too wishy-washy and meaningless, unlike Scrum, or that it was too emotional and not logical enough, unlike DAD (or many others).

As for me? I just like collecting shiny objects.

Agile is a brand. It’s a brand without an owner. That means that each of us has to come up with some kind of working definition for what the brand stands for. For me, that brand represents something like “best practices in iterative and incremental development”. If you’ve got one of those, you can publish it under Agile. Works for me.

Of course, people go off the deep end just on that formulation. What do we mean by “best practices”. Isn’t that prescriptive? Are we saying that we know the perfect answer to how teams should act?


I’ve been around this shrubbery many times, and I think it comes down to what you want to do in life.

I’m in this to help developers. I really don’t care what you call it, or how it makes me feel. I don’t even care if it all fits together in some master plan, or whether it has a class or not. If it helps developers, I want to do it.

Some folks are in this to change the world. To them, Agile is a movement. It exists to show what is wrong and what needs to be fixed.

Some folks are in this for a theory of life, the universe, and everything. They want a philosophical grounding that they can use for their development, their team — even the organization.

I believe these last two groups are expecting a bit much. Sadly, though, it’s these powerful emotional constructs that drive adoption of things. So they’re always going to be with us.

I also believe that Nietzsche was right: any sort of structured system of belief is going to be self-contradictory. In other words, no matter what you do, once you make a system out of it, it’s broken. And we technologists love to make systems out of things. Even things that are supposedly non-prescriptive. After watching this industry for decades, I believe this is unavoidable.

All of this has led me to believe that fighting over the term “Agile” is a fool’s game. If you only care about what works, it doesn’t matter what folks call it, and no matter what comes along next, the community is just going to do to it what it did to Agile. If you care so much about terms, then get your head out of your ass and start focusing on what’s important. We have work to do. Give up on allying yourself to a certain brand or term — or proclaiming that you’re opposed to a certain brand or term — and just collect things that make developers’ lives better. Then we can share.

Follow the author on Twitter

March 11, 2014

2 responses to Why I Don’t Care About Agile, Lean, Kanban, Scrum, and XP

  1. Project managers prefer Scrum better than Kanban. It is more oriented toward systems while Scrum has a close affinity with project managers and stakeholders due to their presentation of processes and events. Both their workflows are alike, with the only exception of Scrum having their deadlines better demarcated.

  2. Ron Harding said:

    I echo here that in job requirements i see Agile, Hadoop, and scrum master. Instead, i use the keyword K.I.S.S. keep it simple stupid. Do this where you can. because even the simplest problem that you run into can have complexities at its heart that you could not anticipate.

    So stay away from these fancy schmancy terms and focus on solving the problems. Tools are fine, they help you do the job, but at the base of how you do it is orders of magnitude more important than these fancy regurgitated terms.

    With that being said, i have applied the Agile ‘practice’ to solving problems by
    * interviewing target user of my application and come up with tools so user can run their test cases
    * go back to user again a week/2 weeks later, white board problem set to satisfy new test cases and come up with tools again.
    * keep going proceeding on this path.

    So I have no problem with that, I simply don’t use those terms because that takes away from solving the problem and ends up making things more complex.

Leave a Reply

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

* Copy this password:

* Type or paste password here: