Im letzten Artikel findet man einen Überblick darüber, was ich unter Produktivität in Softwareentwicklungsteams verstehe und welche Faktoren Einfluss auf diese haben können. Im Folgenden gehe ich auf meine Erkenntnisse in Hinblick auf die Umsetzung agiler Vorgehensmodelle näher ein.

1. Agiles Vorgehen

Agile Methoden sind mittlerweile sehr verbreitet und versprechen effiziente Softwareentwicklung. Sich für diese Vorgehensweise zu entscheiden, halte ich auch für sehr schlau. Was ich aber ebenso beobachte, sich “agil” auf die Fahnen zu heften, heißt nicht notwendigerweise agile Methoden auch sauber umzusetzen. Wie viele Arten von “Scrum” wird es in der Praxis tatsächlich geben?

• “Wir machen jetzt Scrum! Wir stellen uns jeden Morgen zusammen und reden miteinander!”
• “Scrum Master? Brauchen wir nicht!”
• “Die Retrospektive ist bei uns nicht wichtig. Die lassen wir aus.”
• “Bei uns ist der Product Owner auch der Scrum Master.”
• “Bei uns gibt es mehr POs als EntwicklerInnen.”

Sich bei der Umsetzung von agilen Vorgehensmodellen nicht selbst anzulügen, ist meines Erachtens nach ein wichtige Faktor, um in den versprochenen Genuss der effizienten und kundenorientierten Softwareentwicklung zu kommen. Auch wenn die Umstellung auf agile Softwareentwicklung einmal geglückt ist und man vorbildhaft darin ist, heißt das nicht, dass sich nicht auch blinde Flecken einschleichen. Nach über 10 Jahre Scrum stelle ich gerade wieder fest, wie wichtig es ist, die angewandten Methoden und Prozesse regelmäßig zu betrachten, radikal ehrlich zu sein um festzustellen, ob man sich etwas schönredet, was eigentlich schon längst verbessert gehört. Ein Blick von Außen durch Externe, neue MitarbeiterInnen oder einem guten Scrum Master kann hier viel Gutes leisten. Verschläft man das allerdings, kann so manche Unausgewogenheit Auswirkungen auf die Produktivität haben.

Abweichungen reflektieren

Abweichungen vom Bilderbuch-Scrum gehören begründet und auch in regelmäßigen Abständen reflektiert, ob diese tatsächlich aufgrund der Projektsituation noch notwendig sind.

• Gibt es Meetings, die aus irgendwelchen Gründen nicht (mehr) durchgeführt werden?
• Gibt es eine(n) definierte(n) Scrum-Master(in)?
• Gibt es eine(n) Product Owner(in), der/die die Interessen aller Stakeholder sammelt, priorisiert und den Überblick behält?
• Wird der Backlog gepflegt? Von wem wird der Backlog gepflegt?

Diese Fragen hören sich banal an, doch sieht die Realität einfach anders aus. Ein Beispiel aus der Praxis: Aus zeitlichen Gründen sind die Feinplanung am Anfang des Sprints aber auch regelmäßige Retrospektiven innerhalb des Teams zu kurz gekommen. Gerade aber durch die Corona-bedingte Homeoffice Situation haben wir im Team gemerkt, wie wichtig diese Meetings sind, da es sonst über kurz oder lang zu Abstimmungsproblemen und unklaren Verantwortlichkeiten kommt.

Größe des Scrum-Teams

Auch ein Scrum-Team verändert sich mit der Zeit. Irgendwann kann ein Team eine Größe erreichen, in dem zu viele Kommunikationslinien entstehen und die Zusammenarbeit inneffizient wird. Was hier eine sinnvolle Größe ist, da sind mir schon verschiedene Angaben untergekommen wie “ein Scrum-Team hat 7 (+/- 2) MitarbeiterInnen” oder “maximal 12 Teammitglieder”. Hier gilt es das Team, die Mitglieder und die Projektorganisation aufmerksam zu beobachten und wenn nötig, Anpassungen der Organisationsstruktur vorzunehmen.

