Ihre Methode hat bereits Retrospektiven. Sie nennt sie Lessons-Learned-Berichte.

Hat Waterfall Retrospektiven?

Ja, unter einem anderen Namen. PRINCE2 nennt „aus Erfahrung lernen" als eines seiner sieben Prinzipien¹. Es führt ein Lessons Log, das während der Starting-Up-Phase in einer Aktivität namens Capture Previous Lessons erstellt wird, und ein Lessons Report ist typischerweise in jedem End Stage Report enthalten². Wenn Sie PRINCE2 durchführen, halten Sie bereits eine strukturierte Review am Ende einer Phase ab und schreiben auf, was Sie gelernt haben. Das ist eine Retrospektive.

Ihnen wurde wahrscheinlich das Gegenteil erzählt. Die Vorstellung, dass traditionelle Teams „keine Retros machen", ist eine der am häufigsten wiederholten und am wenigsten hinterfragten Behauptungen im Delivery-Tooling-Markt. Sie übersteht den Kontakt mit den Handbüchern nicht. Was traditionellen Teams fehlt, ist nicht die Praxis. Es ist das Tooling.

Denken Sie darüber nach, wo ein Lessons Report tatsächlich landet. Jemand schreibt ihn an einer Phasengrenze, meist unter Zeitdruck, meist nachdem die interessanten Details bereits verblasst sind. Er wird einem End Stage Report beigefügt, auf einem gemeinsamen Laufwerk abgelegt und von ungefähr niemandem zu Beginn der nächsten Phase gelesen. Die Erkenntnis wird erfasst und dann gestrandet.

Fairerweise sind agile Teams dabei nicht offensichtlich besser. Ein Retro-Board voller Haftnotizen wird genauso oft fotografiert und aufgegeben. Keine der beiden Gruppen hat das Problem gelöst, die Lektion vom letzten Monat zum Verhalten des nächsten Monats zu machen. Der Unterschied ist, dass eine dieser Gruppen fünfzehn Jahre damit verbracht hat, Software dafür zu entwickeln, und der anderen gesagt wurde, die Software sei nicht für sie.

Egal welche Methode Sie verwenden, PRINCE2, einen internen Stage-Gate-Prozess oder etwas, das Ihre Organisation über zwei Jahrzehnte zusammengestellt hat, die Form ist dieselbe. Am Ende einer Phase überprüfen Sie, was passiert ist, und Sie schreiben es auf. Die offene Frage ist nie, ob Sie es tun. Es ist, ob etwas mit dem passiert, was Sie geschrieben haben.

Worauf bilden sich agile Zeremonien in traditioneller Delivery ab?

Jede agile Zeremonie hat ein traditionelles Gegenstück, und die meisten Gegenstücke kamen zuerst. Retrospektiven bilden sich auf Lessons Reviews ab. Standups bilden sich auf Statusberichte ab. Demos bilden sich auf Stage-Gate-Reviews ab. Schätzung bildet sich auf die Zahlen ab, die bereits in Ihrer Work Breakdown Structure sitzen. Das Vokabular ist unterschiedlich. Die Arbeit ist dieselbe, und Sie machen sie bereits.

Die linke Spalte ist ein Vokabular, das Sie nicht gewählt haben und nicht brauchen. Die mittlere Spalte ist Arbeit, die Sie bereits tun, nach einem Zeitplan, den jemand anderes festgelegt hat, meist in eine Vorlage. Simyl Flow automatisiert die mittlere Spalte. Die linke Spalte ist nur das, was die Buttons zufällig sagen.

Sie können das Produkt ein Jahr lang nutzen, ohne jemals das Wort „Sprint" laut auszusprechen.

Erfordert Simyl Flow zweiwöchige Sprints?

Nein. Ein Sprint in Simyl Flow ist ein benannter Datumsbereich mit einem Anfang und einem Ende. Nirgendwo im Produkt wird eine Länge erzwungen. Eine sechswöchige Phase, ein vierteljährliches Release oder ein Meilenstein, dessen Enddatum bereits zweimal verschoben wurde, verhalten sich alle gleich, weil jede Metrik aus Zeitstempeln auf Ihren Tickets und Commits berechnet wird und nicht aus der Länge des Containers.

Das ist wichtiger, als es klingt. Wenn ein Tool zwei Wochen annimmt, sickert diese Annahme in alles Nachgelagerte durch: die Diagramme, die Vergleiche, die Schwellenwerte, die entscheiden, was als langsam gilt. Tools, die so gebaut sind, passen wirklich nicht zu einer phasenbasierten Organisation, und die vernünftige Reaktion ist die, die Sie bereits hatten.

Hier ist der Container ein Label auf einem Datumsbereich. Nennen Sie es Phase 3. Nennen Sie es Release 4.2. Nennen Sie es Q3 Hardening. Die Cycle Time ist immer noch das Intervall zwischen dem Start und dem Abschluss eines Tickets. Die Bug Rate ist immer noch ein Verhältnis. Keine wird bedeutungslos, weil Ihre Phase elf Wochen statt zwei lief.

Was können Sie messen, ohne zu ändern, wie Ihr Team arbeitet?

Verbinden Sie Ihren Issue Tracker und Ihr Code-Repository, und sechs Metriken erscheinen, ohne dass jemand an einem neuen Meeting teilnehmen muss: Velocity, Cycle Time, PRs Merged, Commits, Bug Rate und Unplanned Work. Jede wird aus Aufzeichnungen abgeleitet, die Ihr Team bereits im Laufe der Arbeit erstellt. Keine Schätzungssitzung, kein Standup und keine Retrospektive ist erforderlich, um eine davon zu produzieren.

Das ist der ehrliche Einstiegspunkt, und es ist der, den wir empfehlen würden, selbst wenn Sie von Zeremonien begeistert wären. Niemand muss neues Vokabular lernen. Niemand muss an einem Montagsmeeting von einer Philosophie überzeugt werden. Die Daten sind bereits in Jira und GitHub, liegen dort und beschreiben, wie Ihre Delivery sich tatsächlich verhält.

Die Zeremonien existieren im Produkt. Sie können sie einschalten, wann immer Sie wollen, oder nie. Ein Team, das zwei Systeme verbindet und nichts anderes öffnet, bekommt immer noch einen Cycle-Time-Trend, was mehr ist, als die meisten traditionellen Shops heute haben.

Was die Leute tendenziell überrascht, ist, wo das Warten auftaucht. Nicht in der Entwicklung. In den Übergaben zwischen Phasen, in der Lücke zwischen „Code complete" und „Testumgebung verfügbar", in der Woche, die ein Change Order auf eine Unterschrift wartete.

Was sagt dir Velocity nicht?

Velocity sagt dir, wie viel Arbeit in einem Zeitraum abgeschlossen wurde. Sie kann dir nicht sagen, ob diese Arbeit abgeschlossen blieb, wie lange irgendetwas davon wartete, bevor es jemand aufnahm, oder was es kostete, es aus der Tür zu bekommen. Eine Phase kann ihr Velocity-Ziel exakt erreichen und trotzdem Defekte ausliefern, die die folgende Phase auffressen. Die Zahl sieht in beiden Fällen gleich aus.

Das ist kein Argument gegen Velocity. Sie ist eine wirklich nützliche Zahl, und sie zu verfolgen bringt dich vor die vielen Organisationen, die überhaupt nichts verfolgen. Das Problem ist nicht, dass Velocity falsch ist. Es ist, dass Velocity normalerweise allein steht.

Stell dir zwei Phasen mit identischer Velocity vor. In der ersten bewegte sich die Arbeit stetig, Review dauerte einen Tag, und fast nichts kam zurück. In der zweiten saß alles neun Tage lang im Review, wurde in einem Schub in der letzten Woche ausgeliefert, und ein Drittel davon kam innerhalb eines Monats als Defekte zurück. Velocity erfasst diese beiden Phasen als gleichwertig. Cycle Time, Bug Rate und Unplanned Work tun das nicht.

