4 ungesunde Prozesse, die Ihren Sprint ruinieren können

In meinem letzten Artikel habe ich die Diskussion über schlecht entwickelte Gewohnheiten innerhalb eines Scrum-Teams begonnen, die früher oder später zu einem Scheitern bei der Lieferung führen. In diesem Artikel möchte ich dieses Thema noch einmal ausweiten und mich nun auf die funktionalen Prozesse innerhalb des Teams konzentrieren.

Diese sind ähnlich wichtig wie die technische Exzellenz des Teams. Selbst wenn die Mitarbeiter im Team für die Aufgabe, die sie erledigen sollen, bestens ausgebildet sind, gibt es immer noch Bereiche, die ihr Streben nach Perfektion zunichte machen können. Und es ist nicht so sehr ihre Schuld, sondern vielmehr die direkte Verantwortung für die Entscheidungen des Projektmanagements und dessen Fähigkeit, das Team mit zweckmäßigen Prozessen zu versorgen, um das Team mit klaren Absichten und vorhersehbaren Aktivitäten zu unterstützen.

Stark segregiertes Team mit unterschiedlichen Qualifikationen

Stellen Sie sich vor, das Team verfügt über fähige Entwickler, die vollkommen unabhängig sind und die Fähigkeit haben, ihre Versprechen einzuhalten und die vereinbarten Sprint-Inhalte rechtzeitig vor Ende des Sprints zu liefern. Selbst in einem solchen perfekten Szenario (das ohnehin höchst unwahrscheinlich ist) wird das Team Probleme haben, mit den (ständig wachsenden) Backlog-Funktionen Schritt zu halten, wenn die Fähigkeiten der Teammitglieder strikt voneinander getrennt sind.

Wenige Beispiele

• Das Team hat 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. Die Diskussion dieser Stories in Scrum-Zeremonien, wie z.B. Verfeinerungen, führt dann dazu, dass der Großteil des Teams seine Zeit vergeudet, indem er ohne jegliche Beteiligung in der Besprechung verweilt, und umgekehrt – der DevOps-Entwickler hat kein Interesse an den restlichen funktionsorientierten Stories, und die Zeit in der Besprechung ist ebenfalls verschwendet.
• Es gibt einen einzigen Datenbankexperten für das gesamte Team. Je nach Komplexität und Verwendung der Datenlösungen in dem System, das das Team entwickelt, kann diese Person ständig mit Stories überlastet sein, die sie nicht schnell genug abschließen kann, insbesondere wenn sie ihre Prioritäten berücksichtigt. Schlimmer noch, andere Stories müssen ebenfalls warten, da diese von der Datenquelle abhängig sind, die von den Datenbank-Stories bereitgestellt wird.
• Wenn ein bestimmtes Produkt hauptsächlich auf die Backend-Entwicklung ausgerichtet ist, ist der einzige Front-End-Entwickler nur für den Fall der Fälle da (denn von Zeit zu Zeit sind auch in der UI-Anwendung einige kleine Änderungen erforderlich). Auch in diesem Fall sind die meisten Scrum-Zeremonien für dieses Teammitglied reine Zeitverschwendung, da sich sein Wissen nur auf das Frontend beschränkt und alles andere unwichtig ist.

Wo es endet

In jedem der oben genannten Fälle ist das Ergebnis, dass die Mitarbeiter entweder ihre Zeit vergeuden oder aber nicht in der Lage sind, den Rückstand aufzuholen. Sie hindern den Rest des Teams daran, mit der Arbeit an den nächsten Stories zu beginnen, oder sie verringern effektiv die Gesamteffektivität des Scrum-Teams, weil zu viel Zeit innerhalb des Sprints ungenutzt bleibt.

Das Team hat aber immer noch diese Anzahl von Entwicklern. Von außen ist es nicht sichtbar (auch wenn man es nicht wahrhaben will), dass die Leute im Team nicht in der Lage sind, einige Stories zu übernehmen, weil sie zu sehr auf eine bestimmte Fähigkeit ausgerichtet sind. Sie können also den anderen Teammitgliedern nicht bei den Stories helfen, selbst wenn ihre Kapazität dies zulassen würde und die Prioritäten für die Stories dies ebenfalls begünstigen würden.

Es ist sogar für den Product Owner schwierig, sinnvolle Sprint-Inhalte für das Team zusammenzustellen, da er immer berücksichtigen muss, wie viele Personen an jeder einzelnen Story arbeiten können. Wenn mehr ähnliche Storys gleichzeitig in den Sprint eingebracht werden, ist die Kapazität des Teams letztendlich überfordert, selbst wenn es tatsächlich Personen gibt, die an diesen Storys arbeiten könnten, aber nicht die Fähigkeiten haben, damit anzufangen.

Das Dilemma lösen

