Mit einem Wurf

– oder wie ich strategisch Fokus aufbaue, um große Softwareaufgaben zu lösen

Will man Softwareprojekte mit Expeditionen vergleichen, wird man wahrscheinlich schnell hinken. Dennoch gibt es faszinierende Erkenntnisse, die sich mit etwas Übersetzung gut übertragen lassen. Ein Aspekt ist die enorme und lange Vorbereitung, die je nach Qualität über Gedeih und Verderb einer zeitlich sehr eng gesteckten Umsetzung entscheiden kann. Ein anderer die Fähigkeit zur Reaktion in unbekannten Gegenden, das Parieren des Unvorhersehbaren. Meinen letzten Softwarelaunch als PO hat die Lektüre über Shackleton’s gescheiterte Arktisexpedition begleitet und inspiriert.

In Teams schlummern Energiereserven, die man zielgerichtet zum Einsatz bringen oder sinnlos verschwenden kann. In weniger glücklichen Fällen stellt sich die Verschwendung von alleine ein, z.B. wochenlanger Crunch Mode mit Erschöpfung und Krankheit. Daher wollen wir uns der Choreographie eines Erfolgsfalles zuwenden. Unser Szenario: Ein Team startet Anfang des Jahres, man hat sich nach Storymapping und Magic Estimation mit anschließender Definition eines MVP einen Launch nach acht Monaten ausgerechnet. Das Team hatte Zeit, sich zu finden und arbeitet mit einer brauchbaren Geschwindigkeit. In den ersten Monaten explodiert das Backlog mit neuen Anforderungen, die Umsetzungen ziehen sich in die Länge, der Fokus auf den Launch schwindet. Der Scope des MVP wurde zwar nicht überzogen, aber neue, ursprünglich nicht gesehene Features und Wünsche aus dem Management drücken über das Backlog in die Sprints. Man kennt sich, technische Liebhabereien stoßen auf wenig Widerstand und werden eingebaut – der Termin ist ja noch fern. Einzelne Komponenten haben bereits einen zu hohen Umsetzungsgrad, andere sind noch sehr elementar implementiert. Das Team liefert, hat aber die Konzentration auf das schnelle auf-die-Strasse-kommen, die Sicht auf den Kern der Applikation verloren.
Wie bekomme ich den Fokus zurück, wie kann ich den Termin noch schaffen (oder kontrolliert überziehen)?

Vier Thesen

Aus der Erfahrung mit unterschiedlichen Teams und Projekten würde ich folgende Thesen aufstellen:

• These 1: Ich habe nur einen Wurf. Misslingt der, sind Fokus und Dringlichkeit verbrannt
• These 2: Ich kann mit zusätzlichem Einsatz, mit Kraftreserven rechnen für vielleicht 2 Wochen, ohne den Sustainable Pace zu verletzen und langfristig Schaden im Entwicklerteam anzurichten
• These 3: Ich weiß, dass sich in den letzen Tagen vor dem Launch viele no goes und must have bewegen, also an Bedeutung verlieren werden
• These 4: Nach dem Launch diktiert das Tagesgeschäft die Priorisierung der Aufgaben, was einen natürlichen Fokus mitbringt

Will ich nicht in das Problem von These 1 laufen, die Reserven von These 2 ausschöpfen, den Effekt von These 3 nutzen und den Zufluss „natürlicher“ Stories erreichen, brauche ich zwei Phasen: In Phase EINS definiere ich den Zeitpunkt, an dem ich den Launchtermin verbindlich machen kann, z.B. „In zwei Monaten definieren wir den Launchtermin“. In Phase ZWEI setze ich den Launchtermin, z.B „der Launch ist in 2 Wochen am DD-MM-YY“.

Das Finden des besten Termins vorbereiten

In Phase EINS kürze ich das Backlog auf alle Elemente zusammen, die ich wirklich brauche, um live zu gehen und dem Kunden eine vollständige Produkterfahrung zu ermöglichen. Hier geht es ausschließlich darum, die Zeitspanne zu finden, die ich brauche, um das System so weit fertig zu stellen, dass ich den Launchtermin setzen kann. Der Launchtermin selbst wird NICHT gesetzt. Wir setzen ausschließlich den Termin, an dem wir uns in der Lage sehen, den Launchtermin bestimmen zu können. Das Backlog wird trotz aller Kürzungsbemühungen immer mehr Stories beinhalten, als man in der verbleibenden Zeit abarbeiten kann.

Alle und alles ins Boot holen

