Agile software development - a term that is ubiquitous in the tech world. But what does it really mean to work in an agile way? And what is the best way to put agile principles into practice?
We sat down with Robert Stelzmann, Product Owner at weasl, to talk to him about agile software development. In the interview, he provides exciting insights into how the weasl team works and what agility has to do with the continuous development of our worker assistance system.
Robert Stelzmann:
I would perhaps turn the question around: "What isn't agility?" Sure, implementing waterfalls, of course. But it is just as little agile to pack an encrusted process model into a Scrum corset and then hope that everything will miraculously work out.
I would say that the simplest - and probably least helpful - answer is to stick to the values and principles of the agile manifesto. However, this presupposes that you have not only read and understood these values and principles (this is usually where it fails), but that you have also "internalized" them. Being agile means thinking and acting in a fundamentally value- and people-oriented way. This may sound like a banal platitude, but practically every "agile activity" can be traced back to this.
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 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 - regardless of which agile textbook they were taken from.
Accordingly, I would describe our agile level quite matter-of-factly as "medium". We are constantly evolving. For example, we have decided as a team (team autonomy, also an important principle!) that Scrum doesn't 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 to have 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 2 weeks in advance, but continuously. What is due today, what tomorrow, what next week? What is the big goal for this quarter? We have also changed our traditional review date. We do reviews in the team on an ongoing basis, just like planning - we can also get very technical. Nevertheless, we have decided to keep our old review date, but we now carry it out 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, coherent blocks of topics what we have done, what our goals are and where we want to go with it. In short: how we intend to create real value with our work. Of course, the format is intended to invite discussion and criticism. We are very grateful for feedback and would like to discover potential problems at an early stage (see manifesto!).
Robert Stelzmann: