Agiles Krisenmanagement erklärt - Teil 2

Dieser Blogpost vervollständigt das Modell, das ich verwende, um mir ein mentales Bild von einer neuen Krisensituation zu machen, wenn ich in eine solche gerate. Ich verwende es, um die tausenden von neuen Informationen zu strukturieren und zu priorisieren, die ich verarbeiten muss, um mir ein gutes Bild von dem zu machen, womit ich es zu tun habe. In der Tat ist es ein Werkzeug, um einen schnellen und nützlichen Einblick in die aktuelle Krisensituation zu bekommen, der mir hilft, all die verschiedenen Inputs zu einem kombinierten und nützlichen Bild von dem, was vor sich geht, zu konsolidieren. Dieses Bild hilft mir, mit den Beteiligten zu kommunizieren und die erforderlichen Maßnahmen festzulegen. In meinem vorherigen Beitrag wurden die Grundlagen des Modells erläutert. In diesem Beitrag wird der Rest der Verwendung des mentalen Bildes beschrieben.

Abbildung: Burms Tempel Erinnern Sie sich an die Essenz des ersten Blogposts: Ein starker Tempel ist auf festem Boden und einem starken Fundament gebaut; ebenso ist ein erfolgreiches Projekt auf engagierten Projektmitgliedern und klarer Verantwortung aufgebaut. Wenn Sie ein Projekt bewerten wollen, beginnen Sie mit der Untersuchung von Engagement und Verantwortung. Achten Sie dabei auf zwei Dinge

• Sind 'Veränderung' und 'Struktur' gut ausbalanciert? So haben die Menschen die Möglichkeit, ihr Engagement zum Ausdruck zu bringen.
• Werden Führung und Verantwortung effektiv umgesetzt? Damit die Menschen in ihrer Kraft handeln und sich frei fühlen, das zu tun, was ihnen richtig erscheint?

Nutzen Sie die obigen Fragen, um die Grundlagen einer Lösung für jede Krise zu beurteilen. Haha! Grundlagen sind großartig, aber nicht alles; also lassen Sie uns weitermachen! TEIL III: DER TEMPELFUSSBODEN - Eine funktionierende Wertschöpfungskette Waren Sie schon einmal in einem echten Tempel? Das erste, was Ihnen auffällt, ist der wunderbare Fußboden. Die Schönheit eines erfolgreichen Projekts liegt in der eleganten Effektivität einer funktionierenden Wertschöpfungskette, und zwar in zwei Dimensionen: der funktionalen Produktdimension und der Dimension des virtuellen Eigentums. Wenn Sie eine Wertschöpfungskette vom funktionalen Standpunkt aus betrachten, bedeutet das, dass Sie das Minimalprodukt von Ende zu Ende zum Laufen bringen müssen. Sobald dies geschehen ist, kann es nur noch besser werden. Es kann einige Mühe kosten, sich ein Bild von diesem Bereich zu machen. Fachwissen ist hilfreich, also sprechen Sie mit Leuten, die es haben, und schauen Sie sich gemeinsam die Projektgeschichte an. Der Product Owner ist ein guter Anfang. Werfen Sie einen Blick auf die Storymap und wenn es keine gibt, erstellen Sie eine. Sie könnten auch gemeinsam mit dem Produktverantwortlichen Szenarien für die Interaktion zwischen den Benutzern entwerfen. Beginnen Sie mit dem "Happy Flow" und sehen Sie sich an, welche Funktionen darin bereits enthalten sind und was noch hinzugefügt werden muss. Finden Sie heraus, was das Projekt davon abhält, eine Ende-zu-Ende-Wertschöpfungskette zu vervollständigen. Beispielfragen, die Ihnen einen Vorsprung verschaffen können:

• Können Sie mir erklären, wie die minimale End-2-End-Funktionalität aussieht?
• Was ist der Wert dieser Funktionalität für den Kunden?
• Was wird benötigt, um den ersten Satz von Ende-zu-Ende-Funktionen zu vervollständigen?