Unplanned Work ist normalerweise die Zahl, die in einem phasenbasierten Betrieb am härtesten einschlägt. Sie ist die Zahl, die endlich erklärt, warum der Plan abrutschte, obwohl niemand im Team etwas falsch gemacht hat. Du hast für die Arbeit geplant, von der du wusstest. Etwas anderes kam hinzu. Die meisten Planungsprozesse haben keine Möglichkeit, das zu zeigen, also wird die Abweichung den Schätzungen oder den Leuten zugeschrieben, und das Gleiche passiert in der nächsten Phase.

Du kannst sehen, wie die sechs Dimensionen zusammenpassen, in der Effektivitätsübersicht.

Wir betreiben keinen Langzeitbetrug

Es gibt keine Phase zwei, in der wir dich bitten, Scrum einzuführen.

Die Messung funktioniert, weil deine Phasen Daten haben und deine Tickets Zeitstempel haben. Sie funktioniert nicht wegen des Frameworks, das an der Wand hängt. Wenn du deine Systeme verbindest, nie eine Retrospektive in diesem Produkt durchführst und nie ein einziges Element darin schätzt, sagt es dir trotzdem, ob die Lieferung schneller oder langsamer wird und wo das Warten passiert.

Wir wären lieber nützlich für dich, wie du bereits arbeitest, als darauf zu warten, dass du zuerst jemand anderes wirst.

Kein Conversion-Funnel. Ein Messwerkzeug.

Häufig gestellte Fragen

Müssen wir Agile einführen, um Simyl Flow zu nutzen?

Nein. Das Produkt liest Daten aus deinem Issue Tracker und Zeitstempel aus deinem Repository. Beides hängt nicht von einem Framework ab. Teams, die Phasen, Stage Gates oder einen maßgeschneiderten internen Prozess betreiben, erhalten die gleichen Metriken wie Teams, die zweiwöchige Iterationen durchführen, weil die zugrunde liegenden Aufzeichnungen in beiden Fällen gleich sind.

Erfordert Simyl Flow zweiwöchige Sprints?

Nein. Ein Sprint ist ein benannter Datumsbereich mit einem Anfang und einem Ende, und keine Dauer wird erzwungen. Eine Phase, ein Meilenstein, ein Release oder ein Quartal funktionieren alle. Metriken werden aus Zeitstempeln auf Tickets und Commits berechnet, sodass die Länge des Containers nicht ändert, wie sie berechnet werden.

Wir betreiben PRINCE2. Wo passt es hin?

Dein End Stage Report ist der natürliche Ort. PRINCE2 setzt bereits eine Lessons Review an diese Grenze, sodass die Retrospektive-Features irgendwo Offensichtliches leben können, wenn du sie jemals möchtest. Du musst sie nicht nutzen. Verbinde deine Tools und die Liefermetriken funktionieren unabhängig davon, welcher Prozess sie umgibt.

Wir führen keine Retrospektiven durch. Ist es trotzdem nützlich?

Ja. Cycle Time, Bug Rate, Unplanned Work, PRs Merged und Commits werden alle aus deinen vorhandenen Tickets und deiner Code-Historie abgeleitet. Sie erfordern kein Meeting und keine Moderation. Retrospektiven fügen einen Ort hinzu, um auf das zu reagieren, was die Zahlen zeigen, aber die Zahlen kommen an, egal ob du eine durchführst oder nicht.

Was ist das Minimum-Setup?

Ein Issue Tracker oder ein Code-Repository. Verbinde es, wähle einen Datumsbereich, der zu deiner bisherigen Planung passt, und die Metriken werden aus der Historie befüllt. Nichts ändert sich daran, wie dein Team in dieser Woche arbeitet, und das ist der Punkt.

Quellen