Es handelt sich um ein Dilemma, das es zu lösen gilt, und die Projektmanager müssen sich darüber im Klaren sein, welchen Weg sie wählen müssen. Genauer gesagt, eine Wahl 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 in die Breite gehen, aber nicht in die Tiefe. Dann kann die Bereitstellung schnell voranschreiten, aber die Qualität könnte darunter leiden.
• Sie haben dedizierte Experten für jede Technologie, akzeptieren dann aber die Einschränkung und arbeiten härter an besser angepassten Print-Inhalten. Dann können die Mitarbeiter in die Tiefe gehen und großartige Geschichten erstellen, aber die Geschichten müssen nacheinander angegangen werden, so dass es länger dauert, sie zu liefern.

Schwacher Product Owner

Dies ist nicht unbedingt ein “Prozessproblem” per Definition, aber ich behandle es so, weil die Erstellung von soliden Stories 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 eher auf die Fähigkeit des Product Owners, dem Team Geschichten zu liefern, die die Entwickler verstehen können und die aus Sicht der Produkt-Roadmap einen klaren Sinn ergeben. Beides ist sehr wichtig für ein erfolgreiches Scrum-Team.

Wenn es den Geschichten an Details mangelt, damit die Entwickler den Zweck, den funktionalen Wert oder die technischen Erwartungen klar verstehen können, dann können im Grunde zwei Szenarien eintreten:

• Die Entwickler bauen etwas anderes als das, was der Product Owner eigentlich wollte. Das ist sogar während des Sprints selbst schwer zu erkennen, da der Product Owner meist nicht in der Lage war, den Fortschritt der Stories auf einer so detaillierten Ebene zu verfolgen, und der PO meist einfach erwartet, dass die Dinge (auf magische Weise) passieren werden.
• Die Entwickler werden viel zu viel Zeit damit verbringen, die Stories zu klären und sie immer wieder zu diskutieren, anstatt mit ihrer Erstellung zu beginnen. Das bedeutet viele zusätzliche Anrufe, wiederholte Absprachen und die Verschiebung der Arbeit in die späte Sprintphase. Es wird ein Punkt erreicht, an dem die ursprünglichen Schätzungen für die Stories nicht mehr als genau angesehen werden können und die Stories nicht mehr innerhalb des Sprints abgeschlossen werden können und in die nächsten Sprints verschoben werden. Im schlimmsten Fall wiederholt sich die Situation dann in den folgenden Sprints.

Zeit für Selbstreflexion

Es ist in der Regel schwer zuzugeben, aber der Product Owner sollte sich die Zeit nehmen, nachzudenken, die erstellten Backlog-Stories zu betrachten und sie schließlich mit der Vision der Produkt-Roadmap zu vergleichen, falls es noch eine sinnvolle Verbindung zwischen diesen beiden gibt – falls es überhaupt eine Roadmap gibt. Wenn nicht, ist das der erste Punkt, den es zu lösen gilt. 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 muss die Rolle des Product Owners im Team gelöst werden. Zumindest könnte es eine sinnvolle Option sein, einen soliden Business-Analysten in das Team zu holen, der sich mehr an den Inhalten des Teams als an den geschäftlichen Inhalten orientiert (dafür haben wir in diesem Fall bereits einen Product Owner), selbst um den Preis erhöhter Gesamtkosten des Teams.

Testprozesse ohne festen Zeitplan

Was ist, wenn die Testaktivitäten nicht an einen konkreten Zeitplan innerhalb eines Scrum-Sprints 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 nach außen hin präsentiert wird.

Meine Erfahrung zeigt, dass das Ergebnis dieser Freiheit mehr Chaos als Flexibilität ist. Das bedeutet nicht, dass die Lösung für dieses Problem darin bestehen sollte, “Wasserfälle im Sprint” mit speziellen Testphasen zu schaffen, die erst nach Abschluss der Entwicklung folgen. Das ist in diesem Fall keineswegs der richtige Ansatz. Mehr dazu erfahren Sie in meinen Beiträgen über die Scrum-Teststrategie und den agilen Testlebenszyklus.

Wir können immer noch eine gewisse Flexibilität zulassen und den Testzeitplan so wählen, wie er für das aktuelle Entwicklungsteam und die gegebenen Produkteigenschaften, die das Team liefert, am geeignetsten erscheint. Es gibt jedoch zwei Hauptziele, die mit dieser Wahl erreicht werden sollten:

1. Minimieren Sie die Unterbrechung des Entwicklungsfortschritts während der Testaktivitäten.
2. Sorgen Sie für eine solide (aus inhaltlicher Sicht), zuverlässige (aus Sicht der Häufigkeit) und wiederholte (aus Sicht der Vorhersagbarkeit) Aktivität innerhalb des Teams.

