What is Agile?

I was speaking with a client recently who kept saying her company was Agile. They did Scrums every day and they did demos. So they must be Agile, right?

Agile is so much more than that - but also so much less. Agile is an umbrella that contains many frameworks. Scrum, Kanban, and XP are all frameworks that fall under the Agile umbrella. The most important part of a company being Agile is that it follows the Agile Manifesto.

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.
(https://www.agilemanifesto.org/)

If you read the Agile Manifesto you see it doesn’t mention Scrum, stand ups, pair programming, test-driven development, retrospectives, or Kanban boards. While those are practices that are Agile, they are not the definition of Agile.

Many companies decide they want to “do Agile” so they add practices. Those practices are very valuable. But you don’t “do Agile” just by doing this practices, especially if your culture is such that is in a straight jacket of process instead of having process serve you. 

Let’s unpack each of those values.

Individuals and interactions over processes and tools

I saw a post on Twitter from Derek Huether saying “individuals and interactions over Scrum and JIRA” and I thought that was really great, since I’m using both of those! What this value means to me is that PEOPLE MATTER. PERIOD. When you are working and you are trying to figure out what is the right thing to do, the right thing to do is always to connect, as human beings. It’s to interact with another human, as another human being who makes mistakes and has flaws. It’s being okay if we are not perfect. It’s putting connection with your team mates over doing things “right.” It’s figuring out the smart way to do things even if your tool can’t track that perfectly.

Working software over comprehensive documentation

I’ve gotten questions during which people ask if user documentation is what this topic is about. It is NOT about user documentation - user documentation is PART of working software, if that is one of the product deliverables. When this value talks about documentation, it’s talking about process documentation or requirements documentation. We want to build software that works instead of writing about software that works. This doesn’t mean we don’t write out user stories and requirements - it just means that we talk about it and try to build what we talk about instead of writing large documents.

Jeff Patton, in his book User Story Mapping, says that requirements are like the picture from your vacation. The actual vacation itself is the conversation the team has with the customer (or whoever represents the customer). The pictures from the vacation are supposed to remind you of the vacation--they are not the vacation. They are not valuable if all you have are pictures. The value is in the conversation. We need to have a great conversation and figure out what we want to build, then let the documentation remind us of that conversation.

Customer collaboration over contract negotiation

This value means that we work with our customer (often a product owner or business analyst) over trying to negotiate them into doing what we want. We want to satisfy the needs of our users and work with them. Another thing that Jeff Patton writes about is scope creep. People say this like our product owners are trying to get away with something. Oh - they’re sneaking something in, that is scope creep. Patton says instead of scope creep we should say DEEPER UNDERSTANDING. Of course we discover more as we dive deeper into the work, of course we understand more and have to clarify. Then we need to decide, TOGETHER, does this make it too big? Do we need to split this work again now that we know more about it? That’s a good conversation to have, not a bad one.

Responding to change over following a plan

Deeper understanding flows nicely into the idea of responding to change over following a plan. We can never know exactly what we’re doing at the beginning. We have to dig into the work and allow the truth to emerge and evolve as we go. And then we need to respond to it. Of course it’s changed. Ignoring it doesn’t do us any favors, or our customers that we are trying to serve. Let’s acknowledge things have changed and come up with a NEW plan.

So What is Agile?

If you are working to use the Agile manifesto, then you are becoming Agile. The other frameworks and methodologies can really help, but what really matters is using the manifesto. It can be used to build better software, but it can also be used to build better houses, to write better legal briefs, and to write better blog articles. Let's keep working to help our teams use the Agile manifesto to make the world a better place.