Das Phönix Projekt Schulung

Lernziele

• Wie wende ich DevOps Prinzipien in einer realen Situation an?
• Wie finde ich die richtige Balance zwischen Lieferung der SLA Anfordungen und planmäßiger Projektfertigstellung?
• Wie kann ich erfahren, wie DevOps Wert für mein Business schafft?
• Wie kann ich die Effektivität und Effizienz der IT Abteilung verbessern?
• Wie kann ich einen besseren Arbeitsfluss in meinen Teams erzeugen?
• Wie kann ich meine Mitarbeiter ausbilden, damit sie in einer DevOps Umgebung agieren können?
• Wie kann ich dem Business seine Verantwortlichkeiten und seinen Beitrag zum Erfolg von IT-Projekten aufzeigen?

Ziel des Seminars Das Phönix Projekt

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 deines Einflussbereiches auf und streut hier und da Sand ins Getriebe.

Das Phönix Projekt: 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 kannst du in deinem Arbeitsalltag nutzen?