The Phoenix Project Simulation

Was ist passiert?...

Jeder kennt das typische Verhalten und die Beschwerden über IT Entwickler, die scheinbar ungetestete Softwarelösungen über den Zaun in die Produktivumgebung werfen und Operations muss den Scherbenhaufen dann auflesen. Auf der anderen Seite beschweren sich die Entwickler über Hindernisse, die Operations Ihnen in den Weg stellt und somit das Deployment verzögern oder/und über die Arbeitslast in Form von lauter kleinen Updates, Problembehebungen, nicht funktionierende Applikationen etc., die ihnen von Operations auferlegt wird.Die zunehmende Durchdringung anderer Geschäftsbereiche durch die IT und das wachsende Verlangen nach immer mehr und schnelleren, kundenorientierten Lösungen, verschärfen die Probleme noch mehr. Als Resultat dessen, wächst die Arbeitsbelastung auf die Entwickler und IT Operations weiter, Arbeitsabläufe stecken fest, IT Projekte scheitern und die Unternehmensleitung ist angesichts verlorener Geschäftsmöglichkeiten und Risiken im Geschäftsbetrieb frustriert. Über dieses Thema haben Gene Kim, Kevin Behr und George Spafford einen hervorragenden Roman geschrieben: „Das Phönix Projekt“ handelt von einer Organisation, die genau diesen Herausforderungen gegenübersteht und diese mittels angewandter DevOps Prinzipien meistert und entscheidende Verbesserungen und einen höheren Geschäftswert erzielt.

Die Simulation

Die Simulation startet mit einem Zeitungsbericht über die dramatische Situation bei Parts Unlimited.

Runde 1

Runde 1 ist eine Übungsrunde. Die Teilnehmer erhalten einige Projekte, Features und Probleme, damit das Team langsam, mit nur geringem Arbeitsaufwand, starten kann.

Runde 2

Das Team sieht sich mit einem großen Rückstau an IT bezogenen Problemen wie Incidents von Anwendern aus Sales, HR und Finanzen konfrontiert. Der Arbeitsaufwand ist enorm, jeder ist beschäftigt, aber es scheint keinen Durchblick zu geben, warum etwas benötigt wird und was passiert, wenn etwas nicht fertiggestellt wird. Der IT Support kann die vereinbarten Service Levels nicht einhalten und gleichzeitig stehen ihnen verschiedene Anforderungen aus dem Business gegenüber, Incidents sollen schneller bearbeitet und die geschäftsschädigenden Auswirkungen eines plötzlichen Ausfalls auf das Business verhindert werden. Der Support benötigt Kapazitäten aus dem Entwicklungsteam, um einige der kritischen Incidents zu beheben, aber die Entwickler sind alle in neue innovative Entwicklungsprojekte eingebunden. Die Entwicklungsabteilung wiederum hat Schwierigkeiten, alle Business Features und Projekte fertigzustellen, da Ihnen ein klares Bild für die Prioritäten seitens des Business fehlt und dessen Anforderungen die begrenzte Anzahl an Ressourcen übersteigt. Ein weiteres Problem betrifft das Test Team, welches offenbar viele ernstzunehmende Probleme in den neuen Applikationen oder Systemen findet, die ernste Auswirkungen auf das Business verursachen.

Um diese Situation zu bewältigen, muss das Team einen gleichmäßigen Workflow innerhalb der gesamten Lieferkette schaffen. Sie müssen zusammenarbeiten und als durchgehendes Team funktionieren, welches konkurrierende Arbeitsanforderungen managt und sicherstellt, dass die Arbeit die Lieferkette ohne Engpässe, Verzögerungen oder Nachbesserungen durchläuft. Das Team bewerkstelligt dies durch Kanban-Boards, Post-It´s und guter Kommunikation.

