In meinem vorherigen Beitrag habe ich die Diskussion über ungünstige Gewohnheiten innerhalb eines Scrum-Teams eröffnet, die letztendlich früher oder später zu Schwierigkeiten bei der Auslieferung führen können. In diesem Artikel möchte ich diese Thematik weiter ausführen und mich nun auf die operativen Abläufe innerhalb des Teams konzentrieren.
Diese sind genauso wichtig wie die fachliche Kompetenz des Teams. Selbst wenn die einzelnen Teammitglieder überragend für ihre jeweiligen Aufgaben qualifiziert sind, gibt es dennoch Bereiche, die ihre Bemühungen um Perfektion zunichtemachen können. Dies ist weniger ihre eigene Schuld, sondern eher die direkte Verantwortung des Projektmanagements, das Team mit zweckmäßigen Prozessen zu unterstützen und ihm klare Ziele und planbare Aktivitäten zu ermöglichen.
Ein Team mit stark spezialisierten, abgegrenzten Kompetenzen
Angenommen, das Team besteht aus hochqualifizierten Entwicklern, die selbstständig arbeiten können, ihre Zusagen einhalten und die vereinbarten Sprintinhalte termingerecht liefern. Selbst in einem solchen idealen Szenario (das ohnehin höchst unwahrscheinlich ist) wird das Team Probleme haben, mit den immer größer werdenden Aufgaben im Backlog Schritt zu halten, wenn die Kompetenzen der Teammitglieder strikt voneinander getrennt sind.
Einige Beispiele
- Das Team hat ein oder zwei DevOps-Spezialisten, die Änderungen an den Automatisierungspipelines vornehmen oder sich um die Dienste innerhalb der Plattform kümmern. Der Rest des Teams hat davon jedoch keine Ahnung. Die Diskussion solcher Aufgaben bei Scrum-Meetings wie den Refinements würde dann für die Mehrheit des Teams zur Zeitverschwendung, da sie ohne Beteiligung daran teilnehmen. Umgekehrt wäre der DevOps-Entwickler nicht an den übrigen funktionalen Aufgaben interessiert, und seine Meetingzeit wäre ebenfalls meist verschwendet.
- Es gibt nur einen einzigen Datenbankexperten für das gesamte Team. Abhängig von der Komplexität und Nutzung der Datenlösungen im System, das das Team entwickelt, ist diese Person möglicherweise ständig mit Aufgaben überlastet, die sie nicht rechtzeitig abschließen kann, insbesondere wenn man ihre Prioritäten berücksichtigt. Schlimmer noch, andere Aufgaben müssen ebenfalls warten, da sie von den Datenbankaufgaben abhängig sind.
- Wenn ein bestimmtes Produkt hauptsächlich auf die Backend-Entwicklung ausgerichtet ist, ist der einzige Frontend-Entwickler für alle Fälle zuständig (da von Zeit zu Zeit auch in der UI-Anwendung einige kleinere Änderungen erforderlich sind). Auch in diesem Fall sind die meisten Scrum-Meetings für dieses Teammitglied Zeitverschwendung, da sein Wissen auf das Frontend beschränkt ist und nichts anderes zählt.
Das Fazit
In allen oben genannten Fällen verschwenden die Mitarbeiter entweder ihre Zeit oder sind nicht in der Lage, den Rückstand aufzuholen. Sie hindern den Rest des Teams daran, mit der Arbeit an den nächsten Aufgaben zu beginnen, oder sie verringern die Gesamteffizienz des Scrum-Teams, weil während des Sprints zu viel Zeit ungenutzt bleibt.
Das Team hat jedoch immer noch die gleiche Anzahl von Entwicklern. Von außen ist nicht erkennbar (und soll auch nicht offengelegt werden), dass die Teammitglieder einige Aufgaben nicht annehmen können, weil sie zu stark auf bestimmte Kompetenzen fokussiert sind. Sie können anderen Teammitgliedern bei den Aufgaben nicht helfen, selbst wenn ihre Kapazität dies erlauben würde und die Prioritäten der Aufgaben es auch zulassen würden.
Für den Product Owner ist es sogar schwierig, sinnvolle Sprintinhalte für das Team zusammenzustellen, da er immer berücksichtigen muss, wie viele Personen an jeder einzelnen Aufgabe arbeiten können und ob es sinnvoll ist, mehrere ähnliche Aufgaben gleichzeitig in den Sprint zu ziehen, da die Kapazität des Teams irgendwann ausgeschöpft ist, selbst wenn es Mitarbeiter gibt, die an diesen Aufgaben arbeiten könnten, aber nicht die nötigen Fähigkeiten dazu haben.
Die Lösung des Dilemmas
Dies ist ein Dilemma, das gelöst werden muss, und Projektmanager müssen sich bewusst sein, welchen Weg sie wählen möchten. Im Wesentlichen besteht eine Wahl zwischen:
- Mehreren Full-Stack-Entwicklern, die an einer breiteren Palette von Aufgaben arbeiten können, aber in vielen Themen keine Spezialisten sind. Sie können also weit, aber nicht tief gehen. Die Auslieferung kann dann schnell voranschreiten, aber die Qualität kann darunter leiden.
- Spezialisten für jede Technologie, aber dann die Einschränkungen akzeptieren und härter an besser zugeschnittenen Sprintinhalten arbeiten. Die Mitarbeiter können dann in die Tiefe gehen und qualitativ hochwertige Ergebnisse erzielen, aber die Aufgaben müssen nacheinander angegangen werden, was die Auslieferungszeit verlängert.
Ein schwacher Product Owner
Dies ist definitionsgemäß nicht unbedingt ein „Prozessproblem“, aber ich behandle es so, weil die Erstellung von soliden Aufgaben als Prozess verstanden werden kann, den das Team unbedingt beherrschen sollte und der mit dem Entwicklungsteam kompatibel ist.
Mit „schwach“ meine ich nicht zwangsläufig das Wissensniveau einer Person, sondern die Fähigkeit des Product Owners, dem Team Aufgaben zu liefern, die Entwickler verstehen und die aus der Perspektive der Produkt-Roadmap einen klaren Sinn ergeben. Beide Aspekte sind sehr wichtig für ein erfolgreiches Scrum-Team.
Wenn Aufgaben Details fehlen, damit Entwickler den Zweck, den funktionalen Wert oder die technischen Erwartungen klar verstehen können, können im Wesentlichen zwei Szenarien eintreten:
- Entwickler bauen etwas anderes als das, was der Product Owner eigentlich wollte. Dies ist oft schwer während des Sprints selbst zu erkennen, da der Product Owner meist keine Möglichkeit hat, den Fortschritt der Aufgaben auf einer so detaillierten Ebene zu verfolgen und einfach erwartet, dass die Sache (wie von Zauberhand) funktionieren wird.
- Entwickler werden zu viel Zeit damit verbringen, die Aufgaben zu klären und sie immer wieder zu diskutieren, anstatt mit der Entwicklung zu beginnen. Dies führt zu vielen zusätzlichen Gesprächen, wiederholten Abstimmungen und der Verlagerung der Arbeit in die späte Sprintphase. Irgendwann können die ursprünglichen Schätzungen für die Aufgaben nicht mehr als korrekt betrachtet werden, die Aufgaben können nicht innerhalb des Sprints abgeschlossen werden und müssen in die nächsten Sprints verschoben werden. Im schlimmsten Fall wiederholt sich diese Situation in den folgenden Sprints.
Zeit zur Selbstreflexion
Es ist oft schwer einzugestehen, aber der Product Owner sollte sich die Zeit für eine Selbstreflexion nehmen, die erstellten Backlog-Aufgaben ansehen und diese mit der Produkt-Roadmap-Vision vergleichen, um sicherzustellen, dass es noch eine sinnvolle Verbindung zwischen den beiden gibt – falls überhaupt eine Roadmap existiert. Wenn nicht, ist dies der erste Punkt, der gelöst werden muss. Manchmal besteht die Lösung darin, zuzugeben, dass sich der Product Owner zu weit vom Team und seinen Zielen entfernt hat.
In einem solchen Fall muss der Product Owner Teil der Lösung sein. Es könnte eine gute Option sein, einen qualifizierten Business Analysten ins Team zu holen, der sich stärker auf die Teamaufgaben als auf die geschäftlichen Inhalte konzentriert (dafür haben wir in diesem Fall bereits einen Product Owner), selbst wenn dies die Gesamtkosten des Teams erhöht.
Testabläufe ohne festgelegten Zeitplan
Was passiert, wenn die Testaktivitäten innerhalb eines Scrum-Sprints nicht an einen bestimmten Zeitplan gebunden sind?
Auf den ersten Blick mag das wie ein positiver Aspekt für ein agiles/Scrum-Team wirken. Flexibilität ist immer willkommen und klingt gut, wenn sie nach außen kommuniziert wird.
Meine Erfahrung zeigt, dass das Ergebnis dieser Freiheit eher Chaos als Flexibilität ist. Das bedeutet nicht, dass die Lösung darin bestehen sollte, „Wasserfälle innerhalb des Sprints“ mit dedizierten Testphasen zu schaffen, die unmittelbar nach Abschluss der Entwicklung folgen. Dies wäre keineswegs der richtige Ansatz. Sie können mehr darüber in meinen Beiträgen zur Scrum-Teststrategie und zum agilen Testlebenszyklus lesen.
Wir können durchaus eine gewisse Flexibilität zulassen und den Testplan so wählen, dass er am besten zum aktuellen Entwicklungsteam und den spezifischen Produkteigenschaften passt, die das Team liefert. Es gibt jedoch zwei Hauptziele, die durch diese Wahl erreicht werden sollten:
Wenn diese Bedingungen erfüllt sind, wird sich das Team auf natürliche Weise an den Anpassungsprozess anpassen, und der Lieferplan wird nicht durch ungeplante, verlängerte Testaktivitäten beeinträchtigt.
Letztlich ist ein zuverlässiger und planbarer Sprint-Release am wichtigsten, was mich zum letzten Punkt dieses Beitrags führt.
Ein undefinierter Freigabeprozess
Eigentlich sollte dies für jedes Scrum-Team eine Selbstverständlichkeit sein. Merkwürdigerweise ist es jedoch auch einer der am meisten unterschätzten Prozesse.
Oftmals sagt ein Scrum-Team lediglich, dass die Freigabe nach jedem Sprint erfolgen wird, ohne dass dies durch einen soliden Prozess untermauert wird. In der Realität führt dies dann zu einer Reihe von chaotischen, unvorhersehbaren Aktivitäten während der Freigabezeit. Plötzlich sind alle mit „Release-Aufgaben“ beschäftigt, und niemand kann sich auf die Weiterentwicklung neuer Sprint-Aufgaben konzentrieren. Die Sprint-Metriken sind beeinträchtigt, und die Freigabe wirkt aus der Sicht Dritter (meistens des Kunden) wie eine zufällige, unvorhersehbare Aktivität.
Die Teammitglieder sind so stark auf das Backlog, die Sprintinhalte, die Entwicklung, das Testen und schließlich die Präsentation der Ergebnisse fokussiert, dass sie vergessen, dass der nächste Sprint bereits läuft, sobald sie damit fertig sind, und sie somit bereits Zeit verlieren.
Die Suche nach einem guten Zeitpunkt für die Freigabe
Wann genau sollte das Team also die eigentliche Freigabe für die Produktion durchführen? Schließlich ist dies das einzig Wichtige.
Die Antwort auf diese Frage liegt im Prozess, vorausgesetzt, es gibt einen. Es hängt ab von:
- der Komplexität der Inhalte, die das Team in den Sprints erstellt,
- der Dauer eines Sprints,
- der Anzahl der betroffenen Komponenten im System,
- der Anzahl der Personen, die die Änderungen nutzen und benötigen,
Es sollte ein wiederholbarer Freigabeprozess eingerichtet und in Zukunft eingehalten werden. Die genauen Regeln dieses Prozesses können wiederum flexibel festgelegt werden. Aber wie bei den Testaktivitäten macht es eine feste Gewohnheit, die planbar ist und für bestimmte Tage in der Zukunft eingeplant ist, zu etwas, worauf man sich verlassen kann.
Mögliche Optionen
Die möglichen Formen eines solchen Prozesses könnten eine der folgenden oder auch andere sein:
- Abschluss des Testens der Funktionen aus dem aktuellen Sprint während des folgenden Sprints und Veröffentlichung der Inhalte am Ende dieses Sprints (nach Abschluss der Tests). Dies bedeutet, dass jede Version keine Inhalte aus dem unmittelbar vorherigen Sprint enthalten wird, sondern Aufgaben aus den beiden vorangegangenen Sprints.
- Der letzte Sprint vor der Veröffentlichung dient immer dem Testen der Inhalte aus den beiden vorherigen Sprints.
- Dies bedeutet nicht, dass die Entwicklung während des „Test-Sprints“ gestoppt wird. Es bedeutet lediglich, dass die in diesem Test-Sprint entwickelten Inhalte noch nicht in die nächste Version übernommen werden.
- Wenn bereits genügend automatisierte Testaktivitäten vorhanden sind, sollte versucht werden, die Veröffentlichung nach dem Ende jedes Sprints durchzuführen. Dies muss dann ein sehr strenger Prozess sein, bei dem sich engagierte Mitarbeiter zu 100 % auf diese wenigen Tage konzentrieren. Der Rest des Entwicklungsteams sollte dadurch jedoch in keiner Weise beeinträchtigt werden.
- Es kann auch gewählt werden, einmal pro Monat oder einmal alle N Monate zu veröffentlichen, vor allem wenn dies aus Sicht der Endbenutzer akzeptabel ist. Dies erhöht den Aufwand auf der Testseite für jeden Sprint (da der Inhalt für jede Version größer wird). Andererseits führt dies im Laufe der Zeit zu weniger wiederholten Aktivitäten, was für das Team von Vorteil sein kann. In der Folge kann das Team zwischen den Veröffentlichungen mehr neue Funktionen erstellen, obwohl die Funktionen tatsächlich langsamer in die Produktion gehen.
Aber wie bereits mehrfach erwähnt, ist es nicht so wichtig, welcher dieser Prozesse ausgewählt wird. Viel wichtiger ist, wie gut sich das Team an diesen Prozess hält und ihn zu einer festen Gewohnheit macht.
Sie können auch diesen Leitfaden zum Release-Management-Prozess und den Praktiken lesen: Release-Management-Prozess und Praktiken.