Reviewing the Agile Manifesto
I love the Agile Manifesto. Go ahead and visit agilemanifesto.org, bask in its turn-of-the-millenium aesthetic, and read it again. (If you are involved in software development, you have actually read it before since it only takes about 30 seconds, right?)
Back? Good. I like visiting it periodically just to be reminded of its principles.
Few things have resonated with me quite as strongly as the manifesto, and clearly it had a significant impact on the industry. The problem is, few companies actually prioritize the principles of the Agile Manifesto, despite claiming to be agile. In fact, a company claiming “We are agile!” can be a bit of a red flag at this point.
Just to have it as a reference throughout this post, here is the 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.
“Agile” has been co-opted by so many different interests that it is virtually useless as a label. If you were visiting from some corner of the business world that somehow hadn’t heard of “Agile” and listened to people talking about it, you might think it was a) some sort of tech religion b) a detailed methodology, or c) a system where you move pieces of paper around on some sort of a two-dimensional todo list.
The divergence starts right in the beginning – with its designation as a “manifesto”. A manifesto is a statement of beliefs, a public declaration of intents or motives. There is nothing about sprints, or boards, or “masters” of this, or “owners” of that anywhere in the manifesto.
Just because you track everything you work on doesn’t mean you are Agile.
Having a backlog doesn’t mean you are Agile.
The team calculated their story points just right and had a little bit of extra development time at the end of the sprint? That’s great – but it doesn’t mean you are Agile.
Everybody loved what was demoed in your last sprint review? Well, that’s an indication that you are pointed in the right general direction – but it still doesn’t necessarily mean you are Agile.
Agile isn’t a methodology, it is a philosophy.
Yes, you need a methodology. No, it doesn’t matter which one you pick. Or rather – it matters for you and your team which one you pick, but you can be Agile using any framework out there. Yes, even with waterfall. For some types of projects, waterfall is the right way to build things; a waterfall approach to development won’t by itself stop you from being Agile. Made up your own methodology? You are probably ahead of everyone else, because of course what works for somebody else with a completely different context and needs won’t work perfectly for you.
Things have changed a bit since the Agile Manifesto was written. Some of the details of how we work and what we call things as an industry have evolved – but all the same ideas still apply. For example:
- Is there so much of a focus on how you write commit messages and perform pull requests that it slows down the actual development work? You might be prioritizing comprehensive documentation over working software, backward from the manifesto.
- Do you spend a lot of time arguing with people over the contents of a user story and what it was actually supposed to mean? Do find yourself thinking “Boy, I sure wish we could get in the same room as our stakeholders”? You might be prioritizing contract negotiation over customer collaboration, backward from the manifesto.
- When the sales team tells you that a new customer needs some feature moved way up in the backlog, does the whole team groan and complain? You might be prioritizing following a plan over responding to change, backward from the manifesto.
- Are there work-stopping arguments about git branching strategy? Do you completely re-evaluate every component in your teams’ standard development environment on a monthly basis? You might be prioritizing processes and tools over individuals and interactions, backward from the manifesto.
Yes, standardizing your dev environment is important. Yes, style guidelines should be set and followed. Commit messages should be written in a way to be useful, the sales team should let you know as soon as possible about upcoming priority changes, etc., etc.
The Agile Manifesto is clear though that those things aren’t unimportant – only that they aren’t quite AS important: “…while there is value in the items on the right, we value the items on the left more”. Take care of the standardization, take care of the style guidelines and everything else, but don’t let it get in the way of producing value.
If there is a certification, or a book, or a dollar to be made by somebody promising more agility for you and your team, consider it with suspicion. If any new steps and processes you are considering (or are being told to do) ultimately come down to greater control for somebody, it’s probably not Agile.
The Agile Manifesto is a time-tested, proven set of philosophies. It’s not a prescriptive plan, and doesn’t intend to be – but when taken as intended it can help you and your team examine the way you work and produce value more effectively.
