Es wurde schon viel darüber geschrieben, was agile Entwicklung und Scrum für ein Team leisten sollten. Nachdem ein Team einige Zeit gereift ist, wird es leicht blind und unempfindlich für Phänomene, die seine Effektivität behindern und sein Potenzial einschränken. Nennen wir sie „Scrum-Gerüche“.
Es gibt Teams, die gerade erst mit der Einführung von Scrum beginnen, und andere, die schon einigermaßen ausgereift sind oder sogar Erfahrung damit haben. Jede Stufe bringt ihre eigenen Gerüche und Düfte mit sich. In dieser Serie werden wir uns auf die grundlegenden und fortgeschrittenen Herausforderungen konzentrieren, denen Scrum-Teams häufig begegnen. Heute sprechen wir über das Problem der unregelmäßigen Releases.
Unfähigkeit, regelmäßig veröffentlichungsfähige Versionen bereitzustellen
Eines der grundlegenden Scrum-Prinzipien ist die Bereitstellung eines potenziell veröffentlichungsfähigen Produktinkrements als Ergebnis der Arbeit jedes Sprints. Ich persönlich glaube, dass dies einer der wertvollsten und am meisten unterschätzten Vorteile der gesamten Scrum-Welt ist. Scrum besagt, dass das Entwicklungsteam am Ende eines jeden Sprints ein Stück Software produzieren sollte, das der Product Owner dann sofort freigeben und produktiv einsetzen kann, wenn er das möchte. Das bedeutet, dass die Software funktionstüchtig sein muss, ohne Regressionen und ohne unfertiges Material. Jeder im Team muss das Gefühl haben, dass es keine Schulden gibt - weder technische noch funktionale.
Im wirklichen Leben werden die Produktions-Builds jedoch eher zufällig bereitgestellt. Die Tage und Sprints vergehen, und es gibt immer etwas in der aktuellen Version zu beheben. Jedes Scrum-Team hat das schon einmal erlebt. Am Ende des Sprints möchte das Team eine endgültige Version bereitstellen, aber es gibt unvollständige Funktionen oder Regressionen, die so schwerwiegend sind, dass diese Version nicht für den produktiven Einsatz freigegeben werden kann. Im darauffolgenden Sprint versucht das Team also, die Fehler zu beheben, entwickelt aber parallel dazu neue Funktionen weiter, was eine neue Quelle potenzieller Probleme und Unsicherheiten mit sich bringt. Die Tage und Sprints vergehen, und es gibt immer etwas in der aktuellen Version zu beheben.
Dieser Teufelskreis setzt den Product Owner unter Druck, endlich alles zu veröffentlichen, was bis dahin implementiert wurde. Es gibt das allgegenwärtige „fast fertig“-Syndrom, den sich hinziehenden Moment der problemfreien Freigabe. Der Product Owner wird nervös und es ist verlockend zu versuchen, eine weitere „wichtige“ Sache in den Sprint einzuschleusen, denn wer weiß, wann die nächste Veröffentlichung stattfindet. Lange Markteinführungszeiten sind eine Realität. Es kommt zu so genannten Härtungs- oder Stabilisierungssprints, bei denen die Teams lediglich versuchen, das Produkt in einen brauchbaren Zustand zu versetzen.
Abgesehen von der unvermeidlichen Demotivation und dem Druck, die dadurch entstehen, führt dies auch zu Problemen bei der Planung und Transparenz. Sie wissen nie, wo man wirklich steht, bis Sie keine Arbeit mehr an den bereits entwickelten Backlog-Elementen haben.
Den Boden vorbereiten
Wie kann man also die Wahrscheinlichkeit erhöhen, dass am Ende des Sprints regelmäßig potenziell veröffentlichungsfähige Versionen entstehen? Hier geht es zum Teil um eine Änderung der Denkweise. Die Bereitstellung eines funktionierenden, schuldenfreien, fertigen Software-Inkrements muss für das Team während des Sprints oberste Priorität haben, und alle Aktivitäten müssen sich auf dieses eine Ziel konzentrieren.
Alles beginnt mit der Verfeinerung des Backlogs. Backlog-Elemente müssen in möglichst kleine Teile zerlegt werden, um dem Team ein hohes Maß an Manövrierfähigkeit bei der Planung zu geben. Oft ist es notwendig, wirklich atomare Benutzergeschichten zu erstellen, d. h. die Benutzergeschichte auf den Kern der Bedürfnisse des Benutzers zu reduzieren und sie mit dem einfachsten Ansatz zu lösen. Der ganze Rest wird einfach zu einem weiteren Backlog-Element, das unabhängig davon priorisiert wird. Zu große Backlog-Elemente oder ein zu großer Optimismus in Bezug auf die Beibehaltung einiger „einfach zu erledigenden“ Nice-to-have-Elemente, die mit dem Kern der User Story verknüpft sind, sind einfach nur naiv und häufig mit einer gewissen Bequemlichkeit verbunden.
Bei der Sprintplanung entwickelt das Team dann eine Strategie, um das Risiko zu steuern, dass kurz vor Ende des Sprints ein schwerwiegendes Problem entdeckt wird und zu wenig Zeit bleibt, um es tatsächlich zu lösen. Es ist hilfreich, den Sprint mit den risikoreichsten Funktionen zu beginnen und sich zu bemühen, auch einzelne Teile davon so früh wie möglich zu testen. Auf diese Weise lässt sich besser abschätzen, wie viel Arbeit wirklich noch zu erledigen ist. Elemente mit geringem Risiko (wie einfache Textänderungen oder Anpassungen der Benutzeroberfläche) können auf einen späteren Zeitpunkt im Sprint verschoben werden.
Das Entwicklungsteam darf nicht zu viel Arbeit einplanen, in der Hoffnung, dass wir es dieses Mal „schaffen werden“. Das Team muss auf der Grundlage früherer Erfahrungen realistisch mit zusätzlichen unerwarteten Arbeiten rechnen, selbst bei „sicheren“ Backlog-Elementen.
Und natürlich gibt es die bekannte Definition of Done (DoD), die Fertigstellungskriterien. Jedes Teammitglied muss verstehen, was nötig ist, damit ein Punkt als erledigt gilt, und jeder muss dies auf dieselbe Weise verstehen. Was steht auf der DoD-Checkliste? Nun, das hängt von dem jeweiligen Team, dem Produkt und den verwendeten Technologien ab. Aber wenn sich ein Team einig ist, besteht die DoD für jeden Punkt aus dem zu schreibenden Code, den Einheitstests oder automatisierten Tests, der Dokumentation, der Codeüberprüfung, dem End-to-End-Test und allem anderen, was erforderlich ist. Niemand kann behaupten, dass ein Element fertig ist, solange nicht alle diese Arbeiten erledigt sind. Dies trägt dazu bei, einen gemeinsamen Standard für die Qualität und für die Komplexitätsabschätzung zu schaffen. Durch die strikte Einhaltung dieses Standards wird das Risiko einer Schuldenanhäufung verringert. Fehlende oder ungenutzte DoD schaffen einen fruchtbaren Boden für Schulden und machen eine Planung fast unmöglich.
Alltägliche Aktivitäten und Entscheidungen
Häufige End-to-End-Tests während eines Sprints sind absolut unerlässlich. Es ist eine gefährliche Illusion, einen Tag vor Ende des Sprints eine einzige Version zu erstellen, sie zu testen und zu erwarten, dass alles in Ordnung sein wird. Das ist keine Planung, das ist Glücksspiel.
Um dies zu ermöglichen, müssen neue Builds so oft wie möglich erstellt werden, sogar mehrmals am Tag. CI/CD-Pipelines sind ein Muss. TDD ist sehr hilfreich. Automatisierte Regressionstests sind ein Muss. Im Grunde genommen beseitigt die Automatisierung eines möglichst großen Teils der manuellen Arbeit die Gründe, warum Teams es normalerweise vermeiden, regelmäßig Builds zu erstellen. Diese Investition in die Automatisierung lohnt sich in der Regel auf lange Sicht.
Das Hinzufügen von Feature Switches (oder Flags) hilft. Wenn es offensichtlich ist, dass das Team nicht in der Lage sein wird, ein bestimmtes Backlog-Element fertigzustellen (d. h. die DoD zu erfüllen), wird es „ausgeschaltet“ und beeinträchtigt den Rest der Software nicht.
Das Team muss sich auch darüber im Klaren sein, dass ein erledigter und ausgelieferter Backlog-Punkt viel mehr wert ist als zehn in Arbeit befindliche Punkte. Das tägliche Scrum ist ein idealer Zeitpunkt für das Team, um den Fortschritt des Sprint Backlogs zu bewerten und gemeinsam daran zu arbeiten, die in Arbeit befindlichen Elemente so schnell wie möglich in einen „fertigen“ Zustand zu überführen. Das Team muss lernen, immer wieder neu zu bewerten, wo jeder Einzelne gerade arbeitet, und entscheiden, ob es etwas Wertvolleres gibt, auf das man sich konzentrieren kann. Alle Sprint-Backlog-Elemente sind die Aufgabe des gesamten Teams, nicht die eines Einzelnen. Es geht darum, ständig neu zu bewerten, wo die Anstrengungen des Tages investiert werden sollen, um die Chance zu maximieren, am Ende des Sprints eine schuldenfreie Software zu erhalten.
Wenn ein Sprint-Backlog-Element riskant wird und es den Anschein hat, dass im Sprint nicht mehr genug Zeit zur Verfügung steht, muss das Team entscheiden, ob es mehr Energie in dieses Element investieren will (um die Chance zu erhöhen, dass es erledigt wird, z. B. indem es mehr Entwickler darauf ansetzt) oder ob es die Arbeit daran ganz einstellen und sich auf ein anderes Element konzentrieren will, das eine echte Chance hat, erledigt zu werden. Die Entscheidung, ein Sprint Backlog Item fallen zu lassen, muss mit dem Product Owner abgesprochen werden.
Wenn Sie mehr über Strategien zur Erreichung regelmäßiger Releases erfahren möchten, lesen Sie bitte den Folgebeitrag „Scrum-Smells Teil 2“.
