The difference between a dead and an alive Agile Manifesto

One of my favorite books on leadership is “Extreme Ownership” by Jocko Willink and Leif Babin. I can imagine some people bouncing off of the book because of the Navy SEAL angle, but to be honest I’m a bit of a sucker for the whole military leadership genre.

The second part of “Extreme Ownership” covers four critical leadership concepts, the “Laws of Combat”. Curiously enough, you can map these to the four values in the Agile Manifesto. These four concepts do come in a specific order, so you have to shuffle the Agile values around a little bit:

• Cover and Move maps to customer collaboration over contract negotiation.
• Simple maps to working software over comprehensive documentation.
• Prioritize and Execute maps to responding to change over following a plan.
• Decentralized Command maps to individuals and interactions over processes and tools.

To me this mapping is interesting in two ways. It sheds a different light on the four Agile values. And it’s an example of how I think we should be engaging with the Agile Manifesto, in a way that keeps it alive.

Customer collaboration over contract negotiation

“Customer collaboration over contract negotiation” maps to Cover and Move. Teamwork. In the military sense: one team moves, while the other team covers them. You keep each other safe. You work together towards a shared goal. You help each other out.

I think I prefer having this as the first value instead of “individuals and interactions over processes and tools”. The two obvious teams in software development are “IT” and “the business”. This principle tells us that if those two teams will not collaborate, things are going to get rough. It tells us that good software development starts with Business and IT being on the same side, looking out for each other. And by being the first principle, it makes it clear that this is the first one we need to get right.

Working software over comprehensive documentation

“Working software over comprehensive documentation” maps to Simple. The plan needs to be simple (enough). You will have a million things on your mind and you need to make a decision. You don’t have the mental bandwidth to consider a complicated plan. You need a clear goal and a simple plan to be able to make a decision in a complex situation.

In software the simple plan is: build working software. You will need to do a lot of other stuff to be able to do so. Too often we get sidetracked by those other things. Writing documentation, filling up a backlog, moving a ticket to the Done-column, none of these are building working software. So once in a while, ask yourself: is our focus on building working software?

Responding to change over following a plan

“Responding to change over following a plan” maps to Prioritize and Execute. Assess the situation, decide what needs addressing first, address it, then move to the next most important thing. Don’t wait for things to resolve themselves. Don’t stick to the original plan no matter what. Remind yourself of your goal and get things done, one thing at a time.

One thing that Prioritize and Execute has over the Agile value, is that the Agile value suggests a dichotomy. You either respond to change or you follow a plan. While Prioritize and Execute says that responding to change involves making a plan. You anticipate problems and make contingency plans. Responding to change well does not mean having a single plan or no plan, it means having multiple plans.

Individuals and interactions over processes and tools

“Individuals and interactions over processes and tools” maps to Decentralized Command. You don’t want every decision to go up the chain of command, where some high-level person makes all the calls. While these days we do have the high-tech tools to support that kind of process, it’s a horrible way of getting things done. Instead, you train your people to Cover and Move, to have a Simple plan, and to Prioritize and Execute. And then you trust them to get the job done and to decide when and if something needs to go up the chain of command.

While Decentralized Command is the fourth and last principle, it maps to the first Agile value “individuals and interactions over processes and tools”. I’m not sure if the authors of the Manifesto put much thought in the order of the values. In my opinion, it makes more sense to put this one last than first.

Agile has gotten a reputation of being mostly about soft skills and touchy-feely stuff. That, and using sticky notes in every meeting. While that image may be unfair, opening with “individuals and interactions over processes and tools” doesn’t help. It can come across as asking to abandon all existing structure and get carte blanche to figure things out as we go. Better to first start collaborating with the customer, deliver working software and show you can deal with contingencies. That’s how you earn the trust needed for Decentralized Command.

The difference between a dead and an alive Agile Manifesto

The Agile Manifesto is a very short document. Especially if we reduce it to its four values and forget about the twelve principles. It’s also the core authoritative document on Agile. As a result, I’ve often seen it used as no more than an empty symbol. It’s treated as some eternal truth descended from heaven, where simply mentioning the Manifesto gives weight to whatever argument you want to make.

To me, that’s a dead Manifesto. Something you put into a museum to preserve. Something that grants no authority to the people uncritically quoting it - even though they may believe otherwise. A dead Manifesto is not something that will inspire you in your journey in software development. For that to happen, we need to engage with it. Participate in the shared work of continuously interpreting and re-interpreting it. That’s how we can keep the Agile Manifesto alive - if we choose to do so.