Wenn diese Bedingungen erfüllt sind, wird sich das Team auf natürliche Weise an den Anpassungsprozess gewöhnen, und der Lieferplan wird nicht durch ungeplante längere Testaktivitäten beeinträchtigt.

Letztendlich kommt es auf eine zuverlässige und vorhersehbare Sprintfreigabe an, was mich zum letzten Punkt dieses Blogs führt.

Undefinierter Freigabeprozess

Nun, das ist für jedes Scrum-Team eine Selbstverständlichkeit. Doch seltsamerweise ist es auch einer der am meisten unterschätzten Prozesse.

Sehr oft sagt ein Scrum-Team einfach, dass die Veröffentlichung nach jedem Sprint erfolgen wird, ohne dass dies durch einen soliden Prozess untermauert wird. Was dann in der Realität passiert, ist eine Menge chaotischer, unvorhersehbarer Aktivitäten, die während der Release-Zeit anfallen. Plötzlich sind alle Mitarbeiter mit “Release-Aufgaben” beschäftigt und niemand kann sich mehr auf die Entwicklung neuer Sprint Stories konzentrieren. Die Sprint-Metriken stimmen nicht mehr, und die Freigabe sieht aus der Sicht einer dritten Person (in der Regel der Kunde) wie eine zufällige, unvorhersehbare Aktivität aus.

Die Mitarbeiter sind so sehr auf das Backlog, die Sprint-Inhalte, die Entwicklung, das Testen und schließlich die Präsentation der Ergebnisse konzentriert, dass sie vergessen, dass der nächste Sprint bereits läuft, sobald sie mit all dem fertig sind, und dass sie bereits Zeit verlieren.

Suche nach einem guten Zeitpunkt für die Veröffentlichung

Wann genau sollte das Team also die tatsächliche Freigabe für die Produktion vornehmen? Die einzige wichtige Sache, die am Ende zählt.

Die Antwort auf diese Frage liegt im Prozess, vorausgesetzt, Sie haben einen. Das hängt ab von:

• der Komplexität der Inhalte, die das Team in den Sprints produziert,
• der Dauer eines Sprints,
• der Anzahl der betroffenen Komponenten im System
• der Anzahl der Personen, die die Änderungen verwenden und beantragen,

sollte ein wiederholter Freigabeprozess festgelegt und fortlaufend befolgt werden. Die genauen Regeln des Prozesses können wiederum flexibel festgelegt werden. Aber genau wie bei den Testaktivitäten ist es wichtig, dass es sich um eine felsenfeste Gewohnheit handelt, die vorhersehbar ist und für konkrete Tage in der Zukunft geplant wird, damit man sich darauf verlassen kann.

Auswahlmöglichkeiten

Die möglichen Formen eines solchen Prozesses könnten eine der folgenden oder andere sein:

• Schließen Sie die Tests der Funktionen des aktuellen Sprints während des folgenden Sprints ab und geben Sie die Inhalte am Ende dieses Sprints frei (sobald die Tests abgeschlossen sind). Das bedeutet, dass jede Veröffentlichung keine Inhalte aus dem allerletzten Sprint enthält, sondern Stories aus den 2 Sprints davor.
  • Der letzte Sprint vor der Veröffentlichung ist immer dem Testen der Inhalte aus den beiden vorangegangenen Sprints gewidmet.
  • Das bedeutet nicht, dass die Entwicklung während des “Test-Sprints” gestoppt wird; es bedeutet 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, sollten Sie sich bemühen, die Veröffentlichung nach dem Ende jedes Sprints durchzuführen. Dann muss dies ein sehr strikter Prozess sein, bei dem sich die Mitarbeiter zu 100% auf diese wenigen Tage konzentrieren. Der Rest des Entwicklungsteams sollte dabei in keiner Weise beeinträchtigt werden.
• Sie können sich auch dafür entscheiden, einmal pro Monat oder einmal pro N Monate zu veröffentlichen, vor allem, wenn dies aus Sicht der Endbenutzer in Ordnung ist. Dadurch erhöht sich der Testaufwand für jeden Sprint (da der Inhalt für jede Veröffentlichung größer ist). Andererseits bedeutet dies, dass sich die Aktivitäten im Laufe der Zeit weniger häufig wiederholen, was in diesem Fall für das Team von Vorteil sein kann. Infolgedessen kann das Team zwischen den einzelnen Versionen mehr neue Funktionen entwickeln, auch wenn die Funktionen in einem langsameren Rhythmus in die Produktion gehen.

Aber wie schon ein paar Mal gesagt, ist es nicht so wichtig, welche dieser Prozesse gewählt werden. Viel wichtiger ist, wie gut sich das Team dann an diesen Prozess hält und ihn zu einer dauerhaften Gewohnheit macht.

Lesen Sie auch diesen Leitfaden für den Release Management Prozess und die Praktiken.