Agile Softwareentwicklung – ein Begriff, der in der Tech-Welt allgegenwärtig ist. Doch was bedeutet es wirklich, agil zu arbeiten? Und wie setzt man agile Prinzipien am besten in der Praxis um?

Wir haben uns mit Robert Stelzmann, Product Owner von weasl, zusammengesetzt und mit ihm über agile Softwareentwicklung gesprochen. Im Gespräch gibt er spannende Einblicke, wie das weasl Team arbeitet, und was Agilität mit der kontinuierlichen Weiterentwicklung unseres Werkerassistenzsystems zu tun hat.

Robert Stelzmann:

Ich würde die Frage vielleicht umdrehen: "Was ist Agilität nicht?" Klar, irgendwelche Wasserfälle implementieren, logisch. Genauso wenig agil ist es aber, ein verkrustetes Vorgehensmodell in ein Scrum-Korsett zu packen und dann zu hoffen, dass alles auf wundersame Weise gut wird.

Ich würde sagen, die einfachste - und vermutlich am wenigsten hilfreiche - Antwort ist: sich an die Werte und Prinzipien des agilen Manifests zu halten. Das setzt aber voraus, dass man diese Werte und Prinzipien nicht nur gelesen (daran scheitert es meistens schon) und verstanden, sondern eben auch "verinnerlicht" hat. Agil sein bedeutet, grundlegend wert- und menschenorientiert zu denken und zu handeln. Das mag nach einer banalen Plattitüde klingen, aber praktisch jede “agile Aktivität” lässt sich darauf zurückführen.

Robert Stelzmann:

Ich denke, das "unagilste", was man tun kann, ist zu behaupten (und noch schlimmer zu glauben), dass man "vollständig" agil ist. Dass man das Agilitäts-Game irgendwie durchgespielt hat. Ein wichtiger, wenn nicht DER wichtigste, Kerngedanke von Agilität ist das Streben nach Verbesserung. Dementsprechend kann eine "agile Reise" niemals abgeschlossen sein. Agilität bemisst sich definitiv nicht an der Menge der Rituale, die man durchführt - egal aus welchem agilen Lehrbuch sie übernommen wurden.

Dementsprechend würde ich unser agiles Niveau ganz nüchtern als "mittel" bezeichnen. Wir entwickeln uns fortlaufend weiter. Zum Beispiel haben wir als Team (Team-Autonomie, auch ein wichtiges Prinzip!) entschieden, dass Scrum für uns nicht gut funktioniert. Wir wollen einfach nicht "in Rastern" denken und arbeiten. Wir wollen fokussiert und "im Flow" bleiben. Wir wollen keine Wasserfälle haben - auch keine 2-Wochen-Sprint-Mini-Wasserfälle. Wir wollen kontinuierlich, mindestens täglich, releasen. Wir wollen schnell reagieren und adaptieren können. Dementsprechend haben wir unsere Arbeitsweise auf ein Kanban-orientiertes Vorgehen geändert.

Wir planen nicht 2 Wochen im Vorraus, sondern kontinuierlich. Was liegt heute an, was morgen, was nächste Woche? Was ist das große Ziel dieses Quartals? Wir haben auch unseren klassischen Review-Termin geändert. Reviews im Team machen wir analog zur Planung fortlaufend im Team - da darf es auch gerne sehr technisch werden. Dennoch haben wir uns entschieden unseren alten Review-Termin beizubehalten, nur führen wir den inzwischen mit der kompletten Firma und unseren Partnern durch.

Natürlich haben wir auch dieses Format kontinuierlich weiterentwickelt. Wir gehen nicht mehr Ticket für Ticket durch und diskutieren Implementierung und Auswirkung, sondern versuchen, in großen zusammenhängenden Themenblöcken zu erklären, was wir getan haben, was unsere Ziele sind und wo wir damit hin wollen. Kurz: wie wir gedenken, mit unserer Arbeit echten Wert zu schaffen. Natürlich soll das Format zum Diskutieren und Kritisieren einladen. Wir sind sehr dankbar für Feedback und möchten mögliche Probleme frühzeitig entdecken (siehe Manifest!).

Robert Stelzmann:

1. Lest das agile Manifest. Druckt euch die Werte/Prinzipien aus. Hängt sie auf, macht sie "allgegenwärtig". Beginnt euch kontinuierlich zu fragen: "Agieren wir just in diesem Moment gerade gemäß dieser Werte und Prinzipien?" Wenn nicht: Warum? Was wäre “agil”? Kommt ins tun!
2. Startet klein. Scrum ist beileibe nicht universell und immer perfekt. Aber: Es ist bekannt. Die meistens Entwickler und Entwicklerinnen haben ein grundlegendes Verständnis, wie Scrum funktioniert - es ist leicht, damit "ins Rollen" zu kommen. Arbeitet euch von hier aus vor: Seid transparent in euren Reviews, ladet eure Stakeholder ein. Liefert (mindestens) am Sprint-Ende ein Inkrement in guter Qualität. Klappt noch nicht? Dann investiert in technische Exzellenz: CI/CD, Testautomatisierung, usw.
3. Bleibt am Ball. Rückschläge sind normal. Es geht darum sich zu entwickeln - zu lernen. Nehmt die Retros ernst. Fragt euch immer wieder: Wie geht das besser? Und ganz wichtig: Geht den Problemen auf den Grund - 5-Why ist dafür zum Beispiel eine wunderbare Methodik. Denkt an das positive Menschenbild: Steht am Ende eurer Analyse ein einzelner Mensch oder eine Abteilung, seid ihr vermutlich nicht am Ende der Analyse - die Probleme liegen tiefer. Leitet umsetzbare Maßnahmen ab und setzt diese dann auch um! Ganz wichtig: Das betrifft alles! Produkt/Projekt, Technik, Organisation, Kultur - alles.