Wichtig ist die vollständige Abbildung aller Prozesse und eine funktionierende Infrastruktur. In dieser Zeit ist es wichtig, dass das System von allen getestet wird, die auch im späteren Live-Betrieb aktiv sind. Die Qualität einer vollständigen Simulation bestimmt das Gewicht späterer Fehler und möglicher Lücken im Ablauf. Hier muss ausreichend sensibilisiert werden. Es darf und soll zu diesem Zeitpunkt Workarounds geben, z.B. eine Weiterberechnung per Spread Sheet, rudimentäres BI, Tools wie Mailchimp etc., manuelle Zuarbeit z.B. beim Deployment. Ich muss wieder klar machen, dass die Entwicklung nach dem Launch weiter geht. Hier Klarheit über die Aufgaben und Priorisierung bei Operations und den Entwicklerteams zu schaffen, wird Befindlichkeiten glätten und helfen, den Launchtermin zu halten.

Den besten Termin erreichen

In Phase ZWEI setzen wir den Launchtermin. Wir haben jetzt alle Komponenten am Start, das System wäre jetzt grundsätzlich in der Lage Kunden zu bedienen. Das Team wird u.U. dennoch sagen, dass es unmöglich sei, in zwei Wochen live zu gehen, weil es aus dem einfachen Hochrechnen der aktuellen Velocity auch so erscheint. Natürlich darf der Termin nicht unrealistisch sein und die Teams dürfen keine schwerwiegenden Dysfunktionen haben (Uneinigkeit bei der Wahl der Tools, der Gestalt der Infrastruktur, der geplanten Feature, der geschaffenen Prozesse). Das eigene Potenzial wird den Teams erst im Laufe der kommenden Tage und Wochen sichtbar werden. Hier gilt es, Mut zu machen und Zuversicht aufzubauen. Der Countdown und die übersichtliche Zeitspanne werden ein Gefühl der Dringlichkeit erzeugen. Damit dieser positive Fokus nicht in ein Gefühl der Fatalität umschwingt, müssen regelmäßig und gemeinsam die Aufgaben heruntergebrochen und auf die verbleibende Zeit gemappt werden. Wünsche nach Feature und Implementierungstiefen werden umfallen wie Dominosteine, besonders an den letzten Tagen. Sehr wahrscheinlich wird ein Wir Gefühl entstehen, das hilft, alle Reserven zu mobilisieren und mögliche Konflikte hintenanzustellen und damit Reibungsverluste zu minimieren (nicht vergessen, Zeit zu reservieren nach dem Launch, um solche Konflikte anzusprechen).

Den richtigen Rahmen wählen

Für das das schnelle Erreichen des Zieles in Phase ZWEI eignet sich ein Format wie Kanban besser als z.B. Scrum, weil eine hohe Reaktionsfähigkeit des Teams auf neue oder geänderte Anforderungen und ein erforderliches Umpriorisieren dem Team die notwendige Flexibilität ermöglichen. Das Team kann sich auch entscheiden, schon in Phase EINS oder im Laufe der Phase EINS in den Kanban Modus zu wechseln.

Erste Symptome erkennen und fördern

Erste Zeichen der Änderung sollten sich in der Phase ZWEI schnell einstellen, z.B. eine gesteigertes Bewusstsein für die Review-Spalte, die jetzt nicht mehr vollläuft, ein höherer Informationsgrad im gesamten Team durch kürzere Zyklen des Austausches, eine erhöhte Geschwindigkeit beim Deployment, ein gesteigertes Verantwortungsbewusstsein für das Funktionieren der Gesamtapplikation und – Futter für die intrinsisch Motivierten: Flow. Diesen Zustand gilt es zu fördern und das Team vor allen störenden Einflüssen zu schützen. Das kann das Bereitstellen von Essen und Getränken sein sowie der Schutz vor unangebrachten Forderungen, die die gerade gewonnene Motivation und den Flow wieder zerstören könnten. Ein schöner Nebeneffekt: Sehr wahrscheinlich ist die Leistung des Teams, die Durchdringung des Geschäftsmodells und der Prozesse nach dem Launch deutlich höher als zuvor.

Wer ausreichend Erfahrung hat, kann in vielen Teilen sicher seiner Intuition folgen. Ich finde es dennoch hilfreich, auch um Prozesse weiter zu verbessern und Varianten sicher zu erkennen, eine Strategie klar zu formulieren und auch das Team aktiv einzubeziehen. Wie man die beiden Phasen richtig dimensioniert, hängt stark von den Anforderungen und der Qualität der Zusammenarbeit der Mitarbeiter ab. Beide Phasen dürfen nicht zur Erschöpfung führen. Ein bis zwei Monate für Phase EINS, ein bis zwei Wochen für Phase ZWEI.

Niemand läuft Gefahr, bei einem Softwarelaunch zu erfrieren, aber der Erfolg mag ebenso beflügeln wie die Durchquerung der Antarktis.

Quellen:
Shackleton’s Way: Leadership Lessons from the Great Antarctic Explorer, Margot Morrell and Stephanie Capparell, London 2002