Der Projektmanagement-Blueprint Teil 2: Ein umfassender Vergleich von Wasserfall, DAD, SAFe, LeSS und Scrum@Scale

Überblick

In Teil 1 des Projektmanagement-Blueprints haben wir die Softwareentwicklungsmethoden Lean Software Development, Agile, Scrum und Kanban behandelt und wie sie alle ihre Wurzeln bis zur Lean Manufacturing zurückverfolgen. Diese Methoden werden normalerweise auf Ebene eines einzelnen Teams eingesetzt. Die Komplexität wächst jedoch, wenn Projekte und Projektteams größer werden und neue Ansätze erforderlich sind, um in großem Maßstab agil zu sein.

In Teil 2 werden wir uns zunächst damit befassen, wie Projektmanager die Wasserfallmethode anwenden, die in traditionellen Unternehmen das gängigste Framework für die Softwareentwicklung ist. Daneben werden wir die beliebtesten Frameworks behandeln, die versuchen, agile Prinzipien in großem Maßstab zu integrieren – Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) und Scrum@Scale.

Wasserfall

Die Wasserfallmethode (auch bekannt als Softwareentwicklungs-Lebenszyklusmodell (SDLC)) ist eine traditionellere Methode, bei der die Softwareentwicklung wie ein Wasserfall von einer Phase zur nächsten kaskadiert. Die Phasen überschneiden sich nicht und haben spezifische Eingangs- und Ausgangskriterien für den Übergang von einer Phase zur nächsten.

Die sechs Lebenszyklusstadien des ursprünglichen Wasserfallmodells sind:

1. Anforderungen: In dieser Phase werden die Erwartungen und Ziele des Projekts definiert, Anforderungen analysiert und ausführlich dokumentiert, in der Regel durch einen Business Analyst. Die Anforderungen werden überprüft und genehmigt, bevor diese Phase verlassen wird.
2. Design: Nachdem die Anforderungen genehmigt wurden, beginnt die Arbeit an der Architektur und dem Design des Produkts, um die genehmigten Anforderungen zu erfüllen. Die physische Architektur, die Komponentenarchitektur, das Datenbankdesign, das detaillierte Komponentendesign, das Moduldesign und andere Designaspekte werden von einem Softwarearchitekten oder -designer dokumentiert. Es wird dann überprüft und genehmigt, bevor mit der Implementierung begonnen wird.
3. Implementierung: Nachdem das Design genehmigt wurde, wird die Implementierung oder Codierung der Software gemäß den Anforderungen und dem Design von Softwareentwicklern durchgeführt.
4. Verifizierung: Nach Abschluss der Implementierung wird die Software vom Test- oder QA-Team getestet, um sicherzustellen, dass die Anforderungen und das Design erfüllt werden und das gewünschte Qualitätsniveau erreicht wird. Fehler werden gefunden, protokolliert, gesichtet und in vielen Fällen behoben.
5. Freigabe und Wartung: Nachdem das Testen und Debuggen abgeschlossen ist, wird das Produkt für den Kunden freigegeben und installiert. Oft findet eine Testrunde statt, um sicherzustellen, dass die Installation erfolgreich war. Nachdem das Produkt geliefert wurde, finden fortlaufende Wartung und Support statt, um sicherzustellen, dass das Produkt weiterhin wie vorgesehen funktioniert.

Vorteile des Wasserfalls

Der Wasserfall hat einige Vorteile und ist für bestimmte Arten von Projekten geeignet, aber es gibt auch einige schwerwiegende Nachteile. Waterfall eignet sich am besten für kürzere Projekte, bei denen die Anforderungen und die Technologie gut bekannt sind und sich wahrscheinlich nicht wesentlich ändern werden.

Einige der Vorteile des Wasserfallmodells, wenn es auf die richtige Art von Projekt angewendet wird:

• Einfachheit: Waterfall ist einfach zu implementieren, da der Umfang im Voraus festgelegt wird und die starren Phasen und ein klarer Übergang von einer Phase zur nächsten vorhanden sind.
• Sichtbarkeit: Der Fortschritt lässt sich leichter messen und von den Interessenvertretern sehen, da der volle Umfang der Arbeit im Voraus bekannt ist und das Projekt von einer Phase zur nächsten übergeht.
• Dokumentation: Umfang, Anforderungen und Pläne können gründlich durchdacht und gut dokumentiert werden, was weniger erfahrenen Teams die Arbeit am Projekt erleichtert.
• Phasenweise Arbeit: Aufgrund der starren Rollen und des Übergangs zwischen den Phasen ist es möglich, dass Projektressourcen an anderen Projekten arbeiten, wenn ihre Hauptphase nicht läuft.

Nachteile des Wasserfalls

