Friday, 21 January 2011

What's wrong with the Agile Manifesto?

I've never liked the Agile Manifesto. I'm not blaming the authors because I know it must have been a nightmare trying to come to a consensus, and the manifesto has served a useful purpose bringing like-minded people together under a single brand. It is slightly ironic that the wording hasn't changed in 10 years, but there you go. I'm not brave enough to propose an alternative yet. In this article, I'm just going to explain where I think the logic is faulty.

Here is the wording of the manifesto:

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

It doesn't distinguish agile from "slapdash"

The aim of the manifesto seems to be to try and distinguish agile from waterfall. Unfortunately, agile's worst enemy isn't waterfall but the "we don't write documentation, so we're agile" brigade. And the manifesto doesn't defend agile very well against this threat. Perhaps there's something in the twelve principles but who on earth reads them? Certainly not the slapdash developers claiming to be agile.

It mixes up goals and solutions

"We value working software over comprehensive documentation". OK, but surely whatever software development method you select, working software is the ultimate goal, isn't it? Some people believe that by writing comprehensive documentation you are more likely to produce working software. That's part of their solution. But you can't go round comparing goals with solutions. It's nonsensical. Perhaps what the manifesto authors wanted to convey was that "the code is the documentation", or something along those lines, but couldn't agree to write it, so plumped for the goal as their solution. That's cheating!

The dilemmas are easy to solve

The manifesto poses dilemmas and then tries to position agile at a certain point in each trade-off continuum. But why are we compromising? If both sides have value (as the manifesto plainly says), why don't we find solutions that resolve the conflicts? Let's take each one in turn:

I don't know whether the value of documentation is to do with maintainability, improving clarity or good governance. The point I'm trying to make is that there does not have to be any compromise between those needs and agile methods.

So what is agile then?

I'm not sure. Please can you give me feedback on this post and your ideas. Leave a comment, or blog about it, or tweet me (@davidp99). Thanks.

5 comments:

Steve Freeman said...

Of course, you're right.

As Keith Braithwaite points out, manifestos are relevant to the time they're written. Ten years ago, not using waterfall to commission a system was nearly inconceivable. Nowadays, there's still too much contract-driven insanity, but more organisations are prepared to consider incremental approaches.

So, perhaps we should refer to this as the "anti-waterfall manifesto", and view it as a moment in time.

David Peterson said...

It was written ten years ago in a different world, I understand. It's amusing that it hasn't embraced change, but that would be fine too, if I wasn't still seeing it quoted in presentations as "the definition of agile". That's what I find frustrating.

David Kramer said...

Coupla things. First remember that this is sloganism made to attract people with buzzwords, not instructions for practitioners.

You say "why compromise", but all business endeavors are a compromise. We don't have an infinite amount of time or monkeys.

Lastly, "Working software over comprehensive documentation" has been misunderstood, if not purposefully misued. Just like the paperless office really meant the paperWORKless office, this phrase really means don't wait to start coding until you've written a lot of documentation.

So I don't think the manifesto is outdated so much as not needed very much anymore. Everyone's heard of agile, and anyone whose going to be swayed at this point will require details, if not hard numbers.

David Peterson said...

To have an effective software development approach we need things that I mentioned like:

- Strong communication
- Repeatability
- Fast delivery
- Sustainability
- Good governance

We need high levels in all of them. Our approach will not be truly effective if any of them is inadequate.

Compromising is when we don't achieve all the needs to a high enough level.

The manifesto seems to be shouting "compromise!" by emphasising some needs and downplaying others. This is what doesn't make sense to me.

It should instead have explained that agile methods ALLOW you to achieve ALL the needs while other methods (like waterfall, slapdash etc.) force you to compromise.

Ralph Johnson said...

I think that for agile methods, working software is not only the goal but also a solution technique. The main measure of progress is getting more tests to pass, getting more features working. Software is the center of attention.

Now, software can be the center of attention on non-agile projects, but there are some software projects where it isn't the center of attention.