Umgang mit Notfällen in agilen Teams

Jedes agile Team muss sich neben seiner "regulären" Arbeit auch mit dem befassen, was es in die freie Wildbahn entlassen hat. Wie geht man mit der - per Definition - unbekannten Last von Produktionsnotfällen um, wenn man versucht, ein stabiles Tempo zu erreichen? Sie können mit Notfällen umgehen, indem Sie eine Triage durchführen, um entweder abzulehnen, aufzuschieben oder anzunehmen. Sie können einen Puffer einrichten, um einen Teil der Ungewissheit aufzufangen, und schließlich sollten Sie sich die Zeit nehmen, die Anzahl der Notfälle zu reduzieren, indem Sie Qualität einbauen. Wenn Sie feststellen, dass Sie hauptsächlich Wartungsarbeiten durchführen, können Sie Kanban in Betracht ziehen.

Der Kontext

In den alten Zeiten der Wasserfallprojekte hatte ich nie mit dem Schrecken aller Schrecken zu tun, der Wartung. Ich war Teil eines Teams, das etwas Neues entwickelte, und Sie konnten bis zum Ende des Projekts weitermachen. Es war die Wartungsabteilung, die sich mit dem Unsinn befassen musste, den ich geschaffen hatte. Ach, das waren noch Zeiten... der ganze Spaß ohne den Kater danach :-)

Aber agile Teams, oder eigentlich jedes Team, das früh und oft mit der Lieferung beginnt (in meinen späteren Wasserfall-Tagen hatte ich bereits herausgefunden, dass die Wartung ziemlich genau nach den ersten zwei Wochen beginnt... :-) ), liefern lange bevor es überhaupt möglich ist, das Projekt zu übergeben - wenn überhaupt. Die Art der häufigen Übergabe bedeutet, dass das Team alle auftretenden Probleme selbst lösen muss. Der erste Grund ist, dass sie diejenigen sind, die es tun können, der zweite, dass Sie die Korrekturen ohnehin in die Arbeit des Teams integrieren wollen: Sie müssen immer noch neue Versionen derselben Software liefern...

In meiner Beratungstätigkeit habe ich dieses Problem bei jedem einzelnen agilen Team, das ich kenne, erlebt, es ist also keine einmalige Situation für einige wenige Teams. Alle agilen Teams müssen lernen, mit diesem Problem umzugehen!

Das Problem

In einem Scrum-Team taucht das Problem in der Regel nach einem oder mehreren Sprints auf, in denen eine Reihe von "Produktionszwischenfällen" oder ähnliches ungeplantes Chaos so viel Zeit des Teams in Anspruch genommen hat, dass es sein geplantes Sprint-Ziel nicht erreicht hat. Das Ergebnis ist, dass es einem Team schwer fällt, die nächsten Sprints zu planen. Das erste Problem besteht darin, dass sie ihre "echte" Velocity nicht kennen, das zweite darin, dass sie die - per Definition unvorhersehbaren - Produktionsstörungen irgendwie einkalkulieren müssen.

Aber Vorsicht, im obigen Absatz ist ein Fallstrick versteckt. Vorhersagbarkeit ist nicht das Endziel von Agile! Vorhersagbarkeit ist wichtig, um zu wissen, wann eine Version ausgeliefert wird, und um zu wissen, wie das Team vorgehen soll. Aber ich habe zu viele Fälle gesehen, in denen Teams versuchen, "besser vorauszusagen", obwohl sie sich besser anpassen sollten. Wenn es um das Unvorhersehbare geht, sollte der Schwerpunkt zuerst auf der Anpassung liegen und nicht auf mehr Planung im Vorfeld. Das wäre eine Rückkehr zum "Weg des Wasserfalls"...

Das Ziel

Da haben wir es also: Das Ziel ist es , ein vernünftiges Maß an Ungewissheit zu verkraften und dabei ein Gleichgewicht zwischen Robustheit und Geschwindigkeit zu finden.

Die Lösungen

Bevor ich Ihnen einige Lösungen vorstelle, lassen Sie mich eines gleich vorwegnehmen: Wenn der Arbeitsaufwand für ungeplante Produktionsvorfälle im Vergleich zur "regulären" Arbeit erheblich ist, können Sie auf keinen Fall eine ausreichende Stabilität erreichen. Sie müssen zuerst die Ursachen für all diese Produktionsprobleme beheben. Dazu später mehr.

Lösung 1: Triage durchführen - und ablehnen

Als erstes sollten Sie prüfen, ob Sie das Produktionsproblem überhaupt beheben wollen. Das ist gar nicht so dumm, wie es auf den ersten Blick erscheinen mag. Es gibt so viele Fälle, in denen ein Produktionsnotfall gar kein Notfall ist und gar nicht erst hätte gemeldet werden müssen! Einige Beispiele für "Nicht-Notfälle":

