Diese Dimensionen können nicht allein für sich betrachtet werden, auch gerade im Hinblick auf die Teamentwicklung ist es von Bedeutung, zu verstehen, wie ein Team wann mit welcher Methode am besten zum Ziel kommt. Scrum hat fünf Werte, wobei einer davon Fokus ist, was dahingehend interpretiert werden kann, dass ein Team für einen definierten Zeitraum an einem Produkt arbeitet und dieses weiterentwickelt, um Value für den Kunden zu generieren. In dieser Zeit kann das Team nicht im dritten Horizont arbeiten und mittels Design Thinking mögliche Kundenprobleme validieren, welche in zukünftige Lösungen überführt werden. Dies ist eine legitime Sichtweise auf die Idee von Scrum. Das bedeutet im Umkehrschluss, dass das Produkt zu einem gewissen Zeitpunkt nicht mehr weiterentwickelt wird bzw. nicht mehr so stark, sondern in einen stabilen Betrieb übergeht, die Überführung in Horizont eins und ggf. auch eine Übergabe an ein anderes Team. Drei Dimensionen

Die Zielsetzung in diesem Prozessschritt ist dahingehend beschrieben, in beschränkter und kurzer Zeit auf Grundlage des Projektmandates hinreichend Informationen zusammenzutragen, welche es dem Lenkungsausschuss ermöglicht die Projektinitiierung freizugeben. Das Projektmandat ist noch kein Managementprodukt, sondern lediglich eine Idee oder Anfrage vom Unternehmensmanagement (Ebene vier), welche schriftlich oder mündlich erfolgt. Zusammen mit dem Lenkungsausschuss erstellt der Projektmanager einen Business Case Entwurf, der zum einen als Entscheidungsgrundlage und zum zweiten als Basis für den späteren Business Case dient, welche nach erfolgter Projektfreigabe in der Initiierungsphase erstellt wird Steuern einer Phase

Wer glänzen will, kennt möglichst viele BuzzWords aus dem Agilen Umfeld, Design Thinking, Scrum, Lean StartUp oder Design Sprints, um nur ein paar zu nennen. Der Erfahrung nach funktionieren diese Methoden je nach Kontext gut oder schlecht. Leider ist es meist so, dass vielen der Kontext nicht bekannt ist und uU angenommen wird, man könnte die Methoden einfach austauschen, um zu einem gleichen Ergebnis zu kommen, dies ist mit Nichten der Fall. Drei Dimensionen gibt es hierbei zu beachten, eine zeitliche, eine kontextspezifische und eine deterministische. Zu den BuzzWords

Auf der Ebene lenken finden jene Tätigkeiten statt, welche im Prozess „Lenken eines Projektes“ dargelegt werden, dazu zählen „Initiierung freigeben“, „Projekt freigeben“, „Phasen- oder Ausnahmeplan freigeben“, „Ad-hoc  Anweisungen geben“ und „Projektabschluss freigeben“. Diese Tätigkeiten werden von Lenkungsausschuss über den gesamten Projektlebenszyklus durchgeführt. Alle weiteren Tätigkeiten hat der Lenkungsausschuss an den Projektmanager oder weitere Beteiligte delegiert. Lenken eines Projektes

Die Herausforderungen, welche dabei bestehen, ein Team zu etablieren, wie es in der vorangegangenen Kolumne angedacht war, bedarf mehr Wissen über Teamphasen, Lernphasen und Konfliktmanagement. Ist es das Unternehmens- und Teamziel, Scrum einzuführen, kann die Aufgabe dieser Teamentwicklung Richtung Scrum Master gehen. Für den Scrum Master ist es entscheidend, hierbei zu verstehen, wie Menschen mit Veränderungen umgehen und wie sie sich als Team neu finden. Ein Scrum Team zu etablieren ist für die meisten eine Veränderung, welche unter Umständen nicht von allen als notwendig erachtet wird. Teams und deren Entstehung

Im jetzigen Teil der Kolumne möchte ich den nächsten Prozess „Initiieren eines Projektes“  beleuchten, welcher dazu dient, alle nötigen Aktivitäten durchzuführen, welche für das dann folgende Projekt benötigt werden. Am Ende steht eine Projektleitdokumentation zur Verfügung, welche dem Lenkungssauschuss als Entscheidungsvorlage dient, um das Projekt freizugeben oder abzulehnen. Nach der Freigabe des Projektes durch den Lenkungsausschuss in der Vorbereitungsphase (SU), folgt die erste und obligatorische Managementphase im Rahmen eines PRINCE2® Projektes. Innerhalb dieser Phase werden Aktivitäten durchgeführt, welche dazu dienen, dass Projekt auf ein gutes und solides Fundament zu stellen. Initiieren eines Projektes