Sie müssen die Verantwortung für die Wertschöpfungskette übernehmen und dafür, was mit ihr im Laufe des Projekts geschieht. Wenn Ihr Programm in gemeinsamen Umgebungen läuft, z.B. in gemeinsamen Test- oder Abnahmeumgebungen mit anderen Projekten, sollten Sie herausfinden, was für Ihr Programm Priorität hat. Implementieren Sie von da an eine Art von Flugkontrollmechanismus. In gemeinsam genutzten Umgebungen ist es oft so, dass der Betrieb erwartet, dass sich die liefernde Partei koordiniert, und die liefernde Partei erwartet, dass sich der Betrieb koordiniert. Das Ergebnis ist ein großes Durcheinander, das Sie bereinigen müssen. Um sich ein Bild davon zu machen, was vor sich geht, sprechen Sie mit Operations. Erkundigen Sie sich, wie oft die Operationsabteilung Probleme bei der Bereitstellung hat und woher sie kommen. Es versteht sich von selbst, dass dieser Punkt in Ihrem Modell umso wichtiger und komplexer wird, je mehr Drittanbieter in Ihrer Wertschöpfungskette tätig sind. Fragen, die ich gerne verwende, um mir ein Bild von diesem Teil des Modells zu machen:

• Wer verwaltet die Zeitslots und Prioritäten in den verschiedenen Umgebungen?
• Wie lange dauert es, eine Bereitstellung durchzuführen? Welche Art von wiederkehrenden Problemen treten auf?
• Welche Kollegen arbeiten in der Wertschöpfungskette direkt vor und nach Ihnen?
• Was ist als Ausgangspunkt der Wertschöpfungskette zu betrachten? Was das Ende?