Wasserfall eignet sich nicht für längere Projekte, bei denen die Anforderungen nicht gut verstanden sind und/oder sich wahrscheinlich ändern werden und/oder bei denen ein erhebliches technisches Risiko besteht. In der heutigen Zeit, in der sich die Marktbedingungen ständig ändern und die Markteinführungszeit entscheidend ist, gilt dies für die meisten Softwareprojekte.

Zu den Nachteilen des Wasserfallmodells, die sich hauptsächlich auf seine Unfähigkeit zur Anpassung an Veränderungen konzentrieren, gehören:

• Monolithischer Umfang: Es belohnt Stakeholder dafür, an ALLES zu denken, wenn sie den Umfang des Projekts definieren, was zu einem monolithischen Umfang führt.
• Verspätetes Kundenfeedback: Für Stakeholder und insbesondere Kunden ist es schwierig, sich den vollständigen Umfang eines Projekts vorzustellen. Da Wasserfall Kunden vor allem in den letzten Phasen des Projekts Projektergebnissen aussetzt, wird es zwangsläufig schwierig, Kundenfeedback in das Projekt zu integrieren
• Anforderungen ändern sich: Bei längeren Projekten besteht ein sehr hohes Risiko, dass sich die Marktbedingungen und damit die Projektziele und -anforderungen während des Projekts ändern.
• Wertschöpfung am Ende: Waterfall erfordert viel Arbeit im Vorfeld, was bedeutet, dass Wertschöpfung erst spät im Projekt entsteht.
• Interdependenz der Phasen: Die Einbeziehung von Änderungen führt häufig zu Anforderungen und/oder Überarbeitungen des Designs, die sich auf andere Bereiche des Projekts auswirken können. Die Abhängigkeit späterer Phasen von früheren Phasen kann kleine Änderungen im Projekt zu einer unverhältnismäßigen Herausforderung machen.

Disziplinierte agile Bereitstellung (DAD)

Disciplined Agile Delivery (DAD) wurde von Scott Ambler bei IBM und Mark Lines formalisiert und erweitert die Agile- und Scrum-Frameworks, wobei anerkannt wird, dass nicht agile Teile einer Organisation normalerweise in gewisser Weise an der Bereitstellung eines Softwareprojekts beteiligt sind. Dieses Framework umfasst ausdrücklich Aktivitäten aus IT-Betrieb, Unternehmensarchitektur, Portfoliomanagement, Finanzen und Beschaffung in den gesamten Bereitstellungslebenszyklus. DAD zielt darauf ab, die allgemeine geschäftliche Agilität auf pragmatische Weise zu steigern.

Hauptprinzipien und Komponenten

Rollen

DAD hat wesentlich mehr Rollen als Scrum und ist in zwei Kategorien von Teamrollen unterteilt. Primäre Rollen werden von Personen besetzt, die ständig mit dem Projekt arbeiten. Sekundärrollen werden in der Regel vorübergehend eingeführt, um dem Team bei der Skalierung oder anderen Problemen zu helfen. DAD hat diese zusätzlichen Rollen, weil es den gesamten Lebenszyklus der Lösungsbereitstellung abdeckt und weil es die verschiedenen Arten von erforderlichen temporären und unterstützenden Rollen erkennt, die in der realen Welt zu finden sind

Hauptrollen:

1. Stakeholder: Jemand, der von Ihrem Team abhängt, das das Projekt abschließt: Kunde, Endbenutzer oder interner Kollege.
2. Teammitglied : Personen innerhalb des Teams, die die geplante Arbeit tatsächlich ausführen: Entwickler, Designer, Tester usw.
3. Teamleiter: Analog zum Scrum Master arbeitet der Teamleiter als dienender Leiter für das Team, indem er Hindernisse beseitigt, den Teamzusammenhalt erleichtert und agile Werte verbreitet.
4. Product Owner: Wird manchmal als „Stimme des Kunden“ bezeichnet. Der Product Owner vertritt die Stakeholder und pflegt die priorisierte Liste der zu erledigenden Arbeiten.
5. Architektureigentümer: Verantwortlich für die Minderung von Architekturrisiken im großen Maßstab. Diese Rolle wird in der Regel von einem Senior-Entwickler innerhalb des Teams besetzt, da sie einen fundierten technischen Hintergrund und solide Kenntnisse in den Geschäftsbereichen erfordert.

Nebenrollen:

