#2 Agile software development – the Agile Manifesto in practice

Manifesto is a good first step. But what does this mean for your day-to-day work?

In my first blog post, I primarily focused on the historical background of agility in software development and explained what the term means in basic terms.

For that reason I will not revisit the topic at this time. In 2001, 17 software developers provided a description that helps us to apply and understand it correctly to this day. I am talking about the Agile Manifesto and its 12 principles. Before we kick things off, here’s a little tip: there will be a separate blog post that explores the 12 principles.

The Agile Manifesto

It is short and simple, but also concise, authoritative and immensely useful. The Agile Manifesto includes a host of information that could help improve our day-to-day agile work, that is if we even know what it contains in the first place.

The message is as clear as could be: ‘We lead the way and show how it is done. Others will then follow.’ And they were right. ThReading the Agilee Agile Manifesto is still with us 20 years later.

By doing so, we’ve come to appreciate how important these values are:

• Individuals and interaction over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

In other words, although we believe the values on the right are important,we think the values on the left are even more significant

We value individuals and interactions over processes and tools

If we cultivate, debate and agree on the values as a whole in the company, this will have a direct impact on our day-to-day work. Do I now write a message in Teams, create a BPMN and send it? Or do I first try a targeted conversation? No doubt about it, tooling has its virtues. It can be definitely prove useful in a number of situations, but wouldn’t a short conversion have had a similar or even greater effect in many cases? By repeating the phrase ‘we value individuals and interactions over processes and tools’ to myself more often in future, it is likely that I will engage in conversation with someone more often instead of hiding behind tools. It is this type of communication that ensures that we work with increasing frequency with each other, understand each other better and learn from each other.

But there is much more to it. We focus on the individual. This means we accept that everyone is able to add value based on their unique set of experiences and skills. The more we communicate and talk to each other, the more we benefit from swarm intelligence in a certain sense.

We value working software over comprehensive documentation

That would seem obvious, wouldn’t it? What’s the good of having great documentation if the solution doesn’t work? But what does working software mean for us as a company or team, and is everyone familiar with this definition? When is a piece of software finished or functional?

We can improve our product development process if we sit down with the users for whom we are designing a product and come to a mutual understanding. The more often we do this, the better. The more open and transparent we are with those with whom we talk and share information, the more we can learn from each other and the faster we can react when problems occur. By giving the teams greater autonomy and independence during the development process, we can shorten the time between releases and more quickly measure the added value we deliver. Each of these things are vital to creating software that works. Who could argue with this? Yet the word ‘documentation’ did not even appear here.

Do we still need documentation then? Absolutely. But how much documentation do I need for software that is logical and intuitive?

We value customer collaboration over contract negotiation

Contract negotiations are important. The Agile Manifesto says just that. But there is more to it than that. The closer and more often we work with the client throughout the process, the fewer details we would actually have to include in a contract, right?

The advantage of having a standard contract that contains every detail and bit of information you might need for product development is that you don’t have to think that much and less communication is needed. But is that really a good thing? In a standard contract, this particular detail automatically takes on a central role. If it changes, this creates a number of problems since a lot of time has already been devoted to it.

In the agile field, we like to work with goals. This gives us something to focus on. We can describe the path to reaching the goal in some amount of detail. However, the details start to emerge as we get further into our work, be it by providing the customer with regular updates on the status of development work, creating mutual interest and drawing on feedback from the client in the software development process. We understand that conditions, technologies and requirements may change again. The likelihood of this happening is so high that we accept that it is inevitable. It’s certainly true that mistakes may be made along the way, but if we continue to focus on the goal, it’s difficult to get too far off track. If we do not define all the details beforehand, we can save time and get to work immediately. Change is a good thing under the agile approach. Every change brings us one step closer to what the customer actually needs.

We place responding to change over following a plan

If you take the agile approach, you need to have a plan. And we also have one. It is more limited in scope than is typically the case in traditional project or product management (we place functioning software over comprehensive documentation). But it does exist.

In agile software development, a plan often starts with a vision or a goal. This vision is often honed or further elaborated together with the stakeholders who need to be part of the process (customer collaboration...). This creates transparency and establishes a focus. These goals are generally far off in the future. The bigger the goal, the more uncertainty there will be regarding when and how we can achieve it. Therefore, it can be useful to divide a large goal into several smaller ones. These can be readily achieved and help us reach the main goal.

In practice, when changes occur, they are less related to the goals and more to the work we are doing at the moment, meaning that while the focus remains, we have to make adjustments here or there. We accept this will happen because we have one goal in mind.

A family who’s planning to build a house works with an architect to find a design that works for them. This is the vision for how the home should look. In this and the more conventional approaches, all the details are generally documented. At the end of the process, you have the finished house. And it is likely something that the family is even happy with. So why change anything? I imagine that if you had the opportunity to move a window, increase the size of the kitchen beyond the original dimensions or decrease the size of a closet to create a larger guest bathroom, you would do this too. Nothing has changed in the end. You just made a few adjustments along the way.

How well does your team know the Agile Manifesto? Do they put the four values into practice, and if so, how do you measure this?

You will find more exciting topics from the adesso world in our latest blog posts.

Why not check out some of our other interesting blog posts?

• Agile software development – we work in an agile way: here’s how