• Der Vertrieb stürmt mit "dem Deal des Jahrhunderts" herein: "Wenn wir Funktion X JETZT einführen, können wir Kunde X für uns gewinnen". Meiner Erfahrung nach ist dies immer auf eine ungebildete und undisziplinierte Vertriebsabteilung zurückzuführen. Die Ursache dafür ist, dass der Vertrieb Dinge versprochen hat, die er nicht hätte tun sollen, und dass er jetzt seine eigene Haut retten muss. Es ist IMMER möglich, zwei Wochen auf eine neue Funktion zu warten.
• Einige Beteiligte "werten" normale Anfragen zu Produktionsnotfällen auf und versuchen so, die Verhandlungen über den Rückstand zu umgehen. "Es ist ein blockierendes Problem, dass ich diese Funktion nicht bekommen kann!". "Oh? Ist das System abgestürzt? Funktioniert etwas nicht?". "Nun... nein, aber es ist ein echtes Hindernis für meine Arbeit!". Dieser Interessent hat vielleicht ein echtes Bedürfnis, aber das macht es nicht zu einem Produktionsnotfall.

Lösung 1 ist also: ein starker Product Owner, der die Triage aller Produktionsprobleme vornimmt. Wenn es sich um ein echtes Produktionsproblem handelt, sollten Sie es auf jeden Fall beheben. Aber ich kann Ihnen garantieren, dass Sie eine ganze Reihe von Problemen finden werden, die überhaupt keine Notfälle sein sollten... Übrigens ist ein Product Owner, der auf diese Weise eine Triage durchführt, das, was James Coplien in seinem Buch über Organisationsmuster eine Firewall nennt.

Lösung 2: Führen Sie eine Triage durch - und verschieben Sie die Korrektur mindestens bis zum nächsten Sprint

"Wir haben ein wirklich großes Problem gefunden! Wir müssen es sofort beheben!". "Sicher, wir werden uns sofort darum kümmern. Wie lange ist dieses Problem schon im System?". "Nun, seit über einem Jahr, aber wir haben es gerade erst entdeckt!". "Das Problem ist schon seit einem Jahr bekannt? ...und Sie können nicht noch zwei Wochen auf eine Lösung warten?"

Lösung 2 ist eine Erweiterung von Lösung 1. Ein Notfall kann in der Tat wichtig sein, aber es gibt ein wichtiges Kriterium für einen Notfall: Es ist nur dann ein Notfall, wenn er im aktuellen Sprint behoben werden muss. Wenn Sie das Problem auf den nächsten Sprint verschieben können, gibt es kein Problem! Das Team kann es im Rahmen seines regulären Prozesses aufgreifen, es planen, bauen und am Ende des nächsten Sprints liefern. Auch dafür ist der Product Owner verantwortlich: Neben der Entscheidung, etwas abzulehnen, wird ein guter Product Owner dafür sorgen, dass alles, was aufgeschoben werden kann, auch aufgeschoben wird.

Lösung 3: Reservieren Sie einen Puffer für unerwartete Probleme

Wenn Sie die Lösungen 1 und 2 erledigt haben, sollte das, was übrig bleibt, ein echtes Problem sein, das Sie so schnell wie möglich lösen müssen. Der beste Weg, damit umzugehen, ist, einen Puffer an Zeit oder Story-Punkten zu reservieren, der ungeplant bleibt. Das funktioniert besonders gut, wenn die Arbeitsbelastung durch die anstehenden Probleme in der Vergangenheit einigermaßen stabil ist. Sie wissen zwar nicht, was Sie tun werden, aber Sie wissen, wie viel Mühe es kosten wird.

Aber Vorsicht, die Verwendung eines Puffers kann Ihnen zum Verhängnis werden! Die erste Gefahr ist die Größe des Puffers. Wenn der Puffer einen erheblichen Prozentsatz des Sprints ausmacht, z.B. mehr als 1/5 Ihrer Geschwindigkeit, dann entsteht ein großes Loch in Ihrem Planungsprozess. Befolgen Sie also Pufferregel 1: Der Puffer ist nicht für Backlog-Elemente gedacht. Versuchen Sie, den Puffer so klein wie möglich zu halten.

Die zweite Gefahr bei der Verwendung von Puffern ist das, was ich bereits in Lösung 1 besprochen habe: Sobald Ihr Interessensvertreter einen Workaround im regulären Prozess wittert, können Sie sicher sein, dass er sich darauf stürzen wird. Ein Puffer muss unbedingt vor ungewollter Verwendung geschützt werden. Führen Sie also eine gute Triage durch!