1. Spezialist: Personen, die dem Team vorübergehend beitreten, um in einer spezialisierten Rolle auszuhelfen. Beispielsweise kann ein Datenanalyst beitreten, um Forschungskapazitäten in den frühen Phasen eines Projekts bereitzustellen.
2. Domänenexperte: Steuerberater, Rechtsberater und andere Personen, die über Domänenexpertise verfügen und das Team bei damit verbundenen Herausforderungen unterstützen.
3. Technischer Experte: Datenbankadministrator, Sicherheitsexperte, Build-Master usw. Diese Personen helfen den allgemeineren Teammitgliedern an Schlüsselpunkten im Lebenszyklus.
4. Unabhängiger Tester: Während Tester in der Regel Teil des Hauptteams sind, in einigen Fällen lebensnotwendige regulatorische Anforderungen oder sehr komplexe Systeme, arbeiten unabhängige Tester parallel, um die Arbeit zu validieren.
5. Integrator: Im großen Maßstab arbeiten verschiedene Teams an verschiedenen Teilen des gesamten Systems. Ein Integrator hilft dem Team bei der Integration seines Teils in das Gesamtsystem und verwaltet Abhängigkeiten.

Lebenszyklusunterstützung

DAD fördert einen vollständigen Bereitstellungslebenszyklus, nicht nur den Programmier- und Veröffentlichungsteil, der von Agile/Scrum abgedeckt wird, sondern auch die Anfangsphase, in der die Projektvision definiert und genehmigt wird, sowie die Support- und Ruhephasen nach der Veröffentlichung. Derzeit unterstützt DAD 6 verschiedene Lebenszyklen:

• Der agile Lebenszyklus: Ein Scrum-basierter Projektlebenszyklus
• Der Lean-Lebenszyklus: Ein Kanban-basierter Projektlebenszyklus
• Die Continuous Delivery: Agiler Lebenszyklus
• Die Continuous Delivery: Lean Lifecycle
• Der explorative Lebenszyklus (Lean Startup).
• Der Programmlebenszyklus für ein Team von Teams

Diese Lebenszyklen berücksichtigen unterschiedliche Arbeitsstile, Ebenen der Unternehmensagilität und andere Situationen, in denen sich die Teams möglicherweise befinden. Der Hauptpunkt ist, dass diese Lebenszyklen als Vorschläge dienen. DAD fördert Pragmatismus statt Purismus, da jede Situation einzigartig ist und disziplinierte agile Praktiker den agilen Prozess an ihre Bedürfnisse anpassen sollten.

Prozessziele

DAD verfolgt einen zielorientierten Ansatz zur Erstellung und Anpassung agiler Prozesse. Die Autoren dieser Methodik skizzieren die 21 wichtigsten und häufigsten Prozesse, denen die meisten Teams während ihres Lebenszyklus begegnen werden.

Alle diese Prozesse haben dokumentierte Entscheidungspunkte, an denen das Team entscheiden muss, wie es diesen Prozess strukturieren will. Jeder Entscheidungspunkt bietet vorgeschlagene Techniken oder Praktiken, die zur Umsetzung der Entscheidung verwendet werden können. Ein Beispiel dafür sehen Sie im Bild unten. Ein Prozess „Gemeinsame Vision entwickeln“ hat 6 Entscheidungen, die getroffen werden sollten. Jede dieser Entscheidungen hat 2 bis 5 vorgeschlagene Praktiken. Die Pfeile zeigen an, dass DAD-Autoren die Liste so geordnet haben, dass das oberste Element die beste Praxis und das unterste Element die schlechteste Praxis in dieser Liste ist. Der _ fett kursive_ Text kennzeichnet gute Ausgangspunkte für neue Teams, die gerade erst mit DAD anfangen.

Skalierung von DAD

Disciplined Agile Delivery nähert sich der Skalierung aus zwei verschiedenen Blickwinkeln:

• Taktische Agilität im großen Maßstab

• Strategische Agilität im großen Maßstab

Taktische Agilität versucht, individuelle Team-Skalierungsfaktoren wie Größe, geografische Verteilung, Projektkomplexität usw. durch situative Anwendung der Prozessziele und ihrer vorgeschlagenen Praktiken zu adressieren.

Strategische Agilität versucht, die Skalierung durch die Anwendung von agilen und schlanken Strategien auf breiter Basis in der gesamten Organisation anzugehen, indem das Framework erweitert wird, um verschiedene Bereiche der Organisation anzusprechen:

• Disziplinierte DevOps: deckt die Verwendung von DevOps ab, um effektivere Ergebnisse für eine Organisation zu erzielen.

• Disciplined Agile IT (DAIT): behandelt die Anwendung agiler und schlanker Strategien auf alle Aspekte der IT.

• Diszipliniertes agiles Unternehmen:. behandelt, wie man Lean und Agilität im gesamten Unternehmen anwendet.

Sicher