Die Definition von Teams ist je nach Kontext vielschichtig und kann aus verschiedenen Blickrichtungen betrachtet werden. Das Agile Fluency Modell hat eine Sichtweise darauf eröffnet, was geschehen muss, damit ein Team seinen Aufgaben im Kontext eines Unternehmens zielgerichtet nachkommen kann. Zum weiterten Verständnis kann mittels des Drei Horizonte Modells verstanden werden, was Wert und Wertlieferung für Teams bedeutet. Die Zusammensetzung von Teams und die angemessene Einbettung in ein Unternehmen ist mit verschiedenen Herausforderungen verbunden. Im Kontext agiler Produktentwicklung ist die Herangehensweise und die Definition von Teams wie folgt. Das Scrum Team ist cross-funktional und selbstorganisiert. Das richtige Verständnis von Selbstorganisation ist von Bedeutung, damit ein Team im Kontext von Scrum zielgerichtet arbeiten kann und Wert im beschriebenen Sinne liefern kann. Teams und wie Sie sein können

In dem Prozessschritt “Vorbereiten eines Projektes” wird durch den Projektmanager mittels spezifischer Aktivitäten geprüft, ob es sinnvoll ist, für eine Projektinitiierung entsprechend Ressourcen bereitzustellen und das Projekt zu starten.  Nachdem das Projektmandat schriftlich oder auch mündlich übermittelt wurde, folgt die erste Aktivität des Prozesses „Vorbereiten eines Projektes“, die Ernennung des Auftraggebers und des Projektmanagers. Die zwei wichtigsten Verantwortungen im Projekt sind die Ergebnisverantwortung und die Durchführungsverantwortung für das Projekt. Hierbei ist der Auftraggeber, welcher durch das Unternehmensmanagement ernannt wird, ergebnisverantwortlich. Ergebnisverantwortlich bedeutet, er vertritt die Idee und ist für das Projektendprodukt (das Ergebnis) verantwortlich. Vorbereiten eines Projektes

Das Agile Fluency Modell, welches in den vergangenen Teilen beleuchtet wurde, öffnet den Raum, für weitere tiefergehende Gedanken zu den verschiedenen Zonen. Die Zonen eins und zwei befassen sich mit der Grundsteinlegung für Teams, welche die ersten Wege gehen agil zu arbeiten und sich entsprechend auf den Value, also den Wert welchen sie für das Unternehmen erbringen, zu fokussieren und zu liefern. In der dritten Zone dem „Optimize Value“ liegt das Augenmerk darauf, diesen im Besonderen zu verbessern und zielgerichteter zum Kunden zu bringen. Hierfür ist es nötig, dass verstanden wird, was Value überhaupt bedeutet und wie dieser zu messen ist, damit er schlussendlich auch optimiert und verbessert werden kann. Value im Drei Horizonte Modell

Neben den sieben Grundprinzipien und Themen, beinhaltet PRINCE2® sieben Prozesse, welche Aktivitäten beschreiben, die für ein erfolgreiches Projektmanagement nötig sind. Diese Aktivitäten finden auf verschiedenen Managementebenen statt. Innerhalb einer PRINCE2® Projektorganisation gibt es drei dieser Managementebenen, die Ebene Lenken, die Ebene Managen und die Ebene Liefern. Die meisten Prozesse in PRINCE2® beschreiben Aktivitäten auf der Ebene Managen, nur zwei Prozesse entfallen auf die Ebene Lenken und nur einer auf die Ebene Liefern. Prozesse in PRINCE2®

Teams verstehen ihre Rolle im gesamten Unternehmenssystem und arbeiten daran, dieses Gesamtsystem, und nicht nur ihr Team, erfolgreicher zu machen. Strengthening Teams unterstützen ihre Organisation auf drei verschiedenen Wegen und Arten. Aspekt eins, sie verstehen ihren Kontext und ihre Bedeutung im Gesamtsystem. Das bedeutet, sie verstehen wie ihr Nutzenbeitrag mit anderen Teams zusammenspielt, um die gemeinsame Unternehmensstrategie zu unterstützen. Die Arbeit der Teams wird laufend verbessert, um die Unternehmensstrategie besser, erfolgreicher zu erfüllen. Zum Artikel

