Agiles Projektmanagement – Skalierte agile Methoden Teil 2

Teil 8: Skalierte agile Methoden Teil 2 / SAFe und DA

Es folgt der zweite Teil innerhalb unserer RFC Blogreihe zum agilen Projektmanagement, in dem wir uns mit skalierten agilen Methoden beschäftigen. Im ersten Teil wurden skalierte Methoden vorgestellt, die sich hauptsächlich mit der Skalierung von Scrum befasst haben. Nachfolgend stellen wir zwei Frameworks vor, die es sich zum Ziel gesetzt haben, agile Methoden in der gesamten Organisation auszurollen. Beide Frameworks sind außerordentlich komplex und können im Rahmen dieses Blogs nur sehr verkürzt dargestellt werden. Für den interessierten Leser stellen wir die Links der jeweiligen Website zur Verfügung.

SAFe – Scaled Agile Framework

Das Scaled Agile Framework ist ein umfangreiches agiles Framework, das insbesondere entwickelt wurde, um Lean und Agile für größere Organisationen auf Team-, Programm- und Portfolioebene umsetzbar zu gestalten. SAFe beschreibt Strukturen, Rollen, Prozesse und Artefakte, die für ein lean und agiles Programm- und Portfoliomanagement relevant sind. Für eine detaillierte Beschreibung des Frameworks empfehlen wir die SAFe Webseite.

Mit Nutzung des Frameworks, sollen insbesondere Herausforderungen gelöst werden, mit denen größere Organisationen bei der Einführung von agilen Methoden konfrontiert werden. Hierzu gehören u. a.:

  • Varianz und lokale Optimierung: Agilität auf Team-Ebene, selbstorganisierte Teams mit nicht koordinierten Product Ownern, führen zu einer Varianz innerhalb der unterschiedlichen Projekte und lokalen Optimierungen, die nicht im Einklang mit einer organisationsweiten Optimierung stehen.
  • Intransparenz: Die auf Teamebene gewünschten hohen Freiheitsgrade und die mangelnde zentrale Ausrichtung der Teams, führen zu Intransparenz. Einzelne Einheiten mögen zwar produktiv sein, es besteht aber keine Möglichkeit die Effizienz zu bündeln, bzw. Steuerungsmechanismen versagen.
  • Agilität bei Großkonzernen: Die meisten agilen Methoden bewegen sich in der Team-Ebene und richten den Wertschöpfungsprozess danach aus. So soll der Product Owner den Business Value definieren. Auf Teamebene mag das funktionieren, in Großkonzernen wird der Product Owner aber oftmals in einem Umfeld aus Anforderungen der Organisation, des Marktes und der Verfügbarkeit des Teams aufgerieben.

Lean Thinking ist eines der Ursprünge des SAFe. Die grundlegenden Prinzipien von SAFe werden daher in einem „Lean Thinking House“ visualisiert.


Abbildung 1: Lean Thinking House des SAFe


Das folgende Bild zeigt das „Big Picture“ des SAFe, welches frei im Internet verfügbar ist. Es beschreibt die Praktiken, Rollen und Vorgänge auf der Ebene Team, Programm und Portfolio:


Abbildung 2: Big Picture SAFe


Portfolioebene: Auf der Portfolioebene erhalten die Programme je nach Wichtigkeit und Bedeutung Budget zur Umsetzung der geschäftlichen Zielvorgaben, die auf Portfolioebene in Epics formuliert sind. Es findet eine Überwachung und über die Budgetvergabe zugleich eine Steuerung der Programme statt.

Programmebene: Auf der Programmebene findet die Grobplanung für die einzelnen Teams statt. Die Epics werden auf einzelne Features durch den Product Manager runtergebrochen und auf einen Releasezeitstrahl (den sogenannten „Agile Release Train“) für die Umsetzung verteilt. Die Programm-Ebene dient zur Integration und dem Alignment, der sich im Tagesgeschäft weitgehend selbst organisierenden agilen Teams.

Teamebene: Die einzelnen Features werden durch den Product Owner auf Teamebene auf Stories heruntergebrochen. Für ein Release werden die Sprints vorausgeplant. Das Team committet sich auf die Umsetzung von vier bis sechs Sprints.

Das SAFe gibt viele Rollen und Artefakte vor. Die Anzahl ist wesentlich höher als bei anderen agilen Methoden und ist gleichzeitig einer der Hauptkritikpunkte an SAFe. Vielen agilen Coaches gilt SAFe als zu prozesslastig und schwergewichtig, was in vielen Fällen Agilität verhindern und nicht fördern würde. Befürworter von SAFe halten dagegen, dass das Framework dabei hilft, mit Projektmanagern ins Gespräch zu kommen, die bislang agilen Methoden kritisch gegenüberstehen.

DA – Disciplined Agile

Disciplined Agile ist ein Regelwerk zur Prozessentscheidung und soll Unternehmen anleiten, ihre Prozesse auf Agilität einzustellen. Das DA Framework besteht aus vier Teilframeworks, die aufeinander aufbauen. Das folgende Bild zeigt das DA Framework und die Prozesse, die mittels des Frameworks agilisiert werden sollen. Dabei setzt das DA auf unterschiedliche agile Methoden und beschreibt sich selbst als hybrides agiles Framework.