Scaled Agile Framework (SAFe) ist derzeit das beliebteste sowie das komplexeste und umfassendste skalierte Agile-Framework. 29 % der Befragten im Annual State of Agile Report geben an, dass sie dieses Framework in ihren Organisationen verwenden. Im Gegenzug gibt es viele SAFe-Projektmanager auf dem Markt.

Die Anfänge von SAFe waren Dean Leffingwells Buch „Scaling Software Agility: Best Practices for Large Enterprises“, das 2007 veröffentlicht wurde. Leffingwell ist heute der Chefmethodologe von SAFe, aber viele andere Leute tragen ebenfalls zu diesem Framework bei. Derzeit ähnelt dieses Framework in Version 4.6 einem Softwareprodukt mit Versionierung, Abwärtskompatibilität und verschiedenen Komponenten.

Hauptprinzipien und Komponenten

Das Hauptziel von SAFe ist es, die Schaffung und das Wachstum eines schlanken Unternehmens zu erleichtern, da es anerkennt, dass viele verschiedene Arten von Unternehmen teilweise Softwareunternehmen sind, die in kürzester, nachhaltiger Zeit kontinuierlich Wert liefern müssen.

SAFe for Lean Enterprises versucht, ein schlankes Unternehmen zu schaffen, indem es eine Wissensbasis mit bewährten Prinzipien, Kompetenzen und Best Practices bereitstellt.

SAFe 4.6 definiert fünf Kernkompetenzen des schlanken Unternehmens. Jede Kompetenz ist eine Reihe verwandter Kenntnisse, Fähigkeiten und Verhaltensweisen, die es Organisationen zusammen ermöglichen, sich zu übertreffen:

1. Lean-Agile-Führung : Beschreibt, wie Führungskräfte organisatorische Veränderungen durch Lernen, Lehren und Implementieren der Lean-Agile-Mentalität von SAFe vorantreiben und aufrechterhalten.

2. Team- und technische Agilität : Beschreibt die Fähigkeiten, Prinzipien und Praktiken, die erforderlich sind, um leistungsstarke agile Teams aufzubauen.

3. DevOps und Release on Demand : Beschreibt, wie die Implementierung von DevOps und einer Continuous-Delivery-Pipeline Unternehmen in die Lage versetzt, Produktinkremente jederzeit freizugeben, um den Bedarf zu decken.

4. Unternehmenslösungen und Lean Systems Engineering : Beschreibt, wie Lean-Agile-Prinzipien und -Praktiken auf die Spezifikation, Entwicklung, Bereitstellung und Weiterentwicklung großer, komplexer Softwareanwendungen angewendet werden

5. Lean-Portfoliomanagement : Richtet Strategie und Ausführung aus, indem Lean- und Systemdenken-Ansätze auf Strategie- und Investitionsfinanzierung, agile Portfoliooperationen und Governance angewendet werden.

Jede der Kernkompetenzen wird direkt der jeweiligen Ebene im SAFe-Prozessdiagramm zugeordnet, mit Ausnahme von Lean-Agile Leadership, das den gesamten Prozess umfasst.

Lean-Agile Führungskompetenz

Das primäre Ziel der Lean-Agile Leadership Competency ist es, die Transformation der Organisation in ein Lean-Agile-Unternehmen zu unterstützen. Dies geschieht durch Lernen, Üben und Lehren der Lean-Agile-Denkweise, Werte, Prinzipien und Praktiken von SAFe.

Die Kernwerte von SAFe leiten die Transformation zum schlanken Unternehmen. Bei jeder Gelegenheit spielt das Verhalten einer Führungskraft eine entscheidende Rolle bei der Förderung. Die Kernwerte sind:

1. Ausrichtung : Kommunizieren Sie die Mission, die Portfoliostrategie und die Lösungsvision. Führen Sie relevante Briefings durch und nehmen Sie an der Planung von Programminkrementen (PI) und der Pflege des Rückstands teil.

2. Transparenz : Visualisieren Sie alle relevanten Arbeiten.

3. Eingebaute Qualität : Betreiben Sie Praktiken, um während des gesamten Lebenszyklus Qualität zu liefern. Weigern Sie sich, minderwertige Arbeit anzunehmen. Unterstützen Sie Investitionen in die Wartung und reduzieren Sie technische Schulden.

4. Programmausführung : Beteiligen Sie sich als Geschäftsinhaber an der PI-Ausführung und schaffen Sie einen Geschäftswert. Stellen Sie sicher, dass der Umfang an Nachfrage und Kapazität ausgerichtet ist. Entferne aggressiv Hindernisse und Demotivatoren.

Die Kernwerte von SAFe werden durch die Annahme der Lean-Agile-Denkweise und die Anwendung der SAFe-Prinzipien unterstützt:

1. Betrachten Sie die Wirtschaftlichkeit

2. Systemdenken anwenden