Meetings

Die vorgegebenen Meetings der gewählten Methodik sollten eingehalten und effizient gestaltet werden:

• Saubere und effiziente Planungs-Meetings (z.B. Vorbereitung von Backlogpunkten, Feinplanungen in kleineren Runden bei sehr großen Scrum-Teams).
• Retrospektiven auch tatsächlich nutzen, um zu lernen und Verbesserungspotenziale zu identifizieren.
• Auf die Länge von Daily Scrums achten, aber auch auf die Einhaltung dieser.

Klare Projektziele, klare Anforderungen und klare Prioritäten

Sind über einen längeren Zeitraum Ziel(e) und Prioritäten nicht klar, kann sich das sehr negativ auf die Produktivität auswirken und im schlimmsten Fall macht das Team irgendwas, aber nicht das, was am Ende von den KundInnen benötigt wird.

Um produktiv Kundennutzen zu generieren, muss für alle klar sein, wohin das Schiff fährt und welches Ziel angesteuert wird. Die konkreten Anforderungen definieren, was dazu notwendig ist und die Prioritäten machen es möglich, diese effizient in der benötigten Reihenfolge abzuarbeiten. Zu jedem Zeitpunkt sollte dem Team bekannt sein was als Nächstes zu tun ist, um dem Ziel näher zu kommen!

Das heißt nicht, dass das gesamte Projekt bis ins Detail durchgeplant sein soll, sonst wäre es keine agile Vorgehensweise sondern ein Wasserfallmodell. Man muss nicht den gesamten Weg bis zum Ziel kennen, aber die nächsten Schritten müssen bekannt und in Form klarer Anforderungen und Prioritäten definiert sein.

Wenn ich das so schreibe, klingt das in der Theorie auch recht schön. Nun habe ich die Erfahrung gemacht, dass bei neuen Projekten mit neuen Prozessen und Technologien die nächsten Schritte nicht immer ganz “klar” definierbar sind. Das erste mal eine Microservice-Architektur für eine Produktlandschaft zu entwerfen, die ersten Microservices mit Cloud-Komponenten betreiben, die erste Deployment-Pipeline einrichten, die ersten UIs designen, … Da sind die nächsten Schritte nicht immer soooo klar. In solchen Phasen entstehen sehr schwammige und grobe Anforderungen in einem Sprint, die eher Fragestellungen gleichen wie “Herausfinden, wie man eine Deployment-Pipeline einrichtet” oder “Microservices schneiden”. Sowas lässt sich anfangs nicht vermeiden. An diesem Punkt ist es wichtig, Antworten zu bekommen um herauszufinden, was überhaupt die nächsten Schritte sein müssen, um später den KundInnennutzen befriedigen zu können. Hierbei ist darauf Acht zu geben, dass diese Phase nur vorübergehend besteht und nicht zum Normalzustand wird! Um aus dieser Phase herauszukommen hilft es, sich selbst, POs und EntwicklerInnen bei der Definition von Backlog- und Sprint-Backlogeinträgen immer wieder zu ermutigen, so klar wie möglich die Ziele und Schritte zu formulieren, seien sie auch noch so klein. Das bedarf etwas Übung und funktioniert auch nicht immer auf Anhieb - es ist aber meiner Meinung nach wichtig, daran zu arbeiten.

Zusammenfassung

Um Produktivität zu steigern und Problemfelder zu identifizieren ist es hilfreich, das Vorgehensmodell zu betrachten. Agile Methoden versprechen effiziente Softwareentwicklung. Jedoch können sich bewusst oder unbewusst Abweichungen einschleichen, die Zeit und Ressourcen kosten, die anderweitig genutzt werden könnten. Eine ehrlicher, kritischer Blick und Mut den Kurs zu korrigieren kann hier nur von Vorteil sein.

Fortsetzung im Teil 3 der Artikelserie: Optimierungspotenziale identifizieren