Agile Fail?

Slashdot has had links to When Agile Projects Go Bad at cio.com, and James Shore's post on The Decline and Fall of Agile this past week, and it's raised a couple of interesting points for me--mainly concerning the manner in which it is adopted in a business.

The CIO article opens with a piece describing how most people aquire new skills:

In the first stage, people need to follow a recipe. In the second stage, you say 'That's all very nice, but I need more,' so you go off and collect recipes and ideas and techniques. And in the final stage—if you ever get there—is a level of fluency and intuitiveness where you can't say what you're doing, but you kind of borrow and blend.

Introducing Agile as a methodology tend to lead to people in the beginning conforming to a checklist culture. The article then goes onto describe why this almost always has a negative impact on the process of building software.

Some people just assume that by incorporating the practices defined within a particular Agile methodology that makes their business agile. Anyone who has been within a team where this has happened can quite clearly say this is not the case: Weekly releases? Check. Pair programming? Check. Test driven development? Check. Requirements as stories? Check. How does going through the motions of applying these techniques lead to a better product?

Answer: it doesn't. I'm being quite absolute on this: if you're in a team that claims to be "agile" just because you are using some techniques you read in Extreme Programming Explained then think again.

Agile is a mindset you have to get into. It's about trust and professionalism. It's about seeing a problem as a series of stages, and tackling each one separately. It's about communicating with your team and customers constantly. It's about change.

It's not about processes, and yet the processes have become the poster children for the entire movement. Read the original Manifesto for Agile Software Development. Read the Principles behind the Agile Manifesto. There are no concrete techniques there at all.

These ideas are what Agile is about, but its abstract nature is proving to be its downfall. By being so abstract people bought in to the likes of XP and Scrum, where techniques were laid out. And it's always the techniques that are going to take precedence over ideas.

You can see that members of a team are pair programming. You can monitor the amount of tests that developers are writing. You can see requirements listed in story form. But how do you monitor Agile's ideas?

How do you tell if your team is motivated? How do you tell if you team is self-organised? How do you tell if your team is keeping a constant pace? These things are much harder to keep track of, but they stand at the heart of what pure Agile is about.

And it's this that leads some people to believe that Agile is a failure. In many ways it is, and I won't sit here and defend some implementations of it, but at its heart the set principles are sound.

But it's not for everyone. For Agile to make an impact you need a good team. A trusted team with experience and who aren't too jaded to try new things. A team that communicates, and where mistakes aren't chastised but taken in as just another problem to solve.

Communication and team work are key to making a success with Agile. It takes a good team to pull it off, I admit that. Some teams won't thrive under its ideals, but when you put the right people together it gives them all the help they need.

Just don't get too focused on the techniques you read about.