3. Variabilität annehmen; Optionen bewahren

4. Bauen Sie inkrementell mit schnellen, integrierten Lernzyklen auf

5. Stützen Sie Meilensteine ​​auf eine objektive Bewertung funktionierender Systeme

   

6. Visualisieren und begrenzen Sie WIP, reduzieren Sie Chargengrößen und verwalten Sie Warteschlangenlängen

7. Trittfrequenz anwenden, mit domänenübergreifender Planung synchronisieren

8. Setzen Sie die intrinsische Motivation von Wissensarbeitern frei

9. Entscheidungsfindung dezentralisieren

Diese Prinzipien ähneln den Lean- und Agile-Prinzipien. Schließlich wird die Transformation der Organisation durch Befolgen der SAFe-Implementierungs-Roadmap erreicht.

Team- und technische Agilitätskompetenz/Teamebene

Die Kompetenz Team und technische Agilität beschreibt die Fähigkeiten, Prinzipien und Praktiken, die erforderlich sind, um leistungsstarke agile Teams zu bilden, die qualitativ hochwertige Lösungen erstellen. Zwei Hauptmerkmale sind entscheidend:

• Team-Agilität : Teams wenden agile Praktiken und Prinzipien an, die es ihnen ermöglichen, in einem zuverlässigen Rhythmus zu arbeiten, zu lernen und sich anzupassen

• Technische Agilität : Teams wenden agile technische Praktiken an, die die Code- und Komponentenqualität sowie die Wartbarkeit des von ihnen produzierten Codes sicherstellen. Qualität ist ein großer Schwerpunkt in der Kompetenz des Teams und der technischen Agilität. Um dies zu erreichen, werden agile Engineering-Techniken wie Behavior Driven Development (BDD) und Test-Driven Development (TDD) angewendet, um Qualität und Fluss zu steigern. Ein schneller Fluss hängt von der Gebäudequalität im gesamten System ab, da Fehler den Fluss stark beeinträchtigen und Freisetzungen verzögern können.

Die Teamebene des SAFe-Diagramms beschreibt, wie einzelne agile Teams arbeiten. Alle Teams sind Teil des Agile Release Train, der auf die Bereitstellung eines Produktinkrements hinarbeitet. Der Großteil des traditionellen Agile/Scrum-Flows gilt, bei dem Teams in Iterationen arbeiten, um funktionierende Systeme bereitzustellen. Die Rollen Scrum Master, Product Owner und Teammitglied werden in SAFe verwendet, ebenso wie die meisten Scrum-Aktivitäten und -Artefakte. Teams werden auch durch Rollen auf Programmebene wie Produktmanagement, Systemarchitekt und andere gemeinsame Dienste unterstützt. Kanban wird verwendet, um den Fluss von Funktionen durch den Bereitstellungslebenszyklus sowie Interaktionen und Übergaben zwischen Teams zu visualisieren.

Kompetenz-/Programmebene DevOps und Release on Demand

Die Kompetenz „DevOps und Release on Demand“ beschreibt, wie „die Implementierung von DevOps und einer Continuous-Delivery-Pipeline dem Unternehmen die Möglichkeit bietet, Werte ganz oder teilweise jederzeit freizugeben, um die Markt- und Kundenanforderungen zu erfüllen.“

DevOps arbeitet daran, die Entwicklung, den Betrieb, das Geschäft und andere Bereiche aufeinander abzustimmen, um zusammenzuarbeiten, um Geschäftsergebnisse zu erzielen. Auch wenn nicht jede Organisation so oft Releases veröffentlichen muss wie einige der Branchenführer der DevOps-Bewegung (Amazon veröffentlicht alle paar Sekunden), müssen alle Organisationen in der Lage sein, On-Demand-Releases zu erstellen.

• DevOps bietet den Kultur-, Automatisierungs-, Lean-Flow-, Mess- und Wiederherstellungsansatz (CALMR), der eine kontinuierliche Bereitstellung und Freigabe nach Bedarf ermöglicht

• Agile Release Trains (ARTs) sind Teams aus agilen Teams, die so organisiert sind, dass sie über eine kontinuierliche Bereitstellungspipeline Wert auf Abruf liefern

Die Programmebene des Diagramms beschreibt die Rollen und Aktivitäten, die für eine kontinuierliche Bereitstellung über einen Agile Release Train (ART) erforderlich sind. Diese Ebene funktioniert ähnlich iterativ wie die Teamebene, integriert jedoch mehrere agile Teams und umfasst mehr Zyklen. Das ART ist ein agiles Team von Teams, das aus 5 bis 12 Teams (50 bis 125 Personen) besteht, einschließlich der traditionellen agilen Rollen sowie kritischer Programmrollen wie Release Train Engineer (RTE) und Produktmanagement. Das ART liefert in 8-12 Wochen Programminkremente (PI) , die über PI Planning geplant und von einem Produktmanager geleitet werden.