Unter dem Thema „Pläne“ wurde bereits aufgezeigt, wie im Falle einer Ausnahme ein Ausnahmeplan erstellt wird. Als Ausnahme definiert PRINCE2® eine Situation, in welcher eine Abweichung über die vereinbarten Toleranzen hinaus eingetreten ist oder absehbar eintreten wird. Die Ebenen Managen und Liefern haben voneinander getrennte Toleranzen, auf der Ebene Liefern beziehen sich diese zum Beispiel auf die Arbeitspakete, auf der Ebene Managen auf die Phase. Ausnahmen werden jeweils an die nächst höhere Ebene eskaliert. PRINCE2® definiert sechs, entsprechend der PRINCE2® Projektdimensionen, Toleranzbereiche. Toleranzen in PRINCE2®

Die ersten beiden Zonen im „Agile Fluency™ Model“, die Zone „Focusing“ und die Zone „Delivering“ sind ein guter Startpunkt, um Teams und Organisationen in neue Arbeitsweisen zu führen. Hierbei dient die erste Zone im „Agile Fluency™ Model“ den meisten Unternehmen dabei, den Teamgedanken zu verstehen und entsprechend zu fördern. Trotz der Anstrengungen, welche aufgebracht werden müssen, um in der Agile Fluency™ Zone „Delivering“ fluent zu werden, sind die Vorteile essentiell. Teams welche fluent in dieser Zone sind, besitzen die Fähigkeit, Software zu liefern, welche weniger Fehler und weniger technische Schulden aufweist. Als nächstes soll die Agile Fluency Zone „Optimizing“ näher betrachtet werden, eine Zone, welche sich dadurch kennzeichnet, dass Teams, welche in dieser fluent sind, Entscheidungen bezüglich ihres Produktes eigenverantwortlich treffen. Agile Fluency Optimizing

Durch den Produktzentrierten Ansatz, wird die Möglichkeit eröffnet, dass sich PRINCE2® auch mit agilen Vorgehen wie Scrum kombinieren lässt, die genauen Vorgehensweisen werden in PRINCE2® Agile erläutert. Der erste Schritt im Planungsprozess ist benannt ‚Plan entwerfen‘, wobei es hier nicht um einen Entwurf im eigentlichen Sinne geht. In diesem Schritt wird sichergestellt, dass alle notwendigen Voraussetzungen berücksichtigt und standardisiert sind. Der Output aus diesem Schritt kann als Planungsrichtlinie für alle folgenden Pläne im laufenden Projekt gesehen werden, er muss daher auch nicht für jeden Plan wiederholt werden. Anpassungen an den Richtlinien sind weiterhin vorgesehen und erwünscht, da sie dem PRINCE2® Grundprinzip ‚Lernen aus Erfahrung‘ entsprechen. Planen in PRINCE2®

Eine agile Transformation wird in vielen Kontexten zum Selbstzweck, ohne Beachtung, was der Kunde am Markt wirklich benötigt. Das Agile Fluency™ Modell hilft dabei, Transparenz zu schaffen, welche agilen Transitionen wirklich nötig sind, um hinreichend für den Markt transformiert zu sein. Wenn der Kunde im Markt die Lieferungen gar nicht benötigt oder verarbeiten kann, hat das Team zu viel Zeit und Ressourcen in die agile Transformation gesteckt, um eine Woche Sprintlänge zu erreichen. Es ist somit von Bedeutung zu verstehen, was der Markt benötigt, die Reaktion des Marktes zu reflektieren (inspect) und entsprechend sinnvoll anzupassen (adapt), dies geschieht in der Zone zwei des Agile Fluency™ Modells, der Zone „Delivering“. Agile Fluency™ – Delivering

Änderungen gehören zum Tagesgeschäft in vielen Projekten, sei es durch geänderte Kundenwünsche oder oft auch durch sich ändernde Marktbedingungen. Entscheidend ist, dass sämtliche Änderungen, auch wenn dies ein Mehraufwand für den Projektmanager bedeutet, geprüft und entsprechend priorisiert werden müssen. Das PRINCE2® Thema Änderungen zeigt auf, wie Änderungen gesteuert und durchgeführt werden, wer im Besonderen welche Verantwortungen trägt und wie das Konfigurationsmanagement für ein Projekt aufgesetzt werden muss. Änderungen in PRINCE2®

