68 Words that Changed Everything?

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.

These 68 words have entirely changed the way we approach software yet almost everyone has a different interpretation of them. Almost every software development team claims to be agile yet when you ask anybody in software what they understand by agile you’ll get an answer like SCRUM, Kanban, SAFe, JIRA, daily standups, or retrospectives. Yet not one of these things has more than a passing relevence to what agile actually is.

If we were to go back and truly understand these 68 words, we could really revolutionise how we conduct our business in software development.

This is how I understand the four basic values of the Agile Manifesto.

Individuals and Interactions over processes and tools

Two of the great pitfalls in Agile are software developers’ love of tooling and managers’ love of process. The key part of this statement is that the individuals on the team are far more more important than either of these things. Every software professional is an individual with a unique mix of skills and experience. They are irreplaceable and the seconds you start thinking about the “resources” on our team you are doomed. Equally important is the relationships on your team. Without trust on the team, you are doomed. Once you start blaming failures on IT, back-end, UX or front-end you are finished with. These interations between individuals are what makes a collection of people a team.

Once you have your Individuals Interacting, you can focus on your processes and tools. In the words of Colin Chapman, you must “Simplify, then add lightness”. The key is that the team gets to choose this. They are the ones using the process and tools and they should be trusted to make good decisions. Choice of process and tools should be influnced by organisational culture but not proscribed on anyone.

Working Software over Comprehensive Documentation

This the one that has software developers jumping for joy but then almost always ends up getting taken too far. The one constant in software documentation is that it is always out of date. The logical conclusion is that you shouldn’t bother — just read the code since it defines what is going on.

There is a real problem with comprehensive documentation is that does seriously get in the way of true agility since it means that your feedback loop from build — measure — learn gets a step longer which really hits your velocity.

For me, the only way round this is to treat your test codebase as your documentation. As much code as physically possible should be unit tested from the start. No excuses, no writing tests later. No matter how much of a hurry you’re in, the business will probably benefit from spending more time on non-software MVPs that should give you enough time to properly write unit tests that both test your code and document what you do.

Customer Collaboration over Contract Negotiation

Good luck with this one.

Only once in my career, I have been in the position to apply this principle and was easily the best project I ever worked on. This is where Agile gets taken to the entire business and not just left with the software engineering department. The problem here is trust.

For this to work, the customer has to accept that they can’t just pay you a sum of money to deliver a set of features. Instead, both the developer and the customer have to agree with you to work on delivering software, measuring how well it works and learning from the sucesses on failures where to go next. This has to be repeated until you run out of money.

Like I said, good luck with this one.

Responding to Change over Following a Plan

This is another tricky one. Managers love to have a plan and it is is important to have one. But you are never going to end up following it.

No plan survives contact with the enemy

If your methodology is to spend a substantial period of time planning a software development project, you will almost invariably end up wasting 90% of that time. So instead of building a schedule dictating when your individual components should be delivered, the plan should focus on how you can build enough software and infrastructure that you can start delivering value to the customer as soon as possible. Only when you are doing this, will you be able to learn anything. And once you start learning stuff, your plan will go out the window. If it’s all going to plan, something is probably wrong somewhere.

For me the most important take-away from this statement is that putting the infrastruture in place to enable you to respond to change is far more important than building and following a detailed plan.