Der Fortschritt von PI-Features, Epics usw. wird über ein Programm-Kanban-Board verfolgt und verwaltet. Der RTE fungiert als Scrum Master auf dem ART. Zu den täglichen Synchronisationsmeetings gehören Team Daily Standups, Scrum-of-Scrums (RTE & Scrum Masters), PO Sync (Product Management & Product Owners) und ART Sync (Scrum-of-Scrums und PO Sync zusammen). Jeder PI hat eine Systemdemo und eine Retrospektive.

Business Solutions und Lean Systems Engineering-Kompetenz/Large Solution Level

Die Kompetenz Business Solutions and Lean Systems Engineering beschreibt, „wie man Lean-Agile-Prinzipien und -Praktiken auf die Spezifikation, Entwicklung, Bereitstellung und Weiterentwicklung großer, komplexer Softwareanwendungen und cyber-physischer Systeme anwendet“.

Neben den SAFe-Prinzipien ist die Anwendung der folgenden 8 Prinzipien bei der Arbeit an großen Lösungen der Schlüssel zu dieser Kompetenz:

Die Ebene „Große Lösung“ enthält die Rollen, Artefakte und Prozesse, die zum Erstellen großer und komplexer Lösungen erforderlich sind. Mehrere ARTs arbeiten gemeinsam an Solution Trains , um Lösungen bereitzustellen. Die primären Ziele sind:

• Verwalten Sie häufige Integrationen

• Gehen Sie kontinuierlich auf Compliance-Bedenken ein

• Architekt für Skalierbarkeit, Modularität, Freigabefähigkeit und Wartungsfreundlichkeit

Das Solution Management steuert den Inhalt einer Lösung und der Solution Train Engineer (STE) leitet die Arbeit. Der Lösungsarchitekt ist für die Aufrechterhaltung einer guten Architektur für alle ARTs in der Lösung verantwortlich. Die Pre- und Post-PI-Planung wird verwendet, um Lösungen zu planen, die über mehrere Programminkremente bereitgestellt werden. Ein Solution Backlog enthält Capabilities und Solution Epics und wird über ein Solution Kanban Board verfolgt

Kompetenz auf Portfolioebene/Lean-Portfoliomanagement

Die Lean-Portfoliomanagement-Kompetenz „richtet Strategie und Umsetzung aus, indem sie Lean- und Systemdenken-Ansätze auf Strategie- und Investitionsfinanzierung, agile Portfoliooperationen und Governance anwendet.“

Lean Portfolio Management konzentriert sich auf die folgenden Bereiche:

1. Strategie- und Investitionsfinanzierung: verbindet das Portfolio mit der Unternehmensstrategie, finanziert Wertströme und stellt den Portfoliofluss her

2. Agile Portfoliooperationen: Koordiniert die Wertströme, unterstützt die Programmausführung und operative Exzellenz

3. Lean Governance: Prognostiziert Budgets, misst die Portfolioleistung und setzt Compliance durch

Die Portfolioebene enthält die Prinzipien, Praktiken und Rollen, die erforderlich sind, um eine Reihe von Wertströmen für die Entwicklung zu initiieren und zu steuern. Ein Portfolio Backlog enthält Business Epics und Enabler Epics und wird über ein Portfolio Kanban* Board verfolgt. **Lean Portfolio Management (LPM) entscheidet darüber, welche Wertströme sich in einem Portfolio befinden, und bezieht die obersten Entscheidungsträger in einem Unternehmen ein. Ein Unternehmensarchitekt leitet die Arbeit und koordiniert über Wertströme hinweg.

Weniger

Das Large Scale Scrum (LeSS) Framework wurde von Craig Larman und Bas Vodde entwickelt, die es auf ihrer Erfahrung in der Finanz- und Telekommunikationsbranche aufbauen. Wie der Name schon sagt, fördert LeSS so wenige Prozesse und Verfahren wie möglich, damit viele Scrum-Teams zusammenarbeiten können. Skalierung ist schwierig, weil die Leute es komplex machen, also ist das Ziel hier, es so einfach wie möglich zu machen.

Hauptprinzipien und Komponenten

„LeSS ist Scrum, angewandt auf viele Teams, die gemeinsam an einem Produkt arbeiten“. LeSS basiert auf zehn Prinzipien, die jedem bekannt vorkommen werden, der sich mit Lean-Agile-Prinzipien auskennt:

1. Groß angelegtes Scrum ist Scrum

2. Empirische Prozesskontrolle

3. Transparenz