TEIL IV: Vier majestätische Säulen, die das Dach tragen Es gibt vier Säulen, die das Dach unseres Tempels tragen: 1. Erstellen Sie ein einziges verwaltetes Backlog: Ein einziges verwaltetes Backlog ist unabdingbar. Entgleiste Projekte zeigen oft eine Vielzahl von Spezifikationen und Prioritäten für das gesamte Programm und seltsame Konstrukte, um diese zu verwalten. Bringen Sie das Ganze zurück zu einem einzigen Product Owner und konkreten Prioritäten. Erarbeiten Sie das Backlog in schnellen Design-Workshops mindestens für die nächste Version und schätzen Sie es mit dem gesamten Team. Um herauszufinden, ob die Product Owner aufeinander abgestimmt und fokussiert sind, prüfen Sie, ob es ein einheitliches Backlog oder eine Storymap gibt und ob es eine Art Chief Product Owner gibt. Prüfen Sie auch, ob der Chef eine klare Vision für das Produkt (insbesondere das minimal lebensfähige Produkt) hat und das Mandat, entsprechende Entscheidungen zu treffen. Ein guter zweiter Indikator ist die Frage, ob die Product Owner die zentralen Release-Ziele diskutieren und nicht ihre eigenen. Wie oft überprüfen sie gemeinsam, ob diese zentralen Ziele auch erreicht werden? Selbst wenn es ein klares zentrales Backlog und Ziele gibt, können die Product Owner in der Praxis immer noch getrennt arbeiten und hauptsächlich ihre eigenen Gassen säubern. 2. Kennen Sie Ihre Geschwindigkeit: In Programmen mit mehreren Teams ist es oft schwierig, mit der Geschwindigkeit zwischen den Teams zu arbeiten, wenn Sie diese auf ein zentrales Release- und/oder Product Backlog beziehen wollen. Aber in einem Programm, das unter Druck steht, ist es unerlässlich, dass Sie diese Informationen erhalten, um zu sehen, welchen Umfang Sie unter den gegebenen Umständen und der aktuellen Liefergeschwindigkeit fertigstellen können. Um zu überprüfen, wie es um die Geschwindigkeit bestellt ist, fragen Sie, wie die Teams ihre Schätzungen vornehmen und wer was im Hinblick auf das Endprodukt schätzt. Außerdem können Sie fragen, welcher Bezugspunkt verwendet wird und ob dieser für alle Teams derselbe ist. Im letzteren Fall sehen Sie das normalerweise. Abhängig von der Antwort auf die obigen Fragen müssen Sie möglicherweise eine Reihe von Dingen anpassen, um eine gemeinsame Geschwindigkeit zu erreichen. 3. Arbeiten Sie Ende-zu-Ende: Bei der Planung sollten Sie darauf achten, dass keine losen Enden herumliegen. Dies ist ein großes Projektrisiko. Geschwindigkeit in Bezug auf Planungsinformationen ist nur dann etwas wert, wenn sie auf Ende-zu-Ende-Ergebnissen der Teams basiert. Also von den Anforderungen zu den (fertigen) Produkten. Um zu überprüfen, ob die Teams und das Programm als Ganzes in jedem Sprint Ende-zu-Ende arbeiten, sehen Sie sich die Programmplanungsphasen an und sprechen Sie mit den Programm- und Projektmanagern. Es könnte sein, dass sie andere Testtypen durchführen wollen, nachdem die "Entwicklungsarbeit" "abgeschlossen" ist... Meine Faustregel lautet: Je dünner die Definition von "abgeschlossen" ist, desto mehr Risiken werden an das Ende des Programms verlagert, und desto schwieriger wird es sein, dieses Risiko zu mindern und die Krise zu zähmen. 4. Beginnen Sie mit der kontinuierlichen Verbesserung auf Programmebene in einer PTC (Program Transition Community). Ich bin sicher, Sie haben alle schon von Enterprise Transition Communities oder ETCs gehört. Genau wie bei einer agilen Umstellung ist auch die Zähmung einer Projektkrise keine einmalige Angelegenheit, sondern eine kontinuierliche. Es ist eine Illusion, alle Probleme auf einen Schlag zu lösen. Bei entgleisten Programmen ist eine kontinuierliche Verbesserung auf Programmebene oft nicht vorhanden, und Sie können sich nicht allein auf die Selbstverbesserung der einzelnen Lieferteams verlassen. Einfache Nachschlagewerke können Ihr mentales Bild verbessern. Sehen Sie nach, ob es ein Standup auf Programmebene gibt und ob Probleme und Hindernisse explizit gemacht werden. Sehen Sie nach, ob es Aufzeichnungen über Verbesserungen usw. gibt. Um Hinweise auf die Basis für Verbesserungen auf dieser Ebene zu erhalten, sehen Sie sich die Lösungszeit für Hindernisse an, die nicht innerhalb der Teams gelöst wurden. TEIL V: DAS DACH - Priorisierte Ziele und die ewige Glückseligkeit von: transparenten, zuverlässigen Programmergebnissen Die Säulen halten das Dach. Der Hauptteil des Tempels, der auf die ewige Glückseligkeit transparenter, zuverlässiger Programmergebnisse hinweist. Das Dach steht also für die Priorität der Programmziele. Bei vielen Krisenprogrammen sehen wir, dass es mehrere Programmziele gibt, die gleichzeitig erreicht werden sollen. Die vom Lenkungsausschuss festgelegten Ziele müssen durch Priorisierung gestrafft werden. So wie das Dach des Tempels spitz zuläuft, sollte alles, was im Programm zu einem bestimmten Zeitpunkt getan wird, zum Ziel mit der höchsten Priorität führen. Ein Ziel nach dem anderen sorgt dafür, dass der Fokus im Programm optimal bleibt und garantiert die schnellsten Ergebnisse. Jeder kann seine eigenen Unterziele haben, aber sie sollten immer einen direkten Beitrag zu dem zentralen Ziel mit der höchsten Priorität leisten. Um sich einen Überblick über diesen Bereich zu verschaffen, stellen Sie verschiedenen Personen in verschiedenen Ebenen der Programmhierarchie die gleiche Frage: Was ist im Moment unsere Hauptpriorität/unser Hauptziel? Wenn Sie unterschiedliche Antworten erhalten, könnte es ein Problem geben (versuchen Sie zu fragen, warum, um herauszufinden, ob die Antworten zum selben Ziel führen), wenn die Leute nicht in der Lage sind zu antworten, haben Sie ebenfalls ein Problem. Achten Sie auch darauf, ob die Ziele richtig kommuniziert und wiederholt werden. In Gruppensitzungen, in schriftlichen Sitzungsprotokollen und vor allem an den Arbeitsplätzen der Mitarbeiter. Fazit Der erste wichtige Schritt zur Lösung einer Krise besteht darin, den Kontext und die Situation zu verstehen. Das ist leicht gesagt, aber nicht immer einfach zu bewerkstelligen. In komplexen Situationen ist ein Modell, das eine Struktur für die Priorisierung von Informationen und den Aufbau eines mentalen Bildes bietet, von großer Hilfe. Burms Tempel ist ein solches Modell. Nächste Schritte Der nächste Schritt besteht darin, zu bestimmen, welche Maßnahmen ergriffen werden müssen, um die aktuelle Situation, die Sie mit Burms Tempel modelliert haben, zu entschärfen. Von hier aus können Sie und Ihr Kunde sich austauschen und diese gemeinsame Vision in einen umsetzbaren Plan umwandeln, der Sie aus dem Krisenmodus zu transparenten, zuverlässigen Programmergebnissen führt........ PS Nochmals vielen Dank Geert!