Let’s Get Back to the Manifesto
A lot of companies and software groups these days are “Agile” or are going agile. Many people will espouse the downfall of the waterfall method and all that was evil within it. A lot of them will not even understand why it’s wrong.
I often wonder how many people doing Agile actually understand the principles. I also often wonder if I understand its principles. I’ve heard statements from teams akin to “That’s not agile” or “We’re doing real agile development.” And, to be honest, I’ve allowed myself to get sucked into more of these waste-of-time arguments than I care to admit. The interesting point to me, is how little process was dictated during the creation of the Agile Manifesto:
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.
Tell me, where in this manifesto (or in the related 12 Principles) do you find how long your sprint should be? Or how to run a stand-up? Or how to pick the date for a release? The answer, by-and-large is “It’s not in there.” (I’ll give the exception to the fact that they encourage “shorter” sprints.)
Two things are amazing to me about the manifesto:
First, it was created and signed by developers (at the risk of going all Ballmer on you – developers! developers! developers!). That’s right, developers. Not managers who were unhappy with their team’s performance. Not QA professionals who wanted the programmers to be more responsible. Not some consulting firm that wanted to blaze new trails in project management consulting, and not project managers. In fact, some of the names on the list are living legends in development circles (I actually assume that all of the names are legends, but that I’m just too myopic to recognize them.)
What’s interesting to me about this is, the idea was started by developers who wanted a better way of doing software development. They weren’t asking for more overhead on their project. But at the same time, they weren’t asking for anarchy either. What they wanted was to not so much be ruled by some strict process, but instead allowed to work in a way that matches their teams strengths (e.g. “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”)
This flows into my second amazing observation about this manifesto, namely, for something that was to encourage individuals to seek out ways to make the software work (“Working software is the primary measure of progress”) an entire industry has started up. There are agile templates, agile bug tracking software, agile conferences, agile books, agile certifications etc etc.
For something that was supposed to value people over process, there are about a million ways for you to be doing agile “wrong.” How is that even possible? The idea strikes me about as absurd as running a conference on how to be a proper anarchist. For $99.95 I’ll certify that you are an anarchist, provided you’re able to pass my test at the end of my 3 day conference (room and board not included.)
So the next time you’re sitting in your sprint planning session, or you’re having a conversation with a coworker about how some group at your company isn’t doing “real agile,” head on over to the Agile Manifesto, and check out how many of the 12 guiding principles you can honestly say your company is adhering to. My guess is the average score would be about 3/12 or 4/12.