4. Mehr mit weniger

5. Fokus auf das gesamte Produkt

6. Kundenorientierte

7. Kontinuierliche Verbesserung zur Perfektion

8. Systemdenken

9. Schlankes Denken

10. Warteschlangentheorie

LeSS hat nur zwei Hauptrollen, die beide von Scrum entlehnt sind:

1. Product Owner: Arbeitet mit 2-8 Teams.
2. Scrum Master: Arbeitet mit 1-3 Teams.

Alle Teams arbeiten mit demselben Product Backlog in 1-4-wöchigen Sprints. Die Teams arbeiten parallel, das heißt, sie starten und beenden Sprints gleichzeitig. Am Ende des Sprints liefern die Teams gemeinsam ein Produktinkrement . Es mag für einen Product Owner fast unmöglich erscheinen, mit 8 Teams zu arbeiten. LeSS fördert die Verlagerung der Verantwortung für die Klärung von Product Backlog Items in die Teams. Die Teams wiederum müssen funktionsübergreifend sein und nicht nur über Programmier-, Design- und Testkompetenzen verfügen, sondern auch über Fachkenntnisse. Noch wichtiger ist, dass die Teams befähigt werden müssen, Kunden zu erreichen.

Sprint-Planung

Die Planung gliedert sich in zwei Teile:

1. Sprint-Planung 1: Hier treffen sich die Vertreter der Teams mit dem Product Owner und entscheiden, welche Backlog-Items sie übernehmen, und besprechen eine mögliche Zusammenarbeit, die zwischen den Teams während des Sprints erforderlich sein könnte.
2. Sprint-Planung 2: Wie beim traditionellen Scrum trifft sich jedes Team separat, um einen Plan zu erstellen, wie die Backlog-Items erledigt werden sollen.

Produkt-Backlog-Verfeinerung

Product Backlog Refinement (PBR) wird während des Sprints durchgeführt, um Product Backlog Items für die Sprintplanung vorzubereiten. LeSS bietet keine Regeln für Züchterrechte und überlässt es den Unternehmen, ihren effektivsten Prozess selbst herauszufinden. Züchterrechte umfassen drei Hauptaktivitäten:

1. Große Gegenstände teilen.
2. Detaillierung von Gegenständen, bis sie fertig sind.
3. Schätzung.

Ende des Sprints

Am Ende jedes Sprints passieren drei Dinge:

1. Sprint Review: Eine gemeinsame Sprint-Demo, bei der Teams und Kunden untersuchen, was während des Sprints getan wurde und was als Nächstes getan werden sollte.
2. Retrospektive: Jedes Team führt seine eigene Retrospektive durch, um seinen Prozess zu verbessern.
3. Gesamtrückblick: Teams, Product Owner und Scrum Master kommen zusammen, um organisatorische Praktiken zu überprüfen und anzupassen, um effektiver zu sein.

Scrum@Scale

Scrum at Scale und Scrum@Scale werden synonym verwendet. Diese Methodik wurde 2014 von Jeff Sutherland eingeführt, der die Scrum-Methodik entwickelt hat und einer der Unterzeichner des Agilen Manifests war.

Scrum@Scale nimmt Scrum als Ausgangspunkt und bietet ein einfaches, leichtes Framework, um Scrum mit einer „Minimum Viable Officecracy“ zu skalieren. Es ist weniger präskriptiv als die anderen skalierten agilen Methoden und kann als Meta-Framework betrachtet werden. Es hebt die Skalierungsprobleme und -bereiche hervor und bietet einen mentalen Rahmen dafür, wie sie angegangen werden könnten.

Hauptprinzipien und Komponenten

Scrum@Scale ist ein Framework, das die Skalierung radikal vereinfacht, indem es Scrum verwendet, um Scrum zu skalieren. Bei Scrum ist das „Was“ (Product Owner) klar vom „Wie“ (Scrum Master) getrennt. Die gleiche Strategie wird in Scrum@Scale verwendet, damit Zuständigkeit und Verantwortlichkeit gut verstanden werden, wodurch Verschwendung und Konflikte vermieden werden.

Scrum@Scale enthält zwei Zyklen, um Zuständigkeiten klar voneinander zu trennen: den Scrum-Master-Zyklus und den Product-Owner-Zyklus mit zwei Berührungspunkten: Team Level Process und Product Release Feedback.

Scrum-Master-Zyklus

Der Scrum-Master-Zyklus ist dafür verantwortlich, wie die Dinge, die der Product-Owner-Zyklus identifiziert hat, gebaut werden. In Scrum@Scale haben einzelne Scrum-Teams dieselben Rollen, Artefakte, Aktivitäten und Zeremonien wie traditionelles Scrum.

