21. July 2022 By Stefan Mönk
#3 Agile software development – agile in principle
The Agile Manifesto that I presented in my previous blog post now needs to be lived. But how? Twelve principles, which can be understood as codes of behaviour or rules of the game, were established for this very purpose. These principles help provide you the ability to live agility, but not to be able to measure it. Covering all 12 principles in one blog post isn’t that easy, so I’m splitting them up into two blog posts – which means a sequel is already guaranteed ;).
We follow these principles...
We take the following principles from the Agile Manifesto:
Our highest priority is to satisfy
the customer through early and continuous delivery
of valuable software.
In basic terms, it means that we want to provide software regularly and early. This means that small increments – for example, the software’s subfunctions – are provided and a largely iterative approach is taken. We use the feedback we receive by adapting and improving what we do with the next small iteration.
We basically want to reduce complexity in the agile world; and one of the ways we do this is via continuous delivery of increments. Complexity is reduced by sticking to the same rhythm instead of providing software as needed and at irregular intervals. In the agile approach, we try to hold meetings, events and much more at the same time and in the same place. The better we manage to do that, the less we have to worry about organising everyday life. The principle here is to focus on the customer or stakeholder, because, in the end, that’s who we’re doing all this for.
Nobody wants unhappy customers. We have the ability to influence satisfaction in various ways. The crucial thing here is to reduce anxiety and provide security. What better way to do this than to regularly show stakeholders small steps forward and integrate them into the development process? Trust is built by taking feedback seriously and demonstrating in the next iteration that we’ve learned something from it.
Welcome changing requirements, even late in development.
Agile processes harness change
for the customer’s competitive advantage.
Change is a good thing, and we know that it’s part of the process. Instead of seeing the extra work as a burden, we welcome it as an opportunity to do things even better.
If we deliver software regularly and in short stages and are open to a lively exchange with the customer, we will constantly receive their requests for changes and adaptations as we continue our work together. This results in a solution that is much more tailored to the customer’s needs – and that’s exactly what we want to achieve in agile software development. This way, we create real added value for the customer and can remeasure, re-evaluate and, if necessary, recorrect it with every conversation.
Deliver working software
frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
We’re brave and try to deliver small increments within about two weeks instead of two months. The main thing we need to do this is the courage to only take small steps. The customer has to work with us in this regard as well, as working with them to test only small subfunctions at regular intervals instead of one large function after a few months makes a difference.
The less time it takes you to check the working software with the customer, the smaller the feature and the more often we talk to each other. The advantage is that we regularly receive feedback from the customer that can be taken into account and used in the development process.
Businesspeople and developers
must work together daily
throughout the project.
The core elements of agile work include clarifying issues and breaking down silos and interdepartmental thinking – all of which require regular collaboration. We want to benefit from swarm intelligence; and the best way to do that is through a daily exchange between experts and developers. Experts are those who know about the ‘what’. Developers are the ones who make the decisions about ‘how’.
A better understanding of what is needed and actually wanted is created for both groups involved when they talk to each other instead of using documents to communicate. And quite incidentally, customer satisfaction also increases in most cases. Transparency and communication promote trust. And the developers’ satisfaction also increases because they can better experience and understand the added value that was created.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
Trust. We’re saying goodbye to the old system in which everyone focused on their own area of responsibility and showed little interest beyond that. We work together as motivated colleagues towards a common goal. We trust that everyone involved will do their best to develop working software. This, by the way, means that everyone has the opportunity to bring out the best in themselves. The more confidence we have, the more courage we find to develop creative solutions.
The most efficient and effective method of conveying information
to and within a development team is
The focus of the agile approach is on interpersonal communication – in face-to-face conversations, not via e-mails or documents. Short and target-oriented meetings cannot replace documentation or correspondence in every case. However, they do ensure that obstacles or ambiguities are able to be addressed directly. This saves time and creates a faster and better common understanding of what needs to be achieved. The more we enable and support goal-oriented interpersonal interactions, the faster a team can grow together. An agile team says goodbye to individual and personal goals and focuses on common values and goals.
Agile in principle
We’re still missing the remaining six principles. But if even just one person who reads this blog post is already researching them out of curiosity, then it was worth both the trouble and effort.
We can gladly call what we do agile. We can gladly say that we work according to Scrum and are therefore agile. We can also claim that we’re agile because we often show our customers a result in the interim. Nobody forbids us to do that. But are we being honest with ourselves?
Referring to the Bible, Luther is quoted as having said, ‘Every Christian should read and understand the Bible for himself’. Now it’s in no way my intention to equate the Bible and the Agile Manifesto, but I would like to add this: if you want to live agility, you should read and understand the Agile Manifesto and its principles yourself.
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?