Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Books on Demand
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
Alle Ansätze, Software-Entwicklung im industriellen Maßstab über viele Teams zu skalieren und dabei stets gesicherte Angaben über Qualität, Kosten und terminliche Liefertreue machen zu können, sind bisher fehlgeschlagen. SAFe® und die weiteren in diesem Buch behandelte Entwicklungs-Frameworks Spotify®, LeSS®, Nexus und Scrum@Scale® sollen über viele Teams skalierte agile Entwicklung ermöglichen. SAFe® lehnt sich in seiner derzeitigen Version 4.6 am weitesten aus dem Fenster, indem es mittels Agilität und Lean Startup-Modell verspricht, größte Organisationen und Konzerne in die Lage zu versetzen, nahezu beliebig große Software- und Systementwicklungen steuern zu können. Neben einer ausführlichen Beschreibung liefert das vorliegende Buch eine konstruktiv-kritische Betrachtung der 'Heilsversprechen' von SAFe®, flankiert durch die vergleichende Beschreibung weiterer Frameworks und ergänzt durch Anmerkungen aus der beruflichen Praxis des Verfassers.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 337
Veröffentlichungsjahr: 2019
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Manche Autoren stellen ihren Büchern Zitate voran; bei mir sind es deren zwei – ich konnte mich beim besten Willen nicht zwischen diesen beiden in meinen Augen gleichermaßen passenden Zitaten entscheiden. Beide Äußerungen sind gleichermaßen Motivation und Mahnung für die lean-agile Welt:
“Man muss die Dinge so einfach wie möglich machen. Aber nicht einfacher.”
(Albert Einstein)
„Mach nur einen Plan. Sei ein großes Licht. Und mach dann noch 'nen zweiten Plan. Gehn tun sie beide nicht“
(Bertolt Brecht)
In diesem Buch verwendete Markennamen:
SAFe® und Scaled Agile Framework® sind eingetragene Warenzeichen von Scaled Agile Inc.
RUP® und der Rational Unified Process® sind eingetragene Warenzeichen der International Business Machines Corporation.
LeSS® ist ein eingetragenes Warenzeichen von The LeSS Company B.V.
Scrum.orgTM ist ein eingetragenes Warenzeichen von Scrum.org
Scrum@Scale® ist ein eingetragenes Warenzeichen von Scrum@Scale LLC
Spotify® ist ein eigetragenes Warenzeichen der Spotify AB
PRINCE2® ist ein eingetragenes Warenzeichen der AXELOS Limited.
ITIL® ist ein eingetragenes Warenzeichen der AXELOS Limited.
IT Infrastructure Library® ist ein eingetragenes Warenzeichen der AXELOS Limited.
PMBOK® ist ein eingetragenes Warenzeichen des Project Management Institute (PMI).
Tupperware® ist ein eingetragenes Warenzeichen der Tupperware Brands Corporation
VW Polo® und VW Lupo® sind eingetragene Warenzeichen der Volkswagen AG
ZU inhaltlichen Fragen, Fehlern und Verbesserungsvorschlägen wenden Sie sich bitte direkt an Lars Dibbern: www.dibbern.biz
Über den Autor
Lars Dibbern, Jahrgang 1966, führte sein erstes agiles Projekt im Jahre 2000 als Softwareentwickler und Architekt durch, konsequent mit Extreme Programming (XP) - und es war ein erfolgreiches Projekt.
Seitdem ist Lars in zahlreichen agilen sowie nicht-agilen Umfeldern in den verschiedensten Rollen in den Bereichen Software-Entwicklung, Cloud-Computing, Big Data und KI als Consultant tätig.
Ein durchgehender Schwerpunkt bestand während dieser Zeit in der agilen Prozessberatung und der Einführung verschiedenen lean-agiler Vorgehensweisen in skalierten Umfeldern, zuletzt in Form von SAFe und LeSS.
Content
1. EINFÜHRUNG
1.1. Warum dieses Buch existiert
1.2. Zur Sprache - Begriffe und SAFe-Terminologie
1.3. Lean-agile Zeitenwende
1.4. Anleitung für dieses Buch
TEIL I: EINFÜHRUNG IN DIE GRUNDLAGEN VON SAFE
2. LEAN UND AGIL
2.1. Der PDCA-Zyklus
2.2. Agile Softwareentwicklung
2.2.1. Agiles Theater
2.3. Lean Management und Lean Startup
2.3.1. Lean Management
2.3.2. Lean Startup und validiertes Lernen
2.3.3. TL;DR
2.4. Die Framework-Idee und wie SAFe sie umsetzt.
3. SAFE IN A NUTSHELL
3.1. Woher kommt SAFe?
3.2. SAFe - Das „Little Big Picture“
3.2.1. Essential SAFe
3.2.2. Large Solution SAFe
3.2.3. Portfolio SAFe
3.2.4. Full SAFe
3.3. Lean-agiles Anforderungsmanagement in SAFe
3.3.1. Ziele müssen S.M.A.R.T. sein
3.3.2. Stretch-Objectives
3.3.3. Der Lean Startup-Zyklus
3.3.4. Elementares zum Kanban Board
3.3.5. Hierarchie der Backlog-Elemente
3.3.6. Anforderungsmanagement im Team Level
3.3.7. Anforderungsmanagement im Program Level
3.3.8. Anforderungsmanagement im Portfolio Level
3.3.9. Anforderungsmanagement im Large Solution Level
3.4. Kerntätigkeiten in den SAFe Leveln
3.4.1. Entwicklung im Team Level
3.4.2. Steuerung im Program Level
3.4.3. Steuerung im Portfolio Level
3.4.4. Steuerung im Large Solution Level
3.5. Lean-agile Budgetierung- und Finanzierung
4. DAS FUNDAMENT VON SAFE
4.1. Kernkompetenz: Lean-Agile Leadership
4.2. Festigung der SAFe Kernwerte (Core Values)
4.2.1. Abstimmung/Ausrichtung (Alignment)
4.2.2. Eingebaute Qualität
4.2.3. Transparenz
4.2.4. Einhaltung des Programms
4.3. Etablierung eines lean-agilen Mindset
4.3.1. Lean denken
4.3.2. SAFe Program Consultants (SPC)
4.4. Die 9 SAFe-Prinzipien
4.4.1. Prinzip #1: Einnehmen einer wirtschaftlichen Sichtweise
4.4.2. Prinzip #2: Denken in Systemen
4.4.3. Prinzip #3 Variabilität annehmen – Optionen offenhalten
4.4.4. Prinzip #4: Inkrementellen Fortschritt mit schnellen integrierten Lernzyklen verbinden
1.1.1. Prinzip #5: Meilensteine an funktionierenden Systemen ausrichten
1.1.2. Prinzip #6: Visualisierung und Beschränkung des WIP, Reduzierung der Losgrößen, steuern der Queue-Längen
1.1.3. Prinzip #7: Entwickeln in einer Kadenz und in Domain-übergreifender Synchronisation
1.1.4. Prinzip #8: Erschließen der intrinsischen Motivation von Wissensarbeitern
1.1.5. Prinzip #9 Dezentrale Entscheidungsfindung
4.5. Eine übergreifende Werkzeugpalette
4.5.1. Metriken
4.5.2. Shared Services
4.5.3. Community of Practice
4.5.4. Meilensteine
4.5.5. Roadmap
4.5.6. Vision
4.5.7. System Team
4.5.8. Lean UX
4.6. Agile Personalpolitik in SAFe
4.7. Capex and Opex in SAFe
4.8. Priorisierung der Backlog-Elemente
4.9. Release Management in SAFe
TEIL II: DETAILS ZU DEN SAFE-KONFIGURATIONEN
5. ESSENTIAL SAFE
5.1. Werkzeuge der Essential SAFe-Konfiguration
5.2. Der Team Level
5.2.1. Kernkompetenz: Technische und Team-Agilität.
5.2.2. PDCA im Team Level
5.2.3. Team Kanban
5.2.4. Die Rollen des Team Level
5.2.5. Lean Development in der Aufbauorganisation
5.2.6. Kultur der Zusammenarbeit
5.3. Der Program Level
5.3.1. Kernkompetenz: DevOps and Release on Demand
5.3.2. Teams und Events
5.3.3. Agile Release Train
5.3.4. Program Kanban
5.3.5. Program Epic Kanban
5.3.6. Architectural Runway
5.3.7. Emergenz vs. Architektural Runway
5.4. Vorgehen bei der Einführung von Essential SAFe
6. LARGE SOLUTION SAFE
6.1. Kernkompetenz: Business Solutions und Lean Systems Engineering
6.2. Large Solution Level
6.3. Solution Kanban
6.4. Solution Backlog
6.5. Events
7. PORTFOLIO SAFE
7.1. Kernkompetenz: Lean Portfolio Management
7.2. Der Portfolio Level
7.3. Finanzierung von Value Streams
7.4. Portfolio Kanban
7.5. Finanzierung von Value Streams
8. FULL SAFE
TEIL III: DIE LEAN-AGILE TRANSFORMATION
9. DIE SAFE-EINFÜHRUNGS-ROADMAP
9.1. Der Wendepunkt
9.2. DevOps-Einführung
10. ORGANISATORISCHE SCHRITTE
10.1. Trainieren der lean-agilen Vermittler für den Wandel
10.2. Trainieren von Führungskräften und Managern
10.3. Schaffung eines Lean-Agile Center of Excellence (LACE)
11. SCHRITTE ZUR ART-IDENTIFIZIERUNG
11.1. Identifizierung der Value Streams und ARTs
11.1.1. Formale Kriterien von Value Streams
11.1.2. Zwei Value Stream - Kategorien
11.1.3. Identifizierung der ARTs
11.2. Erstellung eines Implementierungsplans
11.2.1. Auswählen eines (ersten) Value Streams
11.2.2. Auswählen des ersten ART innerhalb des Value Streams
11.2.3. Erstellung einer vorläufigen Planung für die Implementierung weiterer Arts und Value Streams.
11.2.4. Herausforderungen und Potentiale
11.2.5. Erstellen einer Vorausplanung für zusätzliche ARTs und Wertströme
11.3. Vorbereiten einer ART-Einführung
11.4. Training der Teams und starten des ARTs
11.5. Coaching der ART-Prozesse
11.6. Einführung weiterer ARTs und Value Streams
12. SCHRITTE ZUR ORGANISATIONSWEITEN VERANKERUNG VON SAFE
12.1. Einbeziehung des Portfolios
12.2. Erhalten und vertiefen der lean-agilen Transformation
13. VERTIEFENDE SCHRITTE BEI DER EINFÜHRUNG VON SAFE
13.1. Einführung eines Large Solution Level
13.2. SAFe per Einladung
TEIL IV: ALTERNATIVEN ZU UND ZUKUNFT VON SAFE
14. DAS SPOTIFY-MODELL
14.1. Squads
14.2. Tribes
14.3. Chapter und Gilden
14.4. Zusammenfassung
15. LARGE-SCALE SCRUM (LESS)
16. NEXUS
17. SCRUM@SCALE
18. ZUKUNFT UND BEURTEILUNG VON SAFE
APPENDIX
19. QUELLENVERZEICHNIS
20. INDEX
21. ABBILDUNGSVERZEICHNIS
1. Einführung
1.1. Warum dieses Buch existiert
Es geht um Lean Management und skalierte agile Entwicklung - um die Einführung und den Einsatz dieser beiden Denk- und Vorgehensweisen in eine Organisation.
Kurz: Es geht um die lean-agile Transformation großer und größter Organisationen, die zuvor womöglich weder lean noch agil unterwegs waren.
Diese Buch behandelt die Transformation am Beispiel des Scaled Agile Frameworks (SAFe®) für skalierte Umgebungen. D.h. in Organisationen, die ihre Produktentwicklung über viele Entwicklungsteams skalieren.
SAFe stellt einen organisatorischen Rahmen bereit und reichert diesen mit verschiedenen bereits prinzipiell bekannten Rollen, Prozessen und Artefakten aus der dem Lean Management und der agilen Welt an. Scaled Agile Inc., Rechteinhaber von SAFe, hat diese Elemente gesammelt, teilweise leicht verändert, umbenannt und/oder ergänzt und das Ganze schließlich zu SAFe kombiniert. Organisationen jeglicher Größe sollen in die Lage versetzt werden, SAFe nach ihren Bedürfnissen anpassen und einsetzen zu können.
SAFe stellt bei weitem nicht den einzigen möglichen Weg dar, agile Methoden und Lean Management in einer Organisation anzuwenden. Kap. 14. geht vergleichend auf das Spotify Modell, LeSS, Nexus und Scrum@Scale ein. Dadurch soll neben der Einarbeitung in SAFe das Verständnis für ansatzübergreifende lean-agile Elemente stärken und Leser dazu ermutigen, eigene Wege bei der lean-agilen Transformation zu beschreiten – es muss nicht immer SAFe sein.
SAFe ist keinesfalls „by the book“ zu implementierten. Nachdem die Wahl auf eine der verschiedenen SAFe-Ausbaustufen (Kap. 3.) gefallen ist, muss sich jede Organisation genau darüber im Klaren werden, welche Rollen und Artefakte aus SAFe sie in welcher Weise nutzen möchte.
Ansätze, SAFe als „Blaupause“ für die eigene Organisation zu nutzen, sind erfahrungsgemäß zum Scheitern verurteilt.
Es mag bisweilen verführend erscheinen, sich schlicht auf SAFe zu berufen, wenn man mit Widerständen in einer Organisation konfrontiert wird.
1.2. Zur Sprache - Begriffe und SAFe-Terminologie
In diesem Buch verwendet der Verfasser englische Termini aus SAFe neben deutschen und englischen IT-Fachbegriffen, wie es auch in der täglichen Praxis üblich ist.
Englische und deutsche Begriffe parallel
Das Buch trägt damit der prägenden Bedeutung der englischen Sprache in der Informationstechnologie Rechnung und hütet sich vor unnötigen Eindeutschungen aus dem Englischen oder Amerikanischen übernommenen Begriffe, die meistenteils bereits Eingang in die deutsche IT-Szene gefunden haben.
Da dieses Buch neben der Auseinandersetzung mit SAFe ebenso der Vorbereitung auf SAFe-Zertifizierungen dienen soll, wäre es zudem kontraproduktiv, durch die Eindeutschung der in den Zertifizierungen verwendeten Begriffe womöglich Verwirrung zu stiften.
Eine strikte Eindeutschung verbietet sich nach der Erfahrung des Autors auch deshalb, weil lean-agile Transformationen in den meisten ihm bekannten Fällen im internationalen Umfeld stattfinden. Dort werden Dokument in Englisch verfasst und gepflegt.
Beispiele:
Der Verfasser benutzt SAFe-spezifische Begriffe wie Agile Release Train oder Value Stream Canvas in ihrer englischen Version. Wenn es sich um in SAFe genutzte Schlüsselbegriffe wie dem Value Stream oder Principal Role handelt, verwendet dieses Buch ebenso den englischen Begriff.
Begriffe und Abkürzungen
Aufgrund der Vielzahl der neuen Begriffe werden zur leichteren Lesbarkeit Abkürzungen zwar eingeführt, die volle Bezeichnung aber z.T. weiterhin genutzt, durchaus mit wiederholter Angabe der Abkürzung.
1.3. Lean-agile Zeitenwende
Die diesem Buch zugrundeliegenden Begriffe agil und lean werden im folgenden Kap. 2. erklärt. Unter Vorwegnahme des Kap. 2. eine kurze Erklärung der Begriffe lean und agil, soweit sie für das Verständnis dieses einführenden Abschnitts hilfreich sein sind:
Agil
: Produktentwicklung in kurzen aufeinanderfolgenden Zyklen mit der Auslieferung eines messbaren Kundennutzens am Ende einer jeden Iteration
Lean
: Schaffung der Voraussetzungen für effizientes und effektives Arbeiten durch Behebung bzw. Vermeidung von Flaschenhälsen sowohl in der Entwicklung und Produktion als auch in der Entscheidungsfindung hinsichtlich gewünschter Produkteigenschaften.
Die globale Herausforderung
Vor dem Hintergrund der allgegenwärtigen Globalisierung und der damit verbundenen verstärkten Konkurrenz zwischen den Volkswirtschaften steht die lean-agile Transformation im historischen Kontext der stetigen Weiterentwicklung und des Produktionsfortschritts. Erfolgreich angewandtes lean-agiles Management soll einen Wettbewerbsvorteil gegenüber den Teilen der Welt darstellen, in denen lean-agile Vorgehensweisen Kultur- und Gesellschaftsbedingt (derzeit noch) weniger ausgeprägt sind als in westlich-wohlhabenden Industrienationen.
Die lean-agile Transformation stellt im Verbund mit verwandten Techniken wie z.B. DevOps einen Hebel dar, um mit effizientem Einsatz an qualifizierten Wissensarbeitern im globalen Konkurrenzkampf mit den aufstrebenden Volkswirtschaften konkurrieren zu können.
Um es mit ein wenig mehr Dramatik auszudrücken:
Es geht schlichtweg kein Weg an der lean-agilen Transformation vorbei und bedeutet für die Unternehmen “change or perish”, soll in Regionen mit hohem Lohnniveau weiterhin lukrativ Software-Entwicklung betrieben werden können.
Die lean-agile Antwort
SAFe tritt mit dem Versprechen an, ein Framework für eine solche lean-agile Transformation zu sein.
Dabei nimmt SAFe nicht nur für sich in Anspruch, die agile Entwicklung über eine Vielzahl von Teams zu großen Entwicklungsvorhaben skalieren können. Weiterhin ist es das Ziel von SAFe, das Lean-Startup-Model (Ries, 2011), ursprüngliche für kleine Unternehmen und Einheiten gedacht, ebenso auf große und größte Unternehmungen anzuwenden!
Die lean-agile Vorgehensweise bezieht sich prinzipiell auf jegliche Produktentwicklung – keinesfalls nur auf die Software-Entwicklung. Es ist allerdings wahr, dass sich lean Management und agile Softwareentwicklung am leichtesten in der Software-Entwicklung umsetzen lassen.
Anspruch und Wirklichkeit
Gefühlt jede Firma, die etwas auf sich hält bzw. als fortschrittlich und leistungsfähig wahrgenommen werden möchte, behauptet von sich, agil zu arbeiten oder es zu „sein“, teilweise ergänzt um die Attribute „größtenteils“ oder „zumeist“. Wie reibungslos das Ganze dann bei einer Anzahl großer Teams noch abläuft steht auf einem anderen Blatt.
Gewiss dürfen wir keine Wunder erwarten, wenn sich große Organisationen prozesstechnisch neu auszurichten versuchen. Es fällt allerdings auf, dass der Schwerpunkt in vielen Diskussionen zu SAFe auf der Skalierung der agilen Vorgehensweise liegt und der Lean-Aspekt zumeist nur nebenbei oder gar nicht vorkommt. Ein Beispiel ist die Präsentation der Siemens LCS, die ihre SAFe-Erfahrung als Erfolgsgeschichte feiert (Siemens PLM Software, Siemens AG, 2018). Darin kommen die folgenden zentralen Termini in der folgenden Häufigkeit vor:
Agil
: 28x, auf diesen Begriff wird nachdrücklich eingegangen;
Scale
: 14x, Diese Begriff ist wichtig, kommt aber hauptsächlich in stehenden Begriffen vor;
Lean
: 3x, wird nur mitgezogen, in der Überschrift und als Teil stehender Begriffe/Schlagworte (
Lean Enterprise
,
Lean Business Case
).
Diese Verteilung der zentralen Begrifflichkeiten ist symptomatisch. Ferner legt das zitierte Dokument nahe, dass sich Siemens LCS verschiedener in SAFe enthaltenen Rollen, Artefakte und Vorgehensweisen bedient, ohne eine der von SAFe definierte Konfigurationen auch nur einigermaßen komplett zu implementieren. Die Synchronisation der Iterationen der agilen Teams und deren Zusammenfassung zu Program Increments (4 – 8 Iterationen) scheint Siemens LCS laut der zitierten Präsentation umgesetzt zu haben. Dies ist für SAFe essential, macht allerdings noch keine SAFe-Konfiguration aus.
Um jedem Missverständnis vorzubeugen: Der Verfasser sieht das Ganze in keiner Weise negativ: Siemens LCS scheint SAFe als „Werkzeugkasten“ zu nutzen.
Die Frage ist, ob dieser Ansatz die Trainings- und Zertifizierungskosten rechtfertigt. Die zitierte Quelle legt die Inanspruchnahme von Beratungsleistungen nahe, ohne explizit darauf hinzuweisen.
Ziele einer lean-agilen Transformation
Wie so oft bei derartigen Hype-Themen, ist es wichtig, dass der Sinn und Zweck einer lean-agilen Transformation für das Unternehmen allen Mitarbeitern, Stakeholdern und Kunden transparent gemacht wird. Es reicht nicht aus, nur auf den „Transformationszug“ aufzuspringen, „weil alle es so machen“.
Vielversprechende Ziele einer lean-agilen Transformation sind z.B.:
Verlust der bereits oben angeführten Konkurrenzfähigkeit im globalen und/oder unsicheren Umfeld. Trifft das für die jeweilige Organisation wirklich zu?
Erhöhung der Effizienz im Sinne der Verkürzung der Time-to-Market. Ein sehr oft genanntes Ziel, das allerdings voraussetzt, das neben kurzen Implementierungszyklen auch die entsprechenden Vorgaben und Entscheidungen getroffen werden. Vor allem muss die Frage beantwortet werden, was die lean-agile Arbeitseise der derzeitigen Arbeitsweise der Organisation voraushat.
Erhöhung der Profitabilität: Ein sehr oft genanntes Ziel ohne dies aber weiter auszuspezifizieren:
Ohne die Schaffung von Transparenz in den genannten Punkten sollte ein lean-agiler Umbau nicht in Angriff genommen werden.
Die Gefahr eines Rückfalls
Der lean-agile Umbau einer Organisation kann nur dann als erfolgreich bewertet werden, wenn ein Rückfall in „voragile“ Zeiten nicht so ohne weiteres möglich ist.
Mit Rückfällen ist z.B. gemeint, dass in kritischen Situationen das Management in das agile Geschehen eingreift, um detaillierte Planungen und Zeitvorgaben zu erzwingen1. In einer derartigen Situation werden die agilen Teams mit der Situation konfrontiert, dass das Senior Management an festen Planvorgaben festhält bzw. die agilen Werte noch nicht vollständig verinnerlicht hat. Im Ergebnis mag es zwar gelingen, ein bestimmtes Feature zu einem festgelegtem Zeitpunkt vorweisen zu können, allerdings unter Inkaufnahme technischer Schulden, Overhead und Waste.
Dies ist ein Grund, weshalb die SAFe-Roadmap (Teil III) beim Senior Management bzw. den Lean-Agile Leadership2 ansetzt, um diesen Rückfall bereits auf Managementebene möglichst zu vermeiden.
Mit der lean-agilen Steuerung vom Senior- bis zu den untersten Management-Leveln muss bei der Etablierung des lean-agilen Mindsets angesetzt werden. Wenn bereits die Wissensarbeiter in den Teams eine stärkere technische und fachliche Expertise als das Management aufweisen, muss dieses zumindest in der Lage sein, die Lean-agile Transformation voranzutreiben.
Lean-agil im historischen Kontext
Zu Beginn des Industriezeitalters existierten noch nicht die Organisationsformen und Rahmenbedingungen, um die damals neuen technischen Möglichkeiten der Massenfertigung sowie der großangelegten Energiegewinnung und dessen Nutzung in effiziente Bahnen leiten zu können.
Lässt man den Vergleich von industrieller Revolution mit lean-agiler Transformation zu, so kann man sich die disruptive Natur des Wandels anhand eines kleinen Manufakturbetriebs vorstellen, der zu einem Großbetrieb mit Montagebändern und Massenproduktion umgebaut wird.
Startet eine traditionell aufgestellte Organisation eine SAFe-Einführung sind die Änderungen entsprechen tiefgreifend und Risiko-behaftet.
Als Abhilfe bot sich die Orientierung an militärischen Aufbauorganisationen an. Diese fanden als Vorlage Eingang beim Aufbau industrieller Linienstrukturen. Unter einem Oberbefehlshaber (Direktor), existieren weitere Führungsebenen mit Leitern (Offizieren), Mannschaften (Abteilungen) und Stäben (Stabsstellen oder Beratergremien).
Diese Organisationsformen blieben lange Zeit fast unverändert – Anpassungen und Weiterentwicklungen folgten ab Mitte des 20. Jahrhundert, z.B. mit der Einführung von
Fertigungsinseln (Landau, 2007), (Ohno, Das Toyota-Produktionssystem, 1993) und Kaizen (Imai, 1997)3.
These:
Eine weitergehende an die Erfordernisse der lean-agilen Produktionsweise angepasste Organisationsstruktur würde eine mit der industriellen Revolution vergleichbare Umwälzung darstellen.
Voraussetzungen für agiles Arbeiten im skalierten Umfeld
Nehmen die Entwicklungsvorhaben innerhalb einer Organisation an Größe und Komplexität zu, übersteigen die zur Implementierung notwendigen Ressourcen die Personalstärke einzelner agiler Teams. Es müssen also mehrere Teams dazu gebracht werden, koordiniert unter Beibehaltung agiler Vorgehensweisen an einer Lösung zu arbeiten – und diese aktiv voranzutreiben.
Im besten Fall erlaubt die einem System zugrundeliegende Architektur eine Aufteilung der zu implementierenden Komponenten auf die verschiedenen agilen Teams, die isoliert voneinander die jeweilige Funktionalität getrennt voneinander entwickeln.
Eine solche Architektur ist jedoch in vielen Fällen nicht von Vornherein vorhanden. Nicht zuletzt aus diesem Grund ist in der agilen Community das Thema Skalierung von Anfang an umstritten gewesen. Jeff Sutherland, einer der Miterfinder von Scrum sprach sich zunächst noch gegen jegliche Skalierung von Scrum aus, lässt zu einem späteren Standpunkt jedoch eine "kleine Skalierungslösung" in Form von „Scrum of Scrum“ zu, aus der mittlerweile das mit SAFe konkurrierende Skalierungs-Framework (Scrum@Scale, 2019) entstanden ist, dass Kap. 17. näher beschreibt.
Ebenso spricht sich ein weiterer Unterzeichner des agilen Manifests (Agiles Manifest, 2001), Martin Fowler, deutlich gegen Skalierung aus („Scaling Agile methods is the last thing you should do.“) (Fowler, Agile Imposition, 2006). Eine weitere Äußerung ebenda ist:„A better approach is to try to scale down your project “.Martin Fowler bezieht sich auf Projekte, nicht auf skaliertes agiles Arbeiten in Linienorganisationen, so wie es z.B. SAFe und Spotify anstreben.
Ein weiterer Grund für den Widerstand gegen agile Skalierung war und ist, dass Skalierung im Gegensatz zu einer traditionelle Arbeitsteilung steht, wie sie im Rahmen von komplexen Entwicklungen auftritt.
Ken Schwaber, einer der 17. Unterzeichner des agilen Manifests formuliert seine Abneigung gegenüber SAFe im speziellen in seinem Blog (Schwaber, 2013) ein wenig drastisch. Auf der anderen Seite befindet sich Schwabers Consulting Firma LeSS Company B.V. als Anbieter eines Frameworks zur agilen Skalierung (LeSS) in direkter Konkurrenz zu Scaled Agile Inc.
Viele „schlanke“ Ansätze
Neben SAFe und dem in Kap 14. beschriebenen Spotify-Modell existieren noch weitere Frameworks mit dem Ziel, Skalierung unter Beibehaltung agiler Grundsätze zu ermöglichen. Diesen widmet dieses Buch jeweils eigene Kapitel:
Das Spotify-Modell (
Kap. 14
.),
Less (Large-Scale Scrum, 2018) (
Kap. 15
.),
Nexus (
Scrum.org
, 2018) (
Kap. 16
.),
Scrum@Scale (Scrum@Scale, 2019) (
Kap. 17
.).
Teamgrößen
Es gilt als Binsenweisheit, dass die Anzahl von ca. 4 bis 9 Personen die optimale Größe eines agilen Teams darstellt4. Diese Größe ermöglicht die direkte Kommunikation zwischen allen Beteiligten, ohne dass zu viel Kommunikations-Overhead entsteht.
Wenn man sich zur Skalierung entschließt, geht SAFe von einer weiteren Größe aus, die die max. Anzahl der direkt miteinander in Beziehung stehenden Menschen definiert: Das von dem Psychologen Robin Dunbar eingeführte kognitive Limit (ART, Scaled Agile Inc., 2018). Dieses Limit liegt bei ca. 150 Personen und wird als „Dunbar's Number“ bezeichnet. Die Anzahl von 150 Personen stellt selbstverständlich keine exakte Grenze dar, sondern wurde durch Dunbar in einem Studio mit statistischen Methoden ermittelt (Dunbar, 1993).
Hinsichtlich der Skalierung auf mehrere Teams stellen sich die Fragen:
Nach den Kriterien, die für eine Aufteilung der Teams maßgeblich sind;
Nach der Kommunikation zwischen den Teams;
Nach der Behandlung der Abhängigkeiten zwischen den Teams.
SAFe und die weiteren genannten Frameworks sind mit dem Ziel angetreten, auf diese Fragen in der Praxis umzusetzende Antworten geben zu können.
1.4. Anleitung für dieses Buch
Abb. 1-1gibt einen Überblick über die Struktur des Buches:
Abb. 1-1 Struktur des Buches
Teil I: Einführung in die Grundlagen von SAFe
Lean-agile Grundlagen – ein Primer für die lean-agilen Grundlagen von SAFe, unabhängig vom eigentlichen SAFe-Framework.„SAFe in a Nutshell“ – eine abschließende Einführung in das SAFe Framework mit allen seinen Ausbaustufen.Teil II: Details zu den SAFe-Ausbaustufen – verschiedene aufeinander aufbauende Möglichkeiten, SAFe in einer Organisation zu implementieren.
Teil III: Die SAFe-Einführungs-Roadmap – eine Beschreibung, wie Scaled Agile Inc. sich die Einführung von SAFe vorstellt.
Teil IV: Bewertung von SAFe und Vergleich mit anderen agilen Skalierungs-Frameworks
1 Erkenntnis aus der agilen Praxis: Wenn das Team einer Zeitvorgabe des Managements nicht erfüllen kann, ist dies nicht die Schuld des Teams, sondern das Management war wieder einmal nicht in der Lage, die Zukunft vorauszusagen.
2 Die direkte Übersetzung „lean-agile Führerschaft“ ist unpassend und missverständlich, da der englische Begriff Lean bereits Eingang ins Deutsche gefunden hat. Das Wort „führen“ wiederum bezieht sich im Deutschen auf das Delegieren oder gar Befehlen. Vor dem Hintergrund agiler sich selbst organisierender und Ergebnis-verantwortlicher Teams könnte der Begriff Führerschaft somit missverständlich sein.
3 Firmen wie SAP, Software-AG und die diversen Consulting-Unternehmen einmal ausgenommen, fand im ausgehenden 20. Jahrhundert und findet ein Großteil der Software-Entwicklung in den großen und mittelständischen Maschinen- und Anlagenbauern statt sowie in Banken und Versicherungen statt.
4 In der Beschreibung des Scrum@Scale-Framework in Kap. 17. wird auf eine jüngere Studie verwiesen, die eine Teamgröße von 4-6 Personen als ideal betrachtet.
TEIL I:
EINFÜHRUNG IN DIE
GRUNDLAGEN VON SAFE
2. Lean und agil
Um SAFe verstehen zu können, muss man sich vergegenwärtigen, wie SAFe die Begriffe agil und lean versteht und was von der Kombination dieser beiden Konzepte lean agil erwartet wird.
Agil
SAFe bezieht sich mit agil bezieht auf die klassische Form von Agilität, die auf überschaubaren Teams von 3- 9 Personen fußt. SAFe nennt das Agile Manifest (Agiles Manifest, 2001) explizit als eine seiner Grundlagen und bedient sich hinsichtlich der Begrifflichkeiten bei den Vorgehensweisen Scrum (Scrum.org, 2018) und Extreme Programming (XP) (extremeprogramming.org, 2013)5. Dies ist nachvollziehbar, da es sich bei Scrum und XP um gelebte agile Praxis handelt. Das Ziel von SAFe ist die Skalierung der agilen Vorgehensweise auf eine große Anzahl von Teams und Personen bis hin zu großen Lösungen (Solutions) im Bereich von mehr als 1000 Personen.
Lean
Unter „lean“ versteht SAFe mehr als die z.B. in (Liker, 2006) beschriebenen „klassischen“ Grundsätze des Lean Managements. Vielmehr steht das „lean“ darüber hinaus für das Lean Startup Model (Ries, 2011). Diese Methodik zielt auf die Kombination von schnellem Feedback in Kombination mit iterativ-inkrementeller Produktentwicklung ab. Diese dient der stetigen Überprüfung des Geschäftsmodells und ggf. dessen Korrektur im Sinne der Kundenbedürfnisse und einer kleinstmöglichen Time-to-Market.
SAFe soll dabei helfen, die beschriebenen Praktiken so anzuwenden, dass das Ergebnis am Ende trotz aller Skalierung immer noch „lean“ und „agil“ ist.
TL; DR
Scaled Agile Inc. hat mit SAFe prinzipiell einen Rahmen geschaffen, der bereits bekannte Praktiken aus dem Bereich der agilen Entwicklung und der Lean-Startup-Methodik in einem Framework vereint.
SAFe stellt einen Startpunkt für die lean-agile Transformation großer und komplexer Unternehmen dar. Dazu bietet SAFe mehrere Ebenen, um beginnend bei einem oder wenigen Teams, SAFe in eine Organisation einzuführen.
2.1. Der PDCA-Zyklus
Wohlbekannt und immer wieder gerne zitiert ist der PDCA-Zyklus zum Gemeinplatz „verkommen“. Das von Deming in dieser Form bereits Mitte des 19. Jahrhunderts beschriebene Prinzip ist der Inbegriff der Feedback-Schleife, leicht zu verstehen und nachvollziehbar, aber umso schwerer in komplexen Organisationen und Umfeldern umzusetzen.
Die Häufigkeit, mit der die eine oder andere Variante des PDCA- Zyklus in allen möglichen Frameworks und Vorgehensmodellen zitiert wird6, hätte mittlerweile zu einer utopisch-idealen IT-Welt führen müssen – ist so aber nicht der Fall. Offensichtlich erfolgreiche Anwendung findet der PDCA - Zyklus nur dort, wo die Feedback-schleifen hinreichend kurz sind. Z.B. in agilen Umfeldern.
SAFe nimmt in jedem seiner Level Bezug auf den PDCA- Zyklus. Abb. 2-2 zeigt dessen vier Phasen:
Plan: Planung eines Schrittes oder einer Maßnahme, um ein Ziel zu erreichen oder ihm näher zu kommen.
Z.B. die Planung eines Sprints im Sprint Planning in einem herkömmlichen Scrum-Umfeld
Do: Ausführung des geplanten Schrittes oder der Maßnahme.
Z.B. Durchführung des Sprints durch das Scrum-Team.
Check: Überprüfung der Wirksamkeit des soeben durchgeführten Schrittes.
Z.B. in Form eines Sprint Reviews im Scrum-Umfeld.
Adapt/Act: Anpassung des eben durchgeführten Schritts angewendeten Verfahren oder Maßnahme.
Dies geschieht z.B. im Rahmen einer Scrum-Retrospektive.
Abb. 2-2 PDCA-Zyklus
2.2. Agile Softwareentwicklung
Agile Softwareentwicklung bezeichnet die am PDCA-Zyklus ausgerichtete inkrementell-iterative Vorgehensweise in der Softwareentwicklung. Durch den konsequenten PDCA-Einsatz erhöhen sich Transparenz und Flexibilität, was zu einem schnelleren Einsatz entwickelten Systeme führen soll, in Kombination mit minimierten Risiken im Entwicklungsprozess.
Die Agile Software-Entwicklung versucht auf diese Weise, mit geringem bürokratischem Aufwand und Regeln auszukommen und sich schnell an Veränderungen anzupassen, ohne dabei das Risiko für Fehler zu erhöhen.
Geschichtliche Entwicklung und agiles Manifest
Erste Ansätze zu agiler Softwareentwicklung sind bereits Anfang der 1990er Jahre zu finden. Popularität erreichte die agile Softwareentwicklung erstmals Mitte der 1990er Jahre mit dem nahezu zeitgleichen Aufkommen von Extreme Programming (XP) und Scrum. Dieses Interesse an Extreme Programing ebnete den Weg ebenso für andere agile Prozesse und Methoden.
Die Grundprinzipien agiler Vorgehensweisen und der Begriff „agil“ selbst wurden im Februar des Jahres 2001 (Agiles Manifest, 2001) im „agilen Manifest“ formuliert. SAFe nennt das agile Manifest als eine seiner externen Grundlagen. Die 12 Grundsätze des agilen Manifests lesen sich in der deutschen Übersetzung ungefähr so:
Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst vorleben und anderen dabei helfen, es uns gleichzutun.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
Funktionierende Software ist wichtiger als umfassende Dokumentation
Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen
Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans
An die Kernaussage des agilen Manifests schließen sich dessen 12 Prinzipien an:
Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und strebe dabei die kürzest mögliche Lieferzeit an.
Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
Funktionierende Software ist das wichtigste Fortschrittsmaß.
Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell.
Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.
Man sieht sofort anhand der o.g. Prinzipien, dass es schwierig sein könnte, diese in einem Multi-Team- oder gar Multi-Abteilungs-Szenario ohne Weiteres "leben“ zu können.
Zum Zeitpunkt der Formulierung des agilen Manifests wurden Vorgehensweisen wie Scrum, XP, und Kanban bereits bekannt (neben anderen heute nicht mehr oft genutzten Verfahren). Diese wurden noch nicht landläufig als “agil“ bezeichnet7, sondern zunächst mit Begriffen wie “adaptiv”, “leicht” oder “leichtgewichtig” umschrieben. Die Unterzeichner des agilen Manifests verhalfen schließlich den Terminus “agil” zum Durchbruch.
Die heutzutage in der agilen Entwicklung sichtbaren Praktiken leiten sich aus den o.g. 12 Prinzipien ab. Die folgenden Abschnitte dienen der Erläuterung der Prinzipien in Vorbereitung auf die folgenden Teile und Kapitel des Buches:
Praktik:
Erstelle Software innerhalb kurzer Zeitabschnitte in kleinen aufeinander aufbauenden Inkrementen. Also iterativ, inkrementell und, im Ganzen betrachtet, evolutionär. Die in einem Sprint (2 – 4 Wochen) umzusetzenden Anforderungen werden nur für einen Sprint geplant und umgesetzt. Neuer Sprint, neue Planung.
Agile Prinzipien 1, 2 und 3.Praktik:
Arbeite in kleinen, überschaubaren Teams, die Disziplin-übergreifend aufgestellt sind. Alle Fähigkeiten und Qualifikationen zur Erstellung des Produkts sind im Team vorhanden. D.h. neben Entwicklern sind Architekten, Business Analysten etc. vorhanden. Ein sog. Product Owner (PO) repräsentiert im Team die Fachseite. Der PO hat Entscheidungsgewalt darüber, welche Anforderungen mit welcher Priorität umgesetzt werden sollen. Der Rest des Teams hat die Entscheidungsgewalt, wie welche Anforderungen zu welchem Zeitpunkt umgesetzt werden, solange sich die Entwickler an der PO-seitigen Priorität orientieren.
Agile Prinzipien 4 und 6.Praktik:
Das Team konzentriert sich auf den Kundennutzen, das heißt darauf, dass das im jeweiligen Sprint erstellte Produktinkrement einen Mehrwert für den Kunden darstellt und somit “irgendwie“ demonstrierbar ist. Der PO überprüft jede User Story auf ihren Kundennutzen.
Prinzipien 1, und 10.Praktik:
Es werden nur Stories umgesetzt, die von allen Entwicklern im Team verstanden sind und auf deren Aufwand sich die Entwickler geeinigt bzw. ein Commitment abgegeben haben. Jede geschätzte Story, die in einem Sprint umgesetzt werden soll, benötig das Commitment der Entwickler, dass diese Story im jeweiligen Sprint umgesetzt werden kann und wird. Niemand, auch nicht der PO, legt fest, dass eine Story zu einem bestimmten Zeitpunkt umgesetzt werden soll.
Prinzip 11.Praktik:
Der PO, unterstützt von Business-Experten, verfasst kurze Anforderungen in Form von User Stories, die in einem Produkt Backlog für alle einsehbar sind. PO und Entwicklungsteam ordnen im Rahmen des Sprint Plannings einzelne User Stories dem kommenden Sprint zu. Alle an der Implementierung einer Story beteiligten nehmen eine relative8 Aufwandsschätzung der User Stories vor. Der PO entscheidet, was mit in einem Sprint nicht implementierten Stories geschieht: Entweder in den nächsten Sprint verschieben, überarbeiten, wieder im Product Backlog ablegen oder einfach ignorieren. Der PO unterstützt durch das übrige Team darin, dass immer genug Stories im Backlog vorhanden sind, um das Team in seinen Sprints auszulasten.
Agile Prinzipien 4, und 8.Praktik:
Die Entwickler arbeiten zeitweise zu zweit an einem Rechner (Pair Programming oder Pair Work). Dies geschieht sowohl während der üblichen Entwicklung als auch während den Refactorings, in denen vorhandener Programm-Code überarbeitet wird.
Prinzipien 1 und 9.Praktik:
Einmal pro Sprint, meistens an dessen Ende, finden Retrospektiven statt. In einer Retrospektive identifiziert das Team Erfolge und Misserfolge des aktuellen Sprints und einigt sich auf korrigierende Maßnahmen, wenn notwendig.
Prinzip 12.Praktik:
Der einem Team zugeteilter Scrum Master mit Erfahrung in agiler Entwicklung überprüft die Einhaltung aller Prinzipien.
Im Idealfall präsentiert das Team am Ende eines jeden Sprints die entwickelte Funktionalität den internen oder externen Kunden. Metriken zur Messung der Team-Performance und des Erreichten werden automatisch über die Bearbeitung der User Stories erfasst und ebenso ausgewertet. Idealerweise läuft die individuelle Zeiterfassung, wenn notwendig, über die User Stories. Kein Entwickler, auch nicht der PO, erstellt manuell ein Fortschritts-Reporting.
Prinzipien 1, 4 und 7.Die erfolgreiche Realisierung des o.g. Prinzips 8 („Agile Prozesse fördern nachhaltige Entwicklung[...]“) ist auf den Einsatz aller o.g. Praktiken zurückzuführen.
SAFe nennt das agile Manifest als seine Grundlage nicht nur aus dem Anspruch heraus, die agilen Prinzipien bei aller Skalierung nicht zu vernachlässigen zu wollen, sondern ebenso, um den Kritikern agiler Skalierung etwas entgegenzusetzen.
2.2.1. Agiles Theater
Es gibt sie zuhauf: Teams, die das agile Vokabular herauf und herunter deklinieren, in Sprints arbeiten und die agilen Events durchführen. Dies mag zwar in vielen Fällen hilfreich bei der Entwicklung sein, stellt aber keinen Garant für agiles Vorgehen dar.
Statistiken mit Aussagen über den Anteil der Unternehmen, die zumindest teilweise agil arbeiten, beruhen zumeist auf den Aussagen der Unternehmen selbst und sind nach aller Erfahrung mit Vorsicht zu genießen.
In Verbindung mit skaliertem Vorgehen kann sich agiles Theater extrem nachteilig auswirken, wenn die synchrone Zusammenarbeit der Teams in einem gemeinsamen Takt nicht funktioniert, somit kein Flow entsteht und in dessen Folge der agilen Transformation ihr Fundament entzogen wird.
Es ist keine Schande, nicht agil zu arbeiten, jedoch höchst fragwürdig, Agilität nur vorzugeben, sie aber nicht zu leben.
Umgekehrt ist es durchaus ehrbar, im Rahmen einer traditionellen Wasserfallentwicklung, soweit wie möglich iterativ inkrementell vorzugehen, und durch das Setzen entsprechend kurz aufeinander folgender Milestones schnell zu vorzeigbaren Entwicklungsergebnissen zu kommen.
Agiles Theater frustriert und demotiviert nicht nur die Mitarbeiter, sondern führt weiterhin dazu, dass für die in Verbindung mit hohen Schulungs- und Zertifizierungskosten kein ROI existiert.
Agiles Theater lässt alle verlieren, die Organisation, die einzelnen Mitglieder der „agilen“ Teams sowie die Stakeholder und die Kunden.
Woran erkenne ich agiles Theater?
Agiles Theater ist in den meisten Fällen9 kein Potemkin’sches Dorf, dass eine bewusste Irreführung darstellen soll. Vielmehr handelt es sich beim agilen Theater zumeist um die Folge bzw. das Symptom einer nicht konsequent durchgeführten agilen Transformation.
Es sind die Details, die agiles Theater verraten:
In Sprint Reviews werden keine Ergebnisse am lebenden Objekt, dem System, gezeigt, sondern es wird reportet - in Form von Excel-Sheets und Präsentationen.
In den täglichen Standups (
Daily Standups
, DSU) findet anstatt einer Klärung der Status der Backlog-Elemente ein „Rechtfertigungsreporting“ statt.
In den Sprint Reviews finden keinerlei Diskussionen statt – es wird vielmehr darauf geachtet, die Stakeholder von jeglichen Diskussionen und Kontroversen abzuschirmen. Es mag durchaus nachvollziehbar sein, dass die Teams in den Sprint Reviews keine missverständliche Wahrnehmung bei den Stakeholdern erzeugen möchten. Wenn Diskussionen aber von Management-Seite, z.B. einer Gesamtprojektleitung, unterbunden werden, bedeutetet dies, dass dort die agilen Grundlagen entweder nicht verstanden sind oder die agile Vorgehensweise bewusst sabotiert wird, um eigene nicht-agile Herrschaftsbereiche abzusichern.
Die in Sprint-Retrospektiven festgehaltenen Ergebnisse werden nicht oder nur in den seltensten Fällen nachgehalten oder in zukünftigen Retrospektiven wiederaufgenommen.
„Hineinmanagen“ in die Teams: Scrum Master, POs oder sonstige Stakeholder setzen feste Deadlines und Umfang für Ergebnisse der Sprints. Weiterhin verordnen sie Vorgehensweisen für Workarounds, um Impediments abzumildern. Dadurch hat das Team keinen vollen Einfluss auf die Art und Weise, wie technische Schulden aufgebaut oder vermieden werden. In einem solchen Szenario verhalten sich Scrum Master wie Teilprojektleiter.
Micro-Managing: Scrum Master und Pos schalten sich übermäßig(!) in die Kommunikation zwischen Entwickler und Fachexperten während der Abarbeitung der User-Stories und der sich daraus ergebenen Tasks aktiv ein. Dabei wird permanent Druck in Bezug auf deren zeitnahen Abarbeitung aus sowie auf die Art und Weise der Bearbeitung ausgeübt. Diese Art des Micro-Managements wird im agilen Theater bisweilen zur Kunstform erhoben, wenn Projektmanager diese quasi in Vollzeit ausüben.
2.3. Lean Management und Lean Startup
SAFe bezieht sich bei der Verwendung des Wortes Lean nicht nur auf die Grundlagen des Lean Managements, so wie sie (Ohno, 2005) und (Womack, 2007) beschreiben, sondern auch und gerade auf das Lean Startup-Model (Dorf, 2014).
Lean bedeutet, wie der Name bereits sagt, dass möglichst alle unnötigen Tätigkeiten (Waste) in einem Produktionsprozess vermieden werden. Dies geschieht aus zwei Perspektiven heraus:
Der Unternehmensperspektive:
Mit unnötigen Tätigkeiten sind neben dem administrativen Overhead vor allem Tätigkeiten, Verfahren und Prozesse gemeint, deren Veränderung oder Abschaffung die Profitabilität der Entwicklung und Produktion selbst erhöht.
Der Kundenperspektive:
Das oder die Produkte unterliegen einer ständigen Optimierung und Verbesserung im Hinblick auf die Maximierung deren Kundennutzens. Dies geschieht auf der Basis eines permanenten Lernprozesses, der dem Prinzip der kleinen Fortschritts-Inkremente folgt:
Änderungen an bestehenden oder Innovationen für neue Produkte werden in den kleinstmöglichen Inkrementen durchgeführt und an den/die Kunden ausgeliefert. Nach jedem einzelnen Schritt wird der Erfolg des zuletzt durchgeführten Inkrements vor Kunde gemessen und aufgrund des Gelernten die Produktentwicklung in der einen oder anderen Richtung weitergeführt. Der Knackpunkt ist die Kürze der Inkremente (PDCA-Zyklus).
2.3.1. Lean Management
Klassisches Lean Management10 bedeutet die konsequente Ausrichtung auf das, was der Kunde wirklich benötigt und ihm/ihr einen Nutzen verschafft:
„Wer ist unser Kunde bzw. die Zielgruppe und auf welchen Vertriebswegen wollen wir dem Kunden welche Leistung(en) anbieten, damit er oder sie diese am besten für sich nutzen kann?“
Diese Fragestellung wird vor dem Hintergrund der in vielen Firmen vorherrschenden eher schwergewichtigen Prozesse behandelt. Die Kernprinzipien des Lean Managements finden sich durchgehend in SAFe wieder und sind nachfolgend beschrieben:
Den Wert (Value) für den Kunden (Kundennutzen) kennen.
Wenn Ressourcen in die Entwicklung eines technologisch gesehenen fortschrittlichen Produktes investiert werden, das am Ende aus Kundensicht nicht praxisgerecht einsetzbar ist, nützt dies weder Kunden noch Produzenten. Mit reinen Umfragen zur Marktforschung ist es nicht getan, da diese nicht immer dem realen Kundenverhalten11 Rechnung tragen.
Den Wertstrom (SAFe: Value Stream) kennen
Den Wertstrom stellte die Gesamtheit alle Prozesse und Aktivitäten eines Produktes oder Service dar. Indem sich alle beteiligten über den oder die Wertströme einer Organisation im Klaren sind, fällte es ihnen leichter, unnötige Aktivitäten (Waste) zu identifizieren und zu entfernen. Dazu muss die Organisation den o.g. Value kennen, um den Wertstrom auf diesen Value ausrichten zu können.
Das Fluss-Prinzip (Flow) nutzen
Es geht um nichts anderes, als den kontinuierlichen Produktionsfluss aufrecht zu erhalten. Der Ansatz des Lean Managements ist es, diese Optimierung über Abteilungsgrenzen hinweg durchzuführen. Lokale Optimierung würde zu Unterbrechungen oder Engpässen des Flusses an Abteilungsgrenzen führen und den Value Stream schwächen, so wie eine Kette nicht stärker als das schwächste Glied sein kann.
Schaut man aus der Produktsicht auf den Produktionsprozess, erkennt man die vielen Stopps in Form von Wartezeiten, Zwischenlagern und Pufferbeständen. Aus dem Blickwinkel des Lean Managements verbergen sich bzgl. dieser Stopps erhebliche Verbesserungspotenziale, die durchaus eine weitreichende Auswirkung auf die Effizienz des gesamten Wertstroms haben.
Wenn es gelingt, Engpässe zu beseitigen, die Produktion zu harmonisieren sowie darüber hinaus möglichst kleine Lose sehr schnell und kontinuierlich zu verarbeiten („fließen“) zu lassen), dann schafft dies eine wesentliche Voraussetzung dafür, die Fertigung flexibel, auftragsbezogen und effizient steuern zu können.
Das Pull-Prinzip einführen
Das zu erstellende Produkt oder zu implementierende Feature stellt den Auslöser zum Start der Produktion durch den Entwickler/Bearbeiter dar. Das letzte Glied zieht („pull“) die benötigten Ressourcen, Materialen oder Anforderungen. Im Extremfall werden diese erst zum Zeitpunkt der Bedarfsanmeldung (z.B. Kundenbestellung) produziert. In der Realität liegen am Start der Entwicklung nicht alle Anforderungen in der zur Implementierung notwendigen Detailtiefe vor, sondern nur die wichtigsten.
In vielen Unternehmen wird nach der Maßgabe der maximalen Maschinenauslastung produziert12. Wenn das Unternehmen jedoch konsequent auf den Kunden ausgerichtet ist und die Organisation den Wertstrom nach dem Fluss-Prinzip organisiert, wird erst dann produziert, wenn der Kunde bestellt oder die Bestände ein Minimum erreicht haben. Diese Bestellpunkte bilden den Anstoß für die Produktion. Beim Pull-Prinzip zieht man vom Kunden aus gesehen die Produkte durch die Produktionsschritte, anstatt sie durch Planungsvorgaben in die Produktion zu drücken („push“). So ist ohne Terminjägerei und Überstunden eine 100-prozentige Liefertreue erreichbar. Es entfällt zudem nicht nur die Lagerung von Teilprodukten und Fertigwaren und der damit verbundene Such- und Transportaufwand, sondern häufig kann darüber hinaus die Fertigung ebenso personell entlastet werden.
Wertstromanalyse
Wertstromanalyse bedeutet die Identifizierung der in einem Unternehmen vorhandenen Wertströme nebst Detaillierung aller involvierten Prozessschritte im Rahmen einer Ist-Analyse. Neben dem Zusammenhang aller für den Produktionsablauf benötigten Schritte und Ressourcen ist das Ergebnis der Wertstromanalyse die Identifizierung von Flaschenhälsen, Wartezeiten, doppelten Arbeiten oder Nacharbeiten aufgrund von Entwicklungs- oder Produktionsmängeln.
Geringe Batch- oder Los-Größen
