Agile software development – a term that is ubiquitous in the tech world. But what does it really mean to work agilely? And how can agile principles best be put into practice?

We sat down with Robert Stelzmann, Product Owner at weasl, and talked to him about agile software development. In our conversation, he provides exciting insights into how the weasl team works and what agility has to do with the continuous development of our worker guidance system.

Robert Stelzmann:

I would perhaps turn the question around: “What is agility not?” Obviously, implementing waterfall models, that's logical. But it's just as little agile to pack an outdated process model into a Scrum corset and then hope that everything will miraculously turn out fine.

I would say the simplest – and probably least helpful – answer is: adhere to the values and principles of the agile manifesto. However, this requires not only reading (which is where most people fail) and understanding these values and principles, but also “internalizing” them. Being agile means thinking and acting in a fundamentally value- and people-oriented way. That may sound like a banal platitude, but practically every “agile activity” can be traced back to it.

Robert Stelzmann:

I think the most “unagile” thing you can do is to claim (and even worse, believe) that you are ‘completely’ agile. That you have somehow played through the agility game. An important, if not THE most important, core idea of agility is the pursuit of improvement. Accordingly, an “agile journey” can never be complete. Agility is definitely not measured by the number of rituals you perform – no matter which agile textbook they were taken from.

Accordingly, I would soberly describe our agile level as “average.” We are constantly evolving. For example, as a team (team autonomy, also an important principle!), we decided that Scrum does not work well for us. We simply don't want to think and work “in grids.” We want to stay focused and “in the flow.” We don't want waterfalls – not even 2-week sprint mini-waterfalls. We want to release continuously, at least daily. We want to be able to react and adapt quickly. Accordingly, we have changed our way of working to a Kanban-oriented approach.

We don't plan two weeks in advance, but continuously. What's on the agenda for today, tomorrow, next week? What is the big goal for this quarter? We have also changed our traditional review meeting. We conduct reviews in the team on an ongoing basis, similar to planning – and it's okay if they get very technical. Nevertheless, we have decided to keep our old review date, but now we conduct it with the entire company and our partners.

Of course, we have also continuously developed this format. We no longer go through ticket by ticket and discuss implementation and impact, but try to explain in large, related topic blocks what we have done, what our goals are, and where we want to go with them. In short: how we intend to create real value with our work. Of course, the format is designed to encourage discussion and criticism. We are very grateful for feedback and want to identify potential problems early on (see manifesto!).

Robert Stelzmann:

1. Read the Agile Manifesto. Print out the values/principles. Hang them up, make them “ubiquitous.” Start asking yourself continuously: “Are we acting in accordance with these values and principles right now?” If not, why not? What would be “agile”? Get started!
2. Start small. Scrum is by no means universal and always perfect. But: It is well known. Most developers have a basic understanding of how Scrum works – it's easy to get started with it. Work your way forward from here: Be transparent in your reviews, invite your stakeholders. Deliver (at least) one increment of good quality at the end of the sprint. Not working yet? Then invest in technical excellence: CI/CD, test automation, etc.
3. Stay on the ball. Setbacks are normal. It's about developing – learning. Take the retros seriously. Keep asking yourself: How can we do better? And very importantly: Get to the root of the problems – 5 Whys is a wonderful methodology for this, for example. Remember the positive view of human nature: if your analysis ultimately points to a single person or department, you're probably not at the end of your analysis – the problems run deeper. Derive actionable measures and then implement them! Very important: this applies to everything! Product/project, technology, organization, culture – everything.