In meinem vorherigen Artikel habe ich die Diskussion über schlecht entwickelte Gewohnheiten innerhalb eines Scrum-Teams begonnen, die schließlich (früher oder später) zu einem Misserfolg bei der Lieferung führen werden. In diesem Artikel möchte ich dieses Thema noch einmal erweitern und mich nun auf funktionale Prozesse innerhalb des Teams konzentrieren.
Diese sind ebenso wichtig wie die fachliche Exzellenz des Teams. Selbst wenn die Mitarbeiter im Unternehmen für den Job, den sie abliefern werden, super qualifiziert sind, gibt es immer noch Bereiche, die ihre Bemühungen um Perfektion zunichte machen können. Und es wird nicht so sehr ihre Schuld sein, sondern die direkte Verantwortung für die Projektmanagemententscheidungen und ihre Fähigkeit, dem Team mit zweckdienlichen Prozessen zu dienen, um das Team mit klaren Absichten und vorhersehbaren Aktivitäten zu unterstützen.
Inhaltsverzeichnis
Hochgradig getrenntes Team mit unterschiedlichen Fähigkeiten
Stellen Sie sich vor, das Team hat kompetente Entwickler, die vollkommen unabhängig und in der Lage sind, ihre Versprechen zu halten und die vereinbarten Sprint-Inhalte pünktlich vor dem Ende des Sprints zu liefern. Selbst in einem so perfekten Szenario (was ohnehin höchst unwahrscheinlich ist) wird das Team Probleme haben, mit den (immer größer werdenden) Backlog-Funktionen Schritt zu halten, wenn die Fähigkeiten zwischen den Teammitgliedern strikt getrennt sind.
Wenige Beispiele
- Das Team verfügt über 1 oder 2 DevOps-Ingenieure, die in der Lage sind, Änderungen an den automatisierten Pipelines vorzunehmen oder sich um die Dienste innerhalb der Plattform zu kümmern, aber der Rest des Teams hat keine Ahnung von solchen Dingen. Dann wird das Diskutieren dieser Geschichten bei Scrum-Zeremonien wie Verfeinerungen zu Zeitverschwendung für die Mehrheit des Teams führen, indem sie ohne Beteiligung an dem Meeting hängen und umgekehrt – der DevOps-Entwickler wird kein Interesse an den restlichen funktionsorientierten Geschichten haben und die Zeit auf dem Treffen wird auch meistens verschwendet.
- Es gibt einen einzigen Datenbankexperten für das gesamte Team. Abhängig von der Komplexität und Nutzung der Datenlösungen in dem System, das das Team entwickelt, ist diese Person möglicherweise ständig mit Geschichten überlastet, die sie nicht früh genug fertigstellen kann, insbesondere wenn sie ihre Prioritäten berücksichtigt. Schlimmer noch, andere Geschichten müssen ebenfalls warten, da diese von der Datenquelle der Datenbankgeschichten 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 da (weil von Zeit zu Zeit ohnehin einige kleine Änderungen sogar in der UI-Anwendung erforderlich sind). Auch in diesem Fall sind die meisten Scrum-Zeremonien für dieses Teammitglied Zeitverschwendung, da sein Wissen nur auf das Frontend beschränkt ist und nichts anderes zählt.
Wo es endet
In allen oben genannten Fällen verschwenden die Mitarbeiter entweder ihre Zeit oder sind nicht in der Lage, den Nachholbedarf aufzuholen. Sie hindern den Rest des Teams daran, mit der Arbeit an den nächsten Storys zu beginnen, oder sie verringern effektiv die Gesamteffektivität des Scrum-Teams, weil im Sprint zu viel Zeit ungenutzt bleibt.
Das Team hat jedoch immer noch diese Anzahl von Entwicklern. Von außen ist es nicht sichtbar (und will auch nicht bloßgestellt werden), dass die Leute im Team einige Geschichten nicht annehmen können, nur weil sie zu sehr auf bestimmte Fähigkeiten ausgerichtet sind. Sie können den anderen Teammitgliedern also nicht mit den Stories helfen, auch wenn ihre Kapazität das zulassen würde und die Prioritäten für Stories es auch begünstigen würden.
Für den Product Owner ist es sogar schwierig, sinnvolle Sprint-Inhalte für das Team zusammenzustellen, da der Product Owner immer im Hinterkopf behalten muss, wie viele Personen an jeder einzelnen Story arbeiten können und ob mehr ähnliche Stories gleichzeitig in den Sprint gebracht werden , schließlich ist die Kapazität des Teams ausgeschöpft, auch wenn es zwar Leute gibt, die möglicherweise an diesen Geschichten arbeiten könnten, aber nicht die Fähigkeiten haben, damit anzufangen.
Lösung des Dilemmas
Es ist ein Dilemma, das gelöst werden muss, und Projektmanager müssen sich bewusst sein, welchen Weg sie wählen müssen. Konkret eine Auswahl zwischen:
- Viele Full-Stack-Entwickler zu haben, die in der Lage sind, an breiteren Inhalten zu arbeiten, aber nicht wirklich Experten in vielen Themen sind. Sie können also weit gehen, aber nicht tief. Dann kann die Lieferung schnell voranschreiten, aber die Qualität kann darunter leiden.
- Für jede Technologie dedizierte Experten zu haben, aber dann die Einschränkungen zu akzeptieren und härter an besser angepassten Printinhalten zu arbeiten. Dann können die Leute in die Tiefe gehen und großartige Geschichten bauen, aber die Geschichten müssen nacheinander angegangen werden, wodurch es länger dauert, sie zu liefern.
Schwacher Product Owner
Dies ist per Definition nicht unbedingt ein „Prozessproblem“, aber ich behandle es einfach so, weil die Erstellung solider Geschichten als ein Prozess verstanden werden kann, den das Team felsenfest und kompatibel mit dem Entwicklungsteam haben sollte.
Was ich mit schwach meine, muss sich nicht auf die Wissenseigenschaft einer Person beziehen, sondern auf die Fähigkeit des Product Owners, dem Team Geschichten zu liefern, die Entwickler verstehen können und die aus der Perspektive der Produkt-Roadmap einen klaren Sinn ergeben. Beides ist sehr wichtig für ein erfolgreiches Scrum-Team.
Wenn den Geschichten 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. Es ist sogar schwer, während des Sprints selbst zu erkennen, da der Product Owner meistens nicht die Möglichkeit hatte, den Fortschritt der Stories auf einer so detaillierten Ebene zu verfolgen, und meistens wird PO einfach erwarten, dass die Sache (magisch) passieren wird.
- Entwickler werden viel zu viel Zeit damit verbringen, die Geschichten zu klären und sie immer wieder zu diskutieren, anstatt mit dem Aufbau zu beginnen. Das bringt viele zusätzliche Anrufe, wiederholte Absprachen und das Verschieben der Arbeit in die späte Sprintphase mit sich. Es erreicht einen Punkt, an dem die ursprünglichen Schätzungen für die Stories nicht mehr als genau angesehen werden können und die Stories nicht innerhalb des Sprints abgeschlossen werden können und in die nächsten Sprints rollen. Im schlimmsten Fall wiederholt sich die Situation dann in den nachfolgenden Sprints.
Zeit für Selbstreflexion
Es ist normalerweise schwer zuzugeben, aber der Product Owner sollte die Zeit zum Nachdenken finden, sich die erstellten Backlog-Geschichten ansehen und sie schließlich mit der Produkt-Roadmap-Vision vergleichen, wenn es noch eine sinnvolle Verbindung zwischen diesen beiden gibt – wenn es eine Roadmap gibt überhaupt. Wenn nicht, ist das das erste, was zu lösen ist. Manchmal besteht die Lösung darin, zuzugeben, dass der Product Owner zu weit vom Team und zu weit vom eigenen Ziel entfernt ist.
In einem solchen Fall ist der Product Owner Teil des Teams zu lösen. Nicht zuletzt könnte es eine gute Option sein, einen soliden Business Analyst ins Team zu holen, der sich eher an den Inhalten des Teams als an den geschäftlichen Inhalten orientiert (dafür haben wir in diesem Fall bereits einen Product Owner), selbst für den Preis von erhöhte Gesamtkosten des Teams.
Testprozesse ohne festen Zeitplan
Was ist, wenn die Testaktivitäten innerhalb eines Scrum-Sprints nicht an einen konkreten Zeitplan gebunden sind?
Auf den ersten Blick mag das wie etwas Gutes aussehen, das wir uns für ein agiles / Scrum-Team wünschen. Flexibilität ist immer willkommen und klingt gut, wenn sie draußen präsentiert wird.
Meine Erfahrung zeigt, dass das Ergebnis dieser Freiheit eher Chaos als Flexibilität ist. Das bedeutet nicht, dass die Lösung dafür darin bestehen sollte, „Wasserfälle innerhalb des Sprints“ mit dedizierten Testphasen zu schaffen, die unmittelbar nach Abschluss der Entwicklung folgen. Dies ist in diesem Fall keineswegs der richtige Ansatz. Sie können mehr darüber in meinen Posts über die Scrum-Teststrategie und den agilen Testlebenszyklus lesen.
Wir können immer noch etwas Flexibilität zulassen und den Testplan so wählen, wie er für das aktuelle Entwicklungsteam und die gegebenen Produkteigenschaften, die das Team liefert, am besten geeignet erscheint. Es gibt jedoch zwei Hauptziele, die durch diese Wahl erreicht werden sollten:
Wenn diese Bedingungen erfüllt sind, passt sich das Team natürlich an den Anpassungsprozess an, und der Lieferplan wird nicht durch ungeplante verlängerte Testaktivitäten beeinträchtigt.
Was am Ende am wichtigsten ist, ist ein zuverlässiger und vorhersehbarer Sprint-Release, was mich zum letzten Punkt dieses Blogs führt.
Undefinierter Freigabeprozess
Nun, das ist für jedes Scrum-Team eine so offensichtliche Sache. Merkwürdigerweise ist es jedoch auch einer der am meisten unterschätzten Prozesse.
Sehr oft sagt ein Scrum-Team nur, dass die Freigabe nach jedem Sprint erfolgen wird, aber es wird nicht durch einen soliden Prozess unterstützt. Was dann in Wirklichkeit passiert, ist, dass während der Veröffentlichungszeit eine Menge chaotischer, unvorhersehbarer Aktivitäten auftreten werden. Plötzlich sind alle mit „Release Tasks“ beschäftigt und niemand kann sich darauf konzentrieren, neue Sprint Stories weiterzuentwickeln. Die Sprint-Metriken sind deaktiviert und die Freigabe sieht aus der Sicht der dritten Person (normalerweise des Kunden) wie eine zufällige, unvorhersehbare Aktivität aus.
Die Leute konzentrieren sich so sehr auf das Backlog, die Sprint-Inhalte, die Entwicklung, das Testen und schließlich die Präsentation der Ergebnisse, dass sie vergessen, dass, wenn sie mit all dem fertig sind, der nächste Sprint bereits läuft und sie bereits Zeit verlieren.
Auf der Suche nach einem guten Zeitpunkt für die Veröffentlichung
Wann genau sollte das Team also die eigentliche Freigabe für die Produktion vornehmen? Das einzig Wichtige, was am Ende zählt.
Die Antwort auf diese Frage liegt im Prozess, vorausgesetzt, Sie haben eine. Es hängt davon ab:
- die Komplexität der Inhalte, die das Team in den Sprints produziert,
- Dauer eines Sprints,
- Anzahl der betroffenen Komponenten im System
- die Anzahl der Personen, die die Änderungen nutzen und anfordern,
Ein wiederholter Freigabeprozess sollte eingerichtet und in Zukunft befolgt werden. Die genauen Regeln des Prozesses lassen sich wiederum flexibel definieren. Aber wie es bei Testaktivitäten ist, macht es eine felsenfeste Gewohnheit, die vorhersehbar und für konkrete Tage in der Zukunft geplant ist, zu etwas, auf das man sich verlassen und auf das man sich beziehen kann.
Auswahlmöglichkeiten
Die möglichen Formen eines solchen Prozesses könnten eine der folgenden oder andere sein:
- Schließen Sie das Testen der Funktionen aus dem aktuellen Sprint während des folgenden Sprints ab und veröffentlichen Sie den Inhalt am Ende dieses Sprints (nach Abschluss des Tests). Das bedeutet, dass jede Version keine Inhalte aus dem allerletzten Sprint enthalten wird, aber Geschichten aus den 2 Sprints davor enthalten wird.
- Der letzte Sprint vor der Veröffentlichung dient immer dem Testen der Inhalte aus den beiden vorangegangenen Sprints.
- Dies bedeutet nicht, dass die Entwicklung während des „Testsprints“ gestoppt wird; es heißt nur, dass die in diesem Test-Sprint entwickelten Inhalte noch nicht in die nächste Version aufgenommen werden.
- Wenn bereits genügend automatisierte Testaktivitäten vorhanden sind, bemühen Sie sich, die Veröffentlichung nach dem Ende jedes Sprints durchzuführen. Dann muss dies ein sehr strenger Prozess sein, bei dem engagierte Leute sich zu 100 % auf diese wenigen Tage konzentrieren. Es sollte den Rest des Entwicklungsteams dennoch in keiner Weise betreffen.
- Sie können auch wählen, ob Sie einmal pro Monat oder einmal pro N Monate veröffentlichen möchten, hauptsächlich wenn dies aus Sicht der Endbenutzer in Ordnung ist. Dies erhöht den Aufwand auf der Testseite für jeden Sprint (da der Inhalt für jede Version größer wird). Auf der anderen Seite bedeutet dies im Laufe der Zeit weniger wiederholte Aktivitäten, was in diesem Fall Vorteile für das Team haben kann. Infolgedessen kann es dem Team ermöglichen, zwischen den Veröffentlichungen mehr neue Funktionen zu erstellen, obwohl die Funktionen tatsächlich mit einer langsameren Kadenz in die Produktion kommen.
Aber wie bereits ein paar Mal zuvor erwähnt, ist es nicht so wichtig, welcher dieser Prozesse ausgewählt wird. Viel wichtiger ist, wie gut sich das Team dann an diesen Prozess hält und ihn zu einer hartnäckigen Gewohnheit macht.
Sie können auch diesen Leitfaden zum Release-Management-Prozess und zu den Praktiken lesen.