Die dritte Gefahr ist der Pufferüberlauf. Genau wie bei einem Computer führt dies dazu, dass der Prozess explodiert. Wenn der Puffer verwendet wird, müssen Sie verfolgen, wie viel davon verbraucht wurde, sonst erleben Sie am Ende des Sprints eine Überraschung.

Lösung 4: Ursachen beheben, Qualität verbessern

Diese Lösung wird als Nummer 4 vorgestellt, weil die ersten drei in logischer Reihenfolge stehen, wenn Sie versuchen, den Schaden zu begrenzen, aber am Ende wollen Sie das Wichtigste von allem tun: Probleme beheben, damit sie behoben bleiben, Qualität einbauen, damit Sie überhaupt keine Notfälle haben! Das ist etwas, das wir ohnehin tun sollten und das nicht nur bei agilen Projekten der Fall ist: Sie sollten dies bei jedem Projekt tun! Aber es gibt noch eine weitere Pufferregel, die in diesem Zusammenhang von Bedeutung ist (diese Regel verdanken wir Jeff Sutherland, ich habe sie bei unseren CSM-Schulungen gelernt). Puffer-Regel 2: Wenn Sie den Puffer überlaufen lassen, brechen Sie den Sprint ab. Wenn Sie derartige Probleme haben, dass Sie nicht einmal die Notfallarbeit auf einen kleinen Puffer beschränken können, haben Sie kein Recht, mit dem Einbau von Funktionen voranzukommen. Brechen Sie ab, nutzen Sie den Sprint, um die zugrunde liegenden Ursachen zu beheben, und versuchen Sie es im nächsten Sprint erneut. Zufälligerweise wirkt die Pufferregel 2 auch Wunder bei all jenen Stakeholdern, die versuchen, ihre eigene Agenda zu "verbessern": "Wollen Sie wirklich, dass dieses Problem jetzt behoben wird? Das Team schätzt, dass es sich um zwei Arbeitspunkte handelt, und das würde den Puffer überlaufen lassen. Wir müssten den Sprint abbrechen und Sie würden auch die anderen User Stories nicht bekommen, um die Sie gebeten haben! Oh... ähm. Nun, ich denke, das ist kein so großes Problem..." (Und das war es nicht... Wahre Geschichte!).

Extra: Die richtige Größe des Teams

Die Größe des Teams ist kein zentrales Thema bei der Bewältigung von Notfällen, aber ein Faktor, den Sie berücksichtigen sollten. Ein kleines Team ist leistungsfähiger, weil es weniger Overhead hat, aber es ist weniger robust gegen den Verlust von Mitgliedern. Ein kleines Team ist weniger widerstandsfähig gegen Dinge wie Krankheit oder etwas, das ein Teammitglied wegzieht, wie z.B. Produktionsnotfälle. In einem 10-köpfigen Team bedeutet der Verlust einer Person "nur" einen Produktivitätsverlust von etwa 10 % (dies ist natürlich eine vereinfachte Berechnung, die davon ausgeht, dass alle Teammitglieder sofort ersetzt werden können), in einem Drei-Personen-Team würde der Verlust derselben Person bereits satte 33 % bedeuten! Der Sweet Spot liegt bei 7-9 Personen. Klein genug, um die Gemeinkosten zu senken, groß genug, um einen gewissen Produktionsausfall aufzufangen.

Und schließlich... erwägen Sie den Einsatz von Kanban anstelle von Scrum

Wenn Sie feststellen, dass Ihr Team mehr Wartungsarbeiten als "neue Dinge" durchführt, könnten Sie stattdessen Kanban verwenden. Der Grund dafür ist, dass die Granularität von Kanban Stories und nicht Sprints sind. Wenn es eine Produktionsnotwendigkeit gibt, ist die Wartezeit, bis sie abgeholt wird, bereits von Haus aus kürzer. Bei Kanban geht es um den Fluss, während es bei Scrum um Iterationen geht. Die beiden Stile liegen so nahe beieinander, dass ich schon erlebt habe, wie ein Scrum-Team in den "Flow-Modus" überging, als es sich verkleinerte und nur noch Wartungsarbeiten durchführte, und dann wieder zu Scrum zurückkehrte, als eine neue Version geplant war und es sich wieder vergrößerte.

Fazit

Jedes agile Team muss sich mit allem befassen, was es neben seiner "normalen" Arbeit in die freie Wildbahn entlassen hat. Sie können mit Notfällen umgehen, indem Sie eine Triage durchführen, um entweder abzulehnen, zu verschieben oder zu akzeptieren. Sie können einen Puffer einrichten, um einen Teil der Unsicherheit aufzufangen, und schließlich sollten Sie sich die Zeit nehmen, die Anzahl der Notfälle zu reduzieren, indem Sie Qualität einbauen. Wenn Sie feststellen, dass Sie hauptsächlich Wartungsarbeiten durchführen, können Sie Kanban in Betracht ziehen.