In DevOps Sprache hat das Team den sogenannten „First Way“ entdeckt. Die Ergebnisse aus der Umsetzung des First Way in der Praxis beinhalten, dass ein bekannter Fehler niemals nachgelagerte Bearbeitungsplätze passieren sowie lokale Optimierung niemals eine globale Verschlechterung herbeiführen darf und dabei immer nach einer Erhöhung des Arbeitsflusses gestrebt werden soll.

Nach dieser Runde erfolgt eine Reflexion darüber, was passiert ist, was gut gelaufen ist und was verbessert werden muss. Dabei soll auch herausgefunden werden, wie das mit der DevOps Theorie zusammenhängt und wie die eigene Arbeit durch Anwendung der DevOps Prinzipien verbessert werden kann. Das Team hat dann Zeit, das Gelernte in der nächsten Runde zu implementieren.

Runde 3

Die dritte Runde ist herausfordernder. Der CFO kommt mit einigen ernstzunehmenden SOX-404 Nachlässigkeitsproblemen ins Spiel, die unbedingt gelöst werden müssen. Es scheint auch so, als würden die Löhne nicht pünktlich gezahlt, was Einigkeitsprobleme hervorrufen und in den Schlagzeilen der Zeitung landen könnte. In der Zwischenzeit zeigt sich Retail Operations mehr und mehr besorgt, da das Phönix Projekt erste gravierende Verzögerungen und Probleme aufweist, was auch noch dadurch verschärft wird, dass solche Umsatz-Projekte an die Finanzmagazine kommuniziert wurden. Retail Operations gewinnt den Eindruck, dass die Priorität nicht auf diesem Projekt liegt. Daneben gibt es immer noch den Features- und Probleme-Rückstau aus der Vorrunde, die schnell gelöst werden müssen. Dazu kommen einige neue Projekte aus dem Bereich HR, die pünktlich abgeschlossen werden müssen. Der IT Support hat gravierende Probleme mit den SLAs und das ganze Team erreicht langsam die Belastungsgrenze. Aber der durchgängige Workflow im Team soll die Dinge einfacher machen, sicher?!

Das Team lernt jetzt, wie der Workflow genutzt wird und wie man eine funktionierende Feedback-Schleife in die Lieferkette einbaut — auf Feedback des Kunden reagieren und es sofort für Verbesserungsmöglichkeiten und die Aufrechterhaltung des Workflows nutzen. Die Teams arbeiten immer besser zusammen. Als Ergebnis zeigt sich hoffentlich ein steigender Umsatz und ein Anstieg des Aktienkurses. 

Am  Ende der Runde erfolgt wieder eine Reflexion, die Betrachtung der DevOps Prinzipien und die Identifizierung von Verbesserungsmöglichkeiten für die nächste Runde.

In DevOps Sprache hat das Team nun den „Second Way“ entdeckt. Die Ergebnisse des Second Way beinhalten das Verständnis für und die Reaktion auf alle Kunden, intern und extern, die Verkürzung und Verstärkung aller Feedbackschleifen und die Verankerung von Wissen, da wo es gebraucht wird.

Runde 4

Die letzte Runde ist gleichzeitig die wichtigste. Sie ist die letzte Möglichkeit, um finanzielle Aktivitäten und Projekte in den verschiedenen Teams von Operations und Entwicklung zu planen. Jetzt geht es darum, die richtigen Prioritäten zu setzen und die richtigen Entscheidungen zu fällen. Das Team muss jetzt unbedingt lernen, wie die kleinen Feedbackschleifen in die einzelnen Schritte im Workflow zu integrieren sind. Also nicht erst am Ende der Runde testen mit dem Risiko, dass ein Change nicht genehmigt  und somit Nacharbeiten und geschäftskritische Projektverzögerungen kreiert werden.

In DevOps Sprache hat das Team nun den „Third Way“ entdeckt. Beim Third Way geht es darum, eine Kultur zu schaffen, die zwei Dinge unterstützt und fördert: kontinuierliches Experimentieren, welches die Inkaufnahme von Risiken und das Lernen aus Erfolg und Scheitern erfordert; und ein Verständnis dafür, das Wiederholung und Übung die Voraussetzung für Beherrschung ist. 

