When following Agile, don’t forget the items on the right!

The Manifesto for Agile Software Development is a guide meant to help people develop and deliver better software. It’s based on 4 core values and 12 guiding principles. Here is a link to the manifesto where you can find additional info, but here is an extract for convenience:

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.

Most of the software delivery teams I have been in over the last 10+ years have followed agile methodology, so I am well versed in it. Most applications you use today were probably developed by teams who follow a flavour of agile. It works, so if you are in the industry, it’s worth knowing.

Many teams however don’t get it all that right, common pitfalls are that it becomes a checkbox exercise or a team tries to follow it too rigidly. I have seen one team miss the mark rather uniquely before. They got the core values (items on the left) so right but they completely missed the values on the right, don't fall into the same trap, don't forget them.

Hold onto your pitchforks, let’s break it down:

Individuals and interactions over processes and tools…

People and collaboration solve problems, we get things done, no doubt, however with the right tools we are able to solve problems more efficiently and effectively and with the right processes, we can do things consistently and confidently. Tools and processes make work more easily transferable, learnable and explainable...

For example: Using tools like Jira or Azure DevOps to manage your projects work items with clear processes in place so that Developers know which items to work on, and when to move them into QA’s queue notifying QA that a work item is ready for them to test before signing off. Better yet, most of these transitions can and should be automated so that you don’t even have to ask your teammate if their work is ready to test, you will know thanks to your tools and processes.

Working software over comprehensive documentation…

This one I won’t challenge, not the comprehensive part at least, but documentation does have its place, provided it is maintained, as incorrect documentation can be more dangerous than no documentation. Working, tangible software is the quickest feedback loop you will have to know if you are building the right thing.

Documentation comes in handy for reference purposes, something to refer to when people might not be available, which when you are working on older code bases, is often. Documentation should be source controlled as it offers history with point-in-time accuracy allowing you to build a timeline from it. The same goes for task-tracking platforms (like Jira and Azure DevOps), they come with built-in auditing and can be a great source of documentation when you are populating work items with adequate context and linking them correctly to commits and pull requests etc.

Customer collaboration over contract negotiation...

Remember that difficult client with some inferiority complex who was constantly unsatisfied and complained about everything? No one wants to work with them, I completely agree. Collaboration and buy-in (not just financially) from a client is imperative for any successful project or lasting relationship. Contract negotiation has its place though, it stipulates the rules of the game and protects both parties by clearly stating expectations of one another. It holds each party accountable, usually, one for the paying of a service and the other for delivering the agreed upon service.

Responding to change over following a plan…

Of course, we have to be adaptable to change, life happens, and things rarely go precisely according to plan, if only! Who builds software? (yes AI does too I know), but there are still people involved. We are human beings, we need something to aim for, it’s in our DNA. We must have an aim, or else we kind of just drift around. You have to set out clear, ideally SMART goals so that you know where you are going and when you achieve them.

There you have it, in my experience, the most underrated phrase in the Agile Manifesto is: “there is value in the items on the right”. Focus on the left, they are more important, but they don’t replace the items on the right. No matter how successful a methodology is, don’t just follow it blindly, question it, think about it, understand it, practice it and always remember to be pragmatic.

Written by a human