Being agile was never about the process

We’ve come a long way since the Agile Alliance published its manifesto back in 2001. It feels like the majority of teams and companies doing software development have figured out that agile is the way they want to be doing things right now. In my 10 years as a software engineer I have taken the roles of developer, scrum master, and facilitator and often found myself reshaping the processes that were in place. The thing I noticed that was often missing in action was probably the most important one: the Agile Manifesto. Let’s review it together.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
1. Individuals and interactions over processes and tools
This is a pretty big one to begin with. I wrote in the introduction that many companies have been doing agile, but what I meant to say was that they have instituted a certain form of agile process. While I believe that discipline is crucial in maintaining agility, we need to be wary of making our processes too rigid. I’ve often heard people claiming they can’t do X or Y because the process wouldn’t allow it, instead of asking how we can shape our process so that X and Y become available options.
Let’s consider the classic daily stand-up meeting in light of this part of the manifesto. It’s a tool dictated by the process to facilitate individuals to interact. However, in practice it’s often a tool to get a quick status update from everyone in the team. If your stand-up is about pointing at a person just so they can tell you what they did yesterday and what they will be doing today, you are most likely doing it wrong. Ideally, you have a visual representation of your workflow and process so you already have this information. Instead, use your stand-up as a means for individuals to interact, to find opportunities to help each other and to identify things slowing them down as early as possible. Once your team picks up these habits, encourage them to do these things outside of the stand-up meeting as well. After all, it makes absolutely no sense to wait for the next day when you are stuck and need help. The ultimate goal should be to have interactions at such a high level that we can get rid of the daily stand-up entirely.
Remember that every process you instate has impact on how people are doing their work. If their way of working changes, so should your process. A team that reaches a certain maturity level is often hindered by early processes that were designed to get them to that maturity level in the first place. Take away the impediments and use the team’s insights to further revise your processes. After all, your individuals and interactions should shape your processes and tools, not the other way around.
2. Working software over comprehensive documentation
I feel like this is a part of the manifesto that most agile teams have understood well. Sometimes even too well. The reason for this is that very few people enjoy writing documentation. Let’s go back to the original manifesto for a bit and read on. See this line right below the manifesto?
That is, while there is value in the items on the right, we value the items on the left more.
There is a very crucial point being made here. While delivering working software is the top priority, it should be no excuse to abstain from documenting what is important. I have seen this go to the point where teams start to build solutions without a thorough understanding of the problem. I have read more one line user stories than scenarios with proper acceptance criteria. If your team has a hard time balancing working software and solid documentation, you may want to take a look at Living Documentation by Cyrille Martraire.
3. Customer collaboration over contract negotiation
In the past I repeatedly had the pleasure of working on undersold projects. Pressuring a team into delivery and reminding them about the costs and deadlines easily results in frustration, lowering the quality and speed of delivery even more. There are approaches here that the manifesto hints at, but fails at making very explicit. In a situation like this it is quite beneficial to put customers and developers around the same table and let them collaborate on a solution that solves the customer’s problem. Developers are natural problem solvers but they need to have the correct information. Who is better at providing that information than the customer?
In a non-agency environment, where you are working for an internal customer, similar techniques can be used. Classic scrum processes very often put a product owner between a customer and the development team. While this was designed to protect the team from interrupts and let them focus on their work, it is easily pushed too far. The agile manifesto encourages customer collaboration and I strongly believe this needs to include the development team. Similar approaches come from the world of Domain Driven Design, where communication and collaboration between business, development and domain experts are instrumental to the process and seen as a key factor in successful software delivery.
4. Responding to change over following a plan
And here we arrive at one of the toughest points for developers in an agile environment: change. Even though most developers embrace agile, they still hate it when a part of their work becomes invalidated due to changes in business decisions. If this is something you have to deal with regularly, here are a couple of things you can do:
Embrace it
People change their mind, businesses change their ideas and focus. It’s just a fact. You’re okay with refactoring your own code right? Look at this in the same light, but with business ideas. When your mindset is to always be prepared for changes, they will have a lower emotional impact on you.
Develop to refactor
Failure to quickly adapt to change is not always a problem in the process, but also in the code. While there are many good practices on writing software out there in the wild, try and evaluate them in light of refactorability. Design software with change in mind and future you will be your best friend.
Scope down
Having to throw away large amounts of work is never fun. Make sure to chop things up in smaller deliverables so you don’t have to redo large chunks of work.
Offer insights earlier
By collaborating more with your business, you may have helped them find the new focus earlier in the process, saving you a whole lot of work. As a developer you often have different insights that can be very valuable to the business.
Remember that flexibility and being able to respond to change quickly is one of the main strengths of an agile team so we should collectively try to get rid of the negative feelings around the concept. No matter how much work you throw in the bin, you are solving today’s problem, not yesterday’s.
When evaluating your internal processes, always keep the manifesto in the back of your head and actively look for improvements. Put people and interactions first, don’t forget to write down the necessary information, collaborate with your customers and help them with changing their focus when needed. In the end, we all want to deliver working and valuable software, made with love.

I’m Jonas Drieghe, software engineer at madewithlove.
I love building applications in complex domains, refactoring legacy code and coaching people.
In my spare time I’m often organising Magic: The Gathering events or playing music.