Scrum-Teams werden in einem Scrum of Scrums (SoS) gruppiert, die gemeinsam für die Erstellung eines gemeinsamen Produktinkrements verantwortlich sind. Sie beteiligen sich am gemeinsamen Backlog-Grooming und an der Priorisierung, führen Retrospektiven durch, pflegen Impediment-Backlogs und führen ein Scaled Daily Scrum (SDS) (ähnlich dem Daily Scrum) durch, um die Teams zu koordinieren und Hindernisse zu beseitigen. Der SDS wird von mindestens einem Vertreter (in der Regel der Scrum Master des Teams) jedes der teilnehmenden Teams besucht und vom Scrum of Scrums Master (SoSM) geleitet , der für die Koordination mit den Scrum Teams und den Product Ownern verantwortlich ist.

Wenn eine weitere Skalierung erforderlich ist, gibt es ein Scrum of Scrum of Scrums (SoSoS) , das aus mehreren SoS erstellt wird, die sich ebenfalls täglich treffen würden, und so weiter. Der Gesamtleiter ist das Executive Action Team (EAT) , das dafür verantwortlich ist, Agile in der Organisation zu fördern, Scrum-Teams nach Bedarf zu koordinieren und die letzte Station für die Beseitigung von Hindernissen zu sein.

Product-Owner-Zyklus

Der Product Owner Cycle ist dafür verantwortlich, welches Produkt oder welche Dienstleistung erstellt wird, und alle Aktivitäten, die zur Unterstützung erforderlich sind. Product Owner werden Scrum-Teams zugeordnet und führen alle Aktivitäten ihrer Rolle aus, wie sie in Scrum definiert sind. Product Owner sind in Product Owner Teams gruppiert, die den SoS-Teams zugeordnet sind. Product Owner Teams treffen sich täglich bei einem Meta Scrum , um eine übergeordnete Strategie für die Teams zu besprechen und sich bei Bedarf mit dem entsprechenden SoSM und anderen Product Ownern und Stakeholdern abzustimmen. Meta Scrums werden von einem Chief Product Owner (CPO) geleitet.

Product Owner skalieren ähnlich wie der Scrum-Master-Zyklus je nach Größe der Organisation und münden in ein Executive Meta Scrum (EMT) , das für die unternehmensweite Prioritätensetzung zuständig ist.

Implementierung von Scrum@Scale

Die Implementierung von Scrum@Scale beginnt mit der Erstellung eines skalierbaren Referenzmodells, dh einer kleinen Gruppe von Teams, die Scrum in kleinem Maßstab verwenden. Dies geschieht, um alle organisatorischen Richtlinien und Entwicklungspraktiken zu lösen, die Agilität behindern. Scrum@Scale schlägt vor, diese frühzeitig zu lösen, da wahrscheinlich alle Teams mit diesen unternehmensweiten Problemen konfrontiert sind und die daraus resultierenden Frustrationen die Einführung von Agilität behindern könnten. Das Referenzmodell wird dann als Muster für die Skalierung von Scrum auf andere Teams und Abteilungen verwendet.

Zur Umsetzung des Referenzmodells muss zunächst ein Executive Action Team (EAT) gebildet werden. EAT besteht aus Personen, die innerhalb der Organisation politisch und finanziell befugt sind, da sie in der Lage sein werden, die Änderungen der Organisationspolitik umzusetzen.

Fazit

In diesem zweiten Teil des Projektmanagement-Blueprints haben wir einige der beliebtesten Frameworks behandelt, die in größeren Projekten oder Programmen verwendet werden. Wasserfall ist in vielen Organisationen immer noch weit verbreitet, und obwohl es aufgrund seiner unflexiblen Prozesse viele Nachteile hat, ist es manchmal sinnvoll, dieses Framework zu verwenden, wenn die Projekte klein sind und der Umfang klar definiert ist und sich wahrscheinlich nicht ändern wird.

Da Unternehmen auf größere, komplexere Projekte mit sich ständig ändernden Anforderungen oder Zielen stoßen, suchen sie nach agileren Ansätzen. Da Agile ursprünglich für kleine Teams von 5-9 Personen gedacht war, haben verschiedene Agile Praktiker mehrere Möglichkeiten entwickelt, Agile von einzelnen Teams über mehrere Teams bis hin zum gesamten Unternehmen zu skalieren. In diesem Artikel haben wir Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) und Scrum@Scale behandelt.

Im letzten Teil des Projektmanagement-Blueprints werden wir einige projektmanagementspezifische Frameworks wie PMP (PMBOK) und PRINCE2 behandeln. Wir werden auch auf einige Innovationsprozesse und Frameworks wie „Jobs to be Done“ (JTBD) und „Design Thinking“ eingehen.