Am Ende der Runde wird der ganze Tag noch einmal betrachtet. Was haben die Teilnehmer gelernt? Was können sie in ihrem Arbeitsalltag nutzen?

Ziel des Seminars

Parts Unlimited steckt in Schwierigkeiten. Zeitungsberichte haben die schlechten finanziellen Erträge des Unternehmens offengelegt. Der einzige Weg, nicht nur die Firma zu retten, sondern sie auch wieder wettbewerbsfähig und rentabel zu machen ist das „Phönix Projekt“. Es steht für eine, durch die IT ermöglichte, Geschäftsumwandlung bei der Retail Operations der Geschäftseigentümer des Projekts ist. Der Vice President von IT Operations wurde gebeten, die Leitung der IT Abteilung zu übernehmen und den Erfolg des Phönix Projekts sicherzustellen. Aber er sieht sich einem gewaltigen Arbeitsaufwand gegenüber, einem riesigen Rückstand an Problemen, Features und Projekten. Die Teilnehmer agieren in verschiedenen Rollen der Firma Parts Unlimited. Man kann als Retail Operations, Personalabteilung oder Buchhaltung fungieren und somit das Geschäft der Firma, inklusive laufender Projekte verkörpern. Oder man agiert als VP von IT Operations bzw. als eines der Mitglieder seines IT Teams, welches die Applikationen entwickeln und IT Probleme lösen muss. Die Herausforderung hierbei ist, dass die DevOps Prinzipien angewandt und sie auf die Simulation übertragen werden müssen. In vier Runden wird an den IT Projekten und Problemen gearbeitet und es soll sichergestellt werden, dass das Phönix Projekt fristgerecht abgeschlossen wird.

Aber Vorsicht ist geboten, das Business wartet immer wieder mit neuen Ideen und Anforderungen oder externen Entwicklungen außerhalb Ihres Einflussbereiches auf und streut hier und da Sand ins Getriebe.

Über DevOps

In DevOps spricht man von „3 Wegen“. Sie beschreiben die Werte und Philosophien, welche Prozesse, Prozeduren und Praktiken sowie vorgeschriebene Schritte gestalten. Der erste Weg betont die Leistung des gesamten Systems im Gegensatz zu bestimmten Arbeits-Silos oder Abteilungen— dies kann dabei so groß wie ein ganzer Bereich (Entwicklung oder IT Operations) oder so klein wie ein einzelner Mitarbeiter (Entwickler, Systemadministrator) sein. Im zweiten Weg geht es um das Schaffen von Feedbackschleifen. Das Ziel von fast jeder Prozessverbesserung ist es, Feedbackschleifen zu verkürzen und gleichzeitig zu verstärken, sodass nötige Korrekturen kontinuierlich erbracht werden können. Beim dritten Weg  geht es darum, eine Kultur zu schaffen, die zwei Dinge unterstützt und fördert:

• kontinuierliches Experimentieren, welches die Inkaufnahme von Risiken und das Lernen aus Erfolg und Scheitern erfordert;
• und ein Verständnis dafür, das Wiederholung und Übung die Voraussetzung für Beherrschung ist.

Für wen ist die Schulung geeignet?

Zielgruppe

Diese Simulation ist für alle Rollen und Mitarbeiter im Bereich Business, IT Development und IT Operations geeignet, welche die Prinzipien von Lean, Agile und ITSM zur Verbesserung ihrer IT Services oder zur Wertsteigerung ihrer IT-Lösungen anwenden wollen. Diese Simulation ist auch für Unternehmen geeignet, die eine derartige Kultur entwickeln wollen, um eine bessere Zusammenarbeit und als Ergebnis dessen ein schnelleres und fehlerärmeres Deployment ihrer Lösungen erreichen wollen. Die Simulation kann genutzt werden für:

• Awareness-/ Aufklärungsprogramme
• Assessments
• Teambuilding