#4 Agile software development – agile principles for everyone

A guide to agile behaviour – part two

We have already covered some of the basics. We now know what the Agile Manifesto is and have an idea of why it exists, what it deals with and why it is worth taking a closer look at it.

In my last blog post, I introduced you to six of the twelve agile principles. These should help us not only to implement agility, but to live it, too. Let’s take a look at the other principles to complete the picture.

We take the following principles from the Agile Manifesto:

Nobody wants software that doesn’t work, that’s obvious. We invest our time, our diligence and our work into developing software that works. The easiest way to determine whether the software works and is helpful is to work together with the customer. We collect feedback and use it to inform our work. One of the ways we achieve this is through fostering an error culture, which we use to help us learn from our mistakes. We are able to measure and question our work by being highly transparent about both problems and successes. Having the willingness to constantly learn from and with each other is the only way we can achieve our goals.

The idea behind this principle is that everyone, from the customers, to the experts, to the project or product managers and the developers, works together towards a common goal. They should all know what that goal is and understand it. If they don’t do this and work in a way that lacks transparency and/or work at different speeds, we will deliver increments late or not deliver them at all. We get out of step because the left hand doesn’t know what the right hand is doing. Everyone deciding to focus only on their own work will unintentionally create dependencies. If this happens, we build individual solutions and distance ourselves from creating a joint solution.

We can only achieve positive results if we work together. The advantage of being able to release software quickly at any time can swiftly evaporate, especially if the customer is able to use the software directly. The danger of the development process going in the wrong direction increases. The faster a customer expects results, the faster the pressure grows within the team. This also increases the risk of contradicting the principles of working software, as we will be quicker to compromise for the sake of the customer. These compromises will eventually catch up with us and cost us time and money. Compromises are not a bad thing in theory. They happen every day. In order to guarantee sustainable development, we are obliged to weigh up the compromises and not to make them simply because someone at some point agreed to a deadline.

A team or even a company should have a common definition of quality first and foremost. The same applies to good design. Why is having a good design and technical excellence so important anyway? Isn’t it enough if the software just works?

A car that drives serves its purpose. If it doesn’t drive and no one can work out why, we have a problem. Now you have to find an expert who can identify the problem and solve it. And once you’ve found your expert, the repair still takes time. Now there are some faults with the gearbox because the work wasn’t done properly during the production process.

Compromises were made so that the vehicle could be delivered early. Quality had to suffer – the gearbox in this case. We are no longer faithful to this principle. Our customer isn’t satisfied. Was it worth it now?

A team or organisation should talk about what criteria need to be in place for an increment to be considered ‘done’. ‘Done’ should mean that this piece of software can be released and handed over to the customer. If we know what we mean by ‘done’, we’ll only do what is really necessary to declare an increment ‘done’. We save ourselves the rest of the work. If everyone has a different idea of what ‘done’ means, this will be reflected in their work and create a system of differing quality levels overall.

It takes openness, transparency and a lot of communication to create a common understanding. Adhering to this definition during the development process requires courage. The courage not to overdo something I enjoy. The courage not to dismiss something I don’t enjoy.

The key word in agile working here is self-organisation. Give the team an environment in which they can work and agree the goal to be achieved with them. The team does the rest – being completely self-organised and self-reliant. At first, that sounds like everyone has carte blanche and they can do what they want. That’s not the case. There are frameworks (such as Scrum) that will help them channel this large amount of freedom using structures and processes.

We don’t just want to regularly deliver working software. We also want to learn regularly. The best way to do this is to find out how we can use the experience we have gained to help plan our next steps. Talking openly about successes and failures is the only way that we can identify what we want to keep and what we should say goodbye to.

On that note, this is an excellent opportunity to announce the topic of the next blog post: empiricism. Gaining knowledge from experience fits perfectly with this important agile principle.

Agile principles for everyone

The main message here is that the more aware we are of the twelve principles, the more they can help us to be agile in our day-to-day work. By at least understanding the principles, we can effect positive change on the way we think and work. When it comes down to it, it’s all about self-organisation, quality, transparency and continuity.

Have you ever discussed the twelve agile principles in your team and reflected on how you deal with them in practice?

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?

• #1 Agile software development – we work in an agile way: here’s how
• #2 Agile software development – the Agile Manifesto in practice
• #3 Agile software development – agile in principle (in German)