Abbildung 3: DA Framework


  • Disciplined Agile Delivery (DAD): DAD strebt an, alle Aspekte bei der Entwicklung und Auslieferungen von Lösungen zu adressieren. Dies umfasst die Lösungsmodellierung und Planung, das Teambuilding, die Finanzierung, kontinuierliche Architektur (Continuous Architecture), kontinuierliche Tests (Continuous Testing) und kontinuierliche Entwicklung (Continuous Developement) mit einer Governance während des gesamten Lebenszyklus. Das Framework unterstützt mehrere Lieferlebenszyklen, einen einfachen / agilen Lebenszyklus basierend auf Scrum, einen schlanken Lebenszyklus basierend auf Kanban und einen modernen agilen Lebenszyklus für Continuous Delivery.
  • Disciplined DevOps: Disciplined DevOps beschreibt die Zusammenlegung von Entwicklung und IT-Betrieb, sowie die Unterstützung von Enterprise-IT-Aktivitäten, um in der Organisation effektivere Ergebnisse zu liefern.
  • Disciplined Agile IT (DAIT): Wie der Name bereits andeutet, befasst sich DAIT mit der Anwendung von agilen und lean Strategien auf alle Aspekte der IT. Dies umfasst Funktionen auf IT-Ebene sowie Unternehmensarchitektur, Datenmanagement, Portfoliomanagement, IT-Governance und andere Funktionen.
  • Disciplined Agile Enterprise (DAE): Ein diszipliniertes agiles Unternehmen (DAE) ist in der Lage, Veränderungen auf dem Markt frühzeitig zu erkennen und darauf zu reagieren. Dies geschieht durch eine Unternehmenskultur und -struktur, die Veränderungen im Kontext der jeweiligen Situation ermöglicht. Solche Organisationen erfordern eine Mentalität des ständigen Lernens im Kerngeschäft und zugrunde liegende schlanke und agile Prozesse, um Innovationen voranzutreiben.

Die Guidelines für jedes der vier Frameworks basieren auf den gleichen Grundsätzen:

  • Menschen zuerst
  • Lernorientiert
  • vollständiger Lieferlebenszyklus
  • Zielorientiert
  • Unternehmensbewusstsein
  • Skalierbarkeit

Alle Hintergründe und Details zu DA sind durch das Disciplined Agile Consortium auf folgender Webseite zusammengefasst und werden laufend erweitert und aktualisiert.

Fazit:

Es existieren diverse Ansätze zur Skalierung agiler Methoden innerhalb einer Organisation. Dabei hat jeder Ansatz seine Anhänger. Welcher Ansatz zur Skalierung für Ihr Unternehmen der Richtige ist, lässt sich pauschal nicht sagen, sondern muss stets individuell geprüft werden. Die Grundvorrausetzung für die Einführung von agilen Prozessen auf der gesamten Unternehmensebene ist aber immer die Gleiche. Das agile Mindset, bestehend aus dem agilen Manifest und den agilen Prinzipien muss im Management und in der Belegschaft bereits verankert sein. Es gibt daher nicht wenige agile Experten, die behaupten, dass es keine neuen Methoden (und vor allem neue Trademarks) für die agile Skalierung braucht, sondern dass die passenden Praktiken für die Skalierung schrittweise (unter Berücksichtigung der bekannten Prinzipien) passend für das jeweilige Unternehmen gefunden werden müssen. Dabei sollte man sich von der Praxis und nicht von Methoden inspirieren lassen.

Ausblick:

In den vergangenen Beiträgen haben wir uns intensiv mit agilen Projektmanagement auseinandergesetzt. Aber nicht jedes Projekt, nicht jede Organisation ist geeignet, um agile Methoden erfolgreich einzusetzen. Die Entscheidung, ob agil oder klassisch, kann mit geeigneten Methoden nachvollziehbar getroffen werden. In unserem nächsten Blog möchten wir Ihnen diese Methoden näher vorstellen.

_________________________________________________________________________________

Übersicht aller Blogs unserer RFC Blogreihe Agiles Projektmanagement

Blog 1: VUCA und die Folgen für Unternehmen – Warum „Agiles Projektmanagement“?

Blog 2: Systematik des agilen Projektmanagements. Werte, Prinzipien, Techniken und Methoden – Was ist „Agiles Projektmanagement“?

Blog 3: Scrum ist eine der bekanntesten agilen Methoden – Was ist „Scrum“?

Blog 4: Kanban ist eine agile Methode für evolutionäres Change-Management – Wie funktioniert Kanban?

Blog 5: Beschreibung von XP, FDD und Agile Up

Blog 6: Testen im agilen Umfeld – Was bedeutet das?

Blog 7: Beschreibung von skalierten Methoden Teil 1: / SoS, LeSS und ES

Blog 8: Beschreibung von skalierten Methoden Teil 2 / SAFe und DA

Blog 9: Entscheidungsfindung – die Ermittlung der passenden Vorgehensweise

Blog 10: Hybrides Projektmanagement: Das Beste aus beiden Welten?

Blog 11: Agile Transition: Der Change-Management-Prozess in der Organisation

Blog 12: Menschen im agilen Umfeld / Herausforderungen und Lösungen für Veränderungsprozesse.

Gefällt Ihnen unsere Blogreihe, haben Sie Anmerkungen oder neue Ideen? Dann freuen wir uns, wenn Sie uns kontaktieren.

Steffen Hahn

Steffen
Hahn

Torsten Lindlahr

Torsten
Lindlahr

Hans Willhoeft

Hans
Willhöft