Selten wird in Betracht gezogen, welche Vorteile agile Ansätze bieten, Agilität wird ausschließlich eingeführt, um sich agil nennen zu können. Mit dem „Agile Fluency™ Model“ werden die agilen Ansätze in Vordergrund gestellt. Die vier Zonen, die das „Agile Fluency™ Model“ vorschlägt beschreiben Vorteile, was getan werden muss und welche Voraussetzungen es geben muss, damit die Zone entsprechend gehalten werden kann. Besonders die Voraussetzungen sind zu betrachten und im Unternehmen kritisch zu hinterfragen. Agile Fluency™ – Focusing

Die Risikobetrachtung in PRINCE2® ist ähnlich zu klassischen Projektmanagement Methoden, wird aber nicht immer mit der nötigen Sorgfalt betrachtet. Für das Prinzip einer fortlaufenden geschäftlichen Rechtfertigung, ist eine genaue Betrachtung unerlässlich. Als Risiko ist hierbei ein Ergebnis definiert, dessen Eintreten ungewiss ist, was bei Eintritt aber Einfluss auf das Projekt haben wird. Riskiobetrachung in PRINCE2®

In dieser Kolumne möchte ich mich dem Agile Fluency™ Ansatz widmen, um eine Idee zu skizzieren, wie dieser bei einer Agilen Transformation helfen kann. Agile Fluency™ ist ein Model, mit welchem herausgefunden werden kann, wie Teams in Bezug auf Agile Methoden aufgestellt sind. Nicht immer muss es das Ziel sein, bei einer agilen Transformation, alle möglichen Methoden,Arbeitsweisen und Praktiken anzuwenden. Vielmehr ist es entscheidend, herauszufinden, wo das Team gerade steht und mit welchen Herausforderungen es zu kämpfen hat. Hierbei gilt es, die gerade schmerzhaftesten Herausforderungen transparent zu machen und Lösungen hierfür zu finden. Agile Fluency™

PRINCE2® ist vom Grundgedanken her Produktzentriert, was auf die Qualität bezogen bedeutet, ein Produkt nach den gestellten Anforderungen zu liefern. Hierbei ist unter Anforderungen das zu verstehen, was zum Beispiel zwischen Auftraggeber und Projektmanager vereinbart wurde. PRINCE2® beschreibt im Thema Qualität, alle notwendigen Schritte bzw. Verfahren, welche sicherstellen sollen, am Ende einer jeder Phase und am Ende des Projektes, ein Produkt zu übergeben, was den geforderten Anforderungen und der vereinbarten Qualität entspricht. Qualität in PRINCE2®

Eine Transformation hin zu einem Unternehmen, was vornehmlich nach agilen Methoden / Ideen arbeitet, ist eine Herausforderung auf mehreren Ebenen. Die Idee, eine Methode wie zum Beispiel Scrum in allen Bereichen eines Unternehmens zu etablieren, erscheint sehr charmant. Die Annahme hierbei ist, dass sämtliche Bereiche besser und schneller werden, sobald agil gearbeitet wird. Dass erste Missverständnis dabei ist, dass agil mit Nichten ad hoc bedeutet. Genau dies ist oft die Annahme vom „Management“, jederzeit Änderungen in die einzelnen Teams geben zu können. So richtig transformieren

Jene in PRINCE2® (Commerce, 2009) aufgezeigten Prinzipien bilden die Grundlage für die sieben Themen und die sieben Prozessschritte. Ein Merkmal von Projekten ist die Einzigartigkeit, Projekte unterscheiden sich vom Daily Business. Den Ursprung hat auch PRINCE2® im klassischen Projektmanagement. Agile Entwicklung wird einige Anpassungen nötig machen, ein Schritt welcher bereits erkannt wurde und in PRINCE2® Agile mündet. Zuvor möchte ich die sieben Themen von PRINCE2® beleuchten und bereits aufzeigen, wie diese sich in einen agilen Kontext einfügen können. Jene sieben Themen sind, Business Case, Fortschrittsmessung, Organisationsstruktur, Pläne, Änderungen, Risiko und Qualität. PRINCE2® Business Case

PRINCE2® entstand in Großbritannien als eine prozessorientierte und skalierbare Projektmanagementmethode. PRINCE2® verfolgt hierbei den Best-Practice-Gedanken, gibt den Projekten und den Projektmanagementteams einen strukturierten Rahmen und mittels des Prozessmodells konkrete Handlungsempfehlungen für jede Phase. PRINCE2® vereint sieben Grundprinzipien, sieben Themen und sieben Prozesse. PRINCE2® bietet sich besonders zur Kombination mit agilen Prozessen an, da PRINCE2® die Anpassung der Themen und Prozesse an den jeweiligen Projektkontext explizit vorsieht. PRINCE2® in Kombination

