Dienstag, 9. August 2016

Zwischenbericht nach einem Jahr agiler Softwareentwicklung mit Scrum

Vor etwas mehr als einem Jahr starteten wir mit dem Sprint 0 in die agile Welt. Inzwischen haben wir fast 30 Sprints hinter uns und eine Menge Erfahrung gesammelt. Meine Rolle als Scrum Master hat sich als eine tolle Herausforderung bewiesen, und sie ist es immer noch. Doch hat sich wirklich alles wie gewünscht zum Besseren geändert?

Natürlich hängt die Beantwortung dieser Frage von den Erwartungen ab. Wenn die Art und Weise, wie man in der Softwareentwicklung vorgeht, derart stark angepasst wird, sind die Erwartungen entsprechend hoch. Doch die Umstellung zu Scrum hat sehr deutliche Verbesserungen mit sich gebracht, die ich in den folgenden Zeilen erläutern möchte.

Sehr hohe Transparenz


Durch die tägliche Abstimmung (Daily Scrum) weiß jeder genau, woran der andere gerade arbeitet und an welcher Stelle optimal unterstützt werden kann. Außerdem wird jede User Story und jeder Defect in kleinere Häppchen (Tasks) unterteilt, die sich jeder greifen und bearbeiten kann. Der Status dieser Tasks ist für jeden offen einsehbar und kann daran ablesen, wie weit die Story oder der Defect fortgeschritten ist.

Zeitangaben für Lieferung von Funktionen sehr genau


Dadurch, dass das Team alle Aufgaben einschätzen und bewerten muss, bekommt der Product Owner mit jedem Sprint zuverlässigere Aussagen darüber, ob und wann eine Funktion fertiggestellt sein kann. Die Dauer zu Erledigung einer User Story kann über die Tasks, aber auch über die eingeschätzte Komplexität abgelesen werden, aus der die benötigte Zeit abgeleitet werden kann. Auch wenn diese beiden Werte unabhängig voneinander angegeben werden, ist eine entsprechende Tendenz durchaus erkennbar.

Offenlegung von Problemen


Was vor der Einführung von Scrum stets hingenommen, toleriert oder ignoriert wurde, kommt jetzt deutlicher als je zuvor ans Tageslicht. Vor allem unlogische Abläufe, Zeitfresser, ungewünschte Abhängigkeiten oder ungewollte Leerläufe werden nun für jeden sichtbar und müssen vermieden werden. Auch wenn ein einzelner Mitarbeiter nicht weiterkommt wird das frühzeitig bekannt und es kann entsprechend reagiert werden.

Frühzeitige Erkenntnis von Lieferengpässen


Durch die stark erhöhte Kommunikation kann nun sehr früh erkannt werden, ob bestimmte Funktionen zu dem geplanten Datum fertig werden. Dazu ist natürlich ein stetiger Austausch zwischen dem Product Owner und dem Entwicklungsteam notwendig. Der Product Owner hat die Aufgabe, dem Team die Funktion fein zerstückelt in User Stories zur Verfügung zu stellen. Durch die Pflege dieser Stories kann dann früh der Bearbeitungsstand erkannt werden.

Stetige Verbesserung interner Abläufe


Mindestens einmal pro Sprint trifft sich das Team und geht gezielt auf Themen ein, die verbessert werden können (Retrospective). Meist wird der vergangene Sprint analysiert, was gut gelaufen ist und was verbessert werden könnte. Manchmal kommen aber auch übergreifende Punkte zur Sprache, z.B. die Verbesserung der Zusammenarbeit mit anderen Abteilungen, die keinen agilen Prinzipien folgen. Auch während eines Sprints ist das Ziel, interne Abläufe stets effizienter zu gestalten. Vor allem seit Jahren beständige Vorgehensweisen werden inzwischen hinterfragt und Verbesserungen durchgesetzt.

Durch hohen Testaufwand fehlerfreiere Software


Vor allem der Testaufwand von einzelnen User Stories und Defects ist deutlich angestiegen. Jegliche Testprozeduren wurden bereits mehrfach angepasst und es wurden viele Vereinbarungen getroffen, um eine möglichst abgedeckte und praxisnahe Testumgebung zu gestalten. Das Ergebnis ist eine bessere und fehlerfreiere Software als je zuvor.

Noch nicht die Produktivität wie vor der Einführung erreicht


Der einzige negative Punkt, der mir einfällt, ist dass die angestrebte Produktivität noch nicht erreicht wurde. Es wird noch nicht die Anzahl an abgeschlossenen Aufgaben erreicht wie vor der Einführung von Scrum. Doch das ist auch kein Wunder, da die Energie in andere Aufgaben gesteckt wurde, beispielsweise in den erhöhten Testaufwand. Zudem sind zwei Personen aus dem Team weggefallen, die in die Rollen des Product Owners und des Scrum Masters geschlüpft sind. Betrachtet man die Produktivität mit diesen Faktoren, arbeitet das Team effektiver als je zuvor.

Fazit


Sofern alle Nebenfaktoren passen (siehe auch mein Artikel Einführung von Scrum im Unternehmen) spricht nichts dagegen, Scrum einzuführen und anzuwenden. Die Arbeitsweise wird strukturierter und durchdachter, zudem werden auch lohnende Risiken eingegangen. Der Kunde bekommt früh seine bestellte Funktion und kann ebenso früh Rückmeldung geben. Alle Parteien können daher davon profitieren, wie es auch bei uns der Fall war. Ich bin auf das zweite Jahr mit Scrum gespannt!

Zusammenfassung


Positiv
  • Sehr hohe Transparenz
  • Zeitangaben für Lieferung von Funktionen sehr genau
  • Offenlegung von Problemen
  • Frühzeitige Erkenntnis von Lieferengpässen
  • Stetige Verbesserung interner Abläufe
  • Durch hohen Testaufwand fehlerfreiere Software

Negativ
  • Noch nicht die Produktivität wie vor der Einführung erreicht

Hinweis: Der Inhalt dieses Artikels stellt meine persönliche Meinung und nicht die meines Arbeitgebers dar. Ich spreche nicht für das Unternehmen, für das ich arbeite. Meine persönliche Meinung und Einschätzung kann von der Meinung meines Arbeitgebers oder meinen Kollegen abweichen und soll diese nicht beeinflussen.

Keine Kommentare:

Kommentar veröffentlichen