Water Scrum Fall, wie in der letzten Kolumne erwähnt, ist eine Beschreibung für eine Implementierung von Scrum, in welcher nur das Scrum Team (also Developer, Scrum Master und Product Owner) nach Scrum arbeiten. Bereiche welche davor oder danach involviert sind, arbeiten weiterhin nach klassischen Methoden wie Wasserfall. Eine gemeinsame Verantwortung, auch End to End Verantwortung für ein Produkt wird durch eine derartige Implementierung oft verhindert, da die Teams nicht selbstständig Wert zum Kunden bringen können. Kanban Flight Level

Scrum wie auch Kanban zielen unter anderem darauf ab, die Kommunikation im Projekt in den Vordergrund zu stellen – (Agile Manifesto, 2018) -. Durch eine Verbesserung der Kommunikation erhöht sich die Wahrscheinlichkeit, dass das Produkt und der Produktentwicklungsprozess laufend reflektiert und verbessert werden können. Zielgerichtete Kommunikation und ein festgelegter Prozess allein können dies allerdings nicht allein erfüllen. Hierzu bedarf es auch andere Werte wie z.B. die Transparenz mehr zu stärken. Scrum und Kanban Metriken

Mit dem letzten Prozess „Managen der Produktlieferung ist die Beschreibung von PRINCE2® vollständig. Jetzt möchte ich einige der Ideen aufzeigen, welche PRINCE2® vorschlägt, um PRINCE2® Richtung agiler Ansätze zu rücken. Eines der sieben Grundprinzipien von PRINCE2® ist „Anpassen an die Projektumgebung“. Neben diesem Prinzip eignen sich auch weitere Eigenschaften von PRINCE2®, PRINCE2® auch im Agilen Kontext einzusetzen. Zum Artikel

In der vergangenen Kolumne wurden vier der fünf Events von Scrum eingehend beleuchtet. Ein Ziel der Events aus dem Scrum Framework ist es, die Transparenz im Team und gegenüber den Stakeholdern zu erhöhen. Neben der Transparenz fördern die Events auch Inspect and Adapt, also das ständige Verbessern des Produktes und des Prozesses. Hierbei sind insbesondere das Event Review, welches vornehmlich der Produktverbesserung und das Event Retrospektive, welches vornehmlich der Prozessverbesserung dient, zu benennen. Scrum Artefakte und Rollen

Vier der sieben Prozesse von PRINCE2® konnten wir in den vergangenen Teilen bereits behandeln. Neben „Managen eines Phasenübergangs“ und „Abschließen eines Projektes“, ist noch die Ebene „Liefern“ mit dem Prozess „Managen der Produktlieferung“ offen. Der Ebene liefern werden wir uns in der nächsten Kolumne ausführlich widmen, inkl. der Integration Richtung „Agile Arbeitsweisen“. Im jetzigen Teil werden die Aktivitäten der Prozesse „Managen eines Phasenüberganges (SB)“ und „Abschließen eines Projektes (CP)“ beleuchtet. Zum Artikel

Infrastructure as Code (IaC) in Kombination mit dem DevOps Ansatz ist eine gute Ergänzung, wie genau beides gelingen kann, möchte ich im Folgenden aufzeigen! In einem Satz zusammengefasst kann Infrastructure as Code so verstanden werden: „Im Infrastructure as Code Ansatz werden die gleichen Entwicklungs- und Managementpraktiken verwendet, wie in der Softwareentwicklung“. Das klingt auf den ersten Blick nicht sonderlich innovativ oder neu. Die Hauptvorteile dieser Herangehensweise sind ähnlich wie bei jenen Developern,  welche heute auch bereits so arbeiten. Änderungen, welche ins VCS übergeben werden, sind nachvollziehbar und werden mittels CI / CD automatisch getestet, Veränderungen sind damit weit weniger Risiko verbunden. Zum Artikel

Im Prozess „Steuern einer Phase“ werden jene Aktivitäten beschrieben, welche das Tagesgeschäft des Projektmanagers betreffen. Neben den geplanten Tätigkeiten geht es im Besonderen auch darum, mit ungeplanten Ereignissen umgehen zu können, dazu zählen Änderungen bzw. Wünsche, Risiken und offene Punkte. Im Einzelnen sind die Aufgaben des Projektmanagers folgende; Überwachen von: Arbeitspaketen, Phasenfortschritt, Toleranzen; Managen aller Risiken und offenere Punkte; Berichterstattung an den Lenkungsausschuss. Zum Artikel