Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Trochos GmbH
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
Aufbauend auf den klassischen Säulen des IT-Projektmanagements, allen voran dem Agilen Manifest von 2001 und Software Engineering von 1968, stellt das Triple-A Framework einen weiteren Meilenstein in dessen Entwicklung dar. Software-Anforderungen sind seit der Jahrhundertwende rapide gewachsen und damit auch der Umfang und die Komplexität ihrer Entwicklung. Scrum Master werden zur treibenden Kraft hinter prosperierenden Marktführern und disruptiven Start-ups. Ob Sie eine erfolgreiche Führungskraft oder ein ambitionierter Neuling sind - dieses Buch ist Ihr Schlüssel zu Spitzenleistungen. Mit dem Triple-A Framework steigern Sie die Produktivität, forcieren Innovationen und senken die Kosten. Die Softwareentwicklung gleicht heute einem Triathlon, der Kompetenzen in drei Disziplinen erfordert. Das Triple-A Framework vereint diese Elemente und bietet eine einheitliche und effektive Strategie für moderne IT-Landschaften: - Automation: Beherrschung solider Prozesse, die Qualität und Produktivität auf ein neues Niveau heben. - Agility: Entwicklung kundenorientierter Produktideen, um sich auf wechselnde Marktanforderungen einzustellen. - Acting: Beschleunigung disruptiver Innovationen, um technologiegetrieben neue Märkte zu erschließen. Jede Disziplin erfordert eine spezifische Kombination von Mindset, Methoden und Metriken. Triple-A vereint diese zu einem innovativen, ganzheitlichen Ansatz, der Unternehmen zu neuen Leistungsniveaus antreibt. Er befähigt Softwareteams, in einer zunehmend komplexeren Welt erfolgreich zu sein und die Agilitätskrise in eine Chance für den Fortschritt zu verwandeln. Herausforderungen werden als Katalysatoren für bahnbrechende Innovationen, dynamisches Wachstum und nachhaltigen Erfolg neu definiert.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 226
Veröffentlichungsjahr: 2025
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Inhaltsverzeichnis
Vorbemerkungen
Executive Summary
Navigation durch die Kapitel
1 Gewinne statt Business-Esoterik
1.1. Agile Wolkenschlösser
1.2. Führungskraft Scrum Master
1.3. High Performer für Wachstum
1.4. Triple-A: Automation, Agility, Acting
2 Die Essenz der Agilität
2.1. Agile Beschleuniger
2.1.1. Offen für die Zukunft
2.1.2. Phasen
2.1.3. Iteration
2.1.4. Zyklus
2.1.5. Takt
2.1.6. Feedback
2.1.7. Shift Left
2.1.8. Agiles Manifest
2.2. Scrum
2.2.1. Taskforce
2.2.2. Captainless
2.2.3. Events und Artefakte
2.2.4. Definition of Done
2.3. SAFe
2.4. Kanban
2.5. Frameworks
2.5.1. Frameworks für Teams
2.5.2. Strukturierte Skalierungsframeworks
2.5.3. Flexible Baukasten-Frameworks
2.6. Continuous Value
2.6.1. Wert schaffen
2.6.2. Produkt-Ziel
2.6.3. Sprint-Ziel
2.6.4. Teamwert
3 Automation First
3.1. Automatisierung ist die Basis
3.1.1. Run and Change
3.1.2. Permanenter Wandel
3.1.3. Kanban und Scrum
3.1.4. Von DevOps zu Opsless
3.1.5. Das Prinzip der Containerisierung
3.1.6. ContinuousX
3.1.7. Testabdeckung
3.2. Ingenieurskunst
3.2.1. Menschen und Werkzeuge
3.2.2. Produkt und Service
3.3. Wissensorganisation
3.3.1. Technical Backlog
3.3.2. Expert Hub
3.4. Eingebettete Einführung der Automatisierung
4 Stärke durch Qualität
4.1. Zero Tolerance
4.1.1. Das magische Dreieck lösen
4.1.2. Zero Bug
4.1.3. Zero Downtime
4.1.4. Integrationsumgebung
4.1.5. Der Dreiklang der Qualitätssicherung
4.2. Routineprozesse
4.2.1. Hindernisse beseitigen
4.2.2. Report to Action
4.2.3. Best Practices
4.2.4. Routinen und Checklisten
4.2.5. On- und Offboarding
4.2.6. Robustheit durch Routine
4.3. Performance Management
4.3.1. Die drei Säulen
4.3.2. Software Delivery Manager
4.3.3. Performance Excellence Center
5 Agilität 2.0
5.1. Arbeitsteilung
5.1.1. Kognitive Entlastung
5.1.2. Organisation ist Kommunikation
5.1.3. Handover
5.2. Skalierung
5.2.1. Skalierung durch Zeit
5.2.2. Skalierung durch Teambildung
5.2.3. Skalierung durch mehrere Teams
5.2.4. Feature versus Komponente
5.2.5. Software skalieren
5.3. Dynamische Zusammenarbeit
5.3.1. Kooperation und Koordination
5.3.2. Auftrag statt Dirigismus
5.3.3. Planwirtschaft versus Marktwirtschaft
5.3.4. Zusammenarbeit statt Autarkie
5.3.5. Kapselung statt Silo
5.3.6. Hierarchie und Entscheidung
5.3.7. Struktur und Dynamik
5.4. Software-Architektur für Menschen
5.4.1. Architektur strukturiert Anforderungen
5.4.2. Denkmuster prägen Architekturen
5.4.3. Architektur und Zusammenarbeit
5.4.4. Team Topologies
5.4.5. Integration und Inklusion
5.4.6. Standard und Vielfalt
5.4.7. Zentral versus Dezentral
5.4.8. Abhängigkeiten schaffen Werte
6 Erfolgsfaktor Projekt
6.1. Alles ist ein Projekt
6.1.1. Projekt und Produkt
6.1.2. Project Coordinator
6.1.3. Wandel durch Projekte
6.1.4. Liquid Organisation
6.2. Budget gibt es nicht geschenkt
6.2.1. Verantwortlichkeiten
6.2.2. Akquisition
6.2.3. Kalkulation
7 Der pragmatische Scrum Master
7.1. Zwei Seiten eines Teams
7.1.1. Die helle Seite
7.1.2. Die dunkle Seite
7.2. Scrum Master Routinen
7.2.1. Tägliche Tickethygiene
7.2.2. Meetings entlasten
7.2.3. Kapazitätsplanung
7.2.4. Embedded HR
7.2.5. Stakeholder
7.2.6. Vertretungsregelungen
7.2.7. Servant Leadership
7.3. Product Owner lotsen
7.3.1. Drei Sätze
7.3.2. Das Produkt verstehen
7.3.3. Mikromanagement
7.4. Developer ermächtigen
7.4.1. Overall Code Control
7.4.2. Selbstmanagement
7.5. Stakeholder managen
7.6. Das Set-up
7.6.1. Das Toolset
7.6.2. Das Skillset
7.6.3. Das Mindset
7.6.4. Das richtige Mindset
7.7. Eingebettete Einführung von Scrum
8 Von der Last zur Leistung
8.1. Inkasso technischer Schulden
8.1.1. Softwarefehler
8.1.2. Architekturschulden
8.1.3. Arbeitsschulden
8.1.4. Einwandbehandlung
8.1.5. Schuldenmanagement
8.1.6. Technische Retrospective
8.1.7. Geplante Schulden
8.2. Mit Routine Krisen managen
8.2.1. Eskalation und Skill Pump
8.2.2. Vor die Lage kommen
8.2.3. Cutover
8.2.4
.
Konflikte und Schwächen
9 Acting Organisation
9.1. Design und Disruption
9.1.1. Der innere Wert
9.1.2. Design driven Innovation
9.1.3. Die Disruption
9.2. Raum für Innovation
9.2.1. Backfeed
9.2.2. Sprint Perspective und Sprint Pitch
9.2.3. SAFe Innovation Iteration
9.2.4. Icebreaker Event
9.2.5. Skill Building
9.2.6. Psychologische Unsicherheit
9.3. Innovation generieren
9.3.1. Kreativität
9.3.2. Innovation Backlog
9.3.3. Continuous Exploration
9.3.4. Experiment-driven Development
9.3.5. ProgressiveX
9.3.6. Märkte formen
9.4. Agierende Methoden
9.4.1. Erfolg
9.4.2. Passgenauigkeit
9.4.3. Beschleunigung
9.4.4. Shift Ahead
9.4.5. Extreme Thinking
9.4.6. Entscheiden
9.4.7. Vereinfachen
9.4.8. Descaling
9.5. Team Building
9.5.1. Tandem Worker
9.5.2. Quarterback Team
9.5.3. Product Founder
9.6. Acting Scrum
9.6.1. Definition
9.6.2. Artefakte
9.6.3. Events
9.7. Eingebettete Einführung von Acting
10 Triple-A
10.1. Der Kontext
10.2. Das Framework
10.2.1. Automatisierung
10.2.2. Agilität
10.2.3. Agieren
10.3. Die Aspekte
10.4. Schlüsselindikatoren
10.4.1. Indikatoren für Automatisierung
10.4.2. Indikatoren für Agilität
10.4.3. Indikatoren für Acting
10.4.4. Technische Bilanz
10.5. Die Aufstellung
10.6. Die Dynamik
Epilog
Autor
Vorbemerkungen
Zitate aus dem Scrum Guide1 sind der Version 2020 entnommen.
Die deutsche Fassung des Scrum Guides verwendet für zentrale Begriffe wie Scrum Team, Product Owner, Increment und Scrum Master meist die englische Version. Dem wird in diesem Buch gefolgt. Auch darüber hinaus werden branchenübliche englische Begriffe verwendet.
In Anlehnung an den Scrum Guide wird der Begriff „Developer“ stellvertretend für alle umsetzenden Tätigkeiten verwendet.
1https://scrumguides.org/
Executive Summary
Die Kunst der Softwareentwicklung ist ein anspruchsvoller Triathlon in den drei Disziplinen Automatisierung, Agilität und Acting.
Triple-A vereint die drei Disziplinen zu einem kraftvollen Framework, das sowohl in der Softwareentwicklung als auch darüber hinaus wirkmächtig ist.
Automatisierung
schafft stabile Abläufe, die eine hochwertige Entwicklung sowie einen reibungslosen Betrieb gewährleisten.
Agilität
orientiert sich an den Kundenbedürfnissen und stärkt die Wettbewerbsfähigkeit in etablierten Märkten.
Acting
(Agieren) ist technologiegetrieben, disruptiv und erschließt neue Märkte.
Alle drei Disziplinen haben ihr eigenes Framework mit individuellen Mindsets, Methoden und Metriken. Triple-A führt diese erstmalig zu einem neuen, umfassenden Gesamtframework zusammen.
Agile Frameworks sind für eine Welt der Jahrhundertwende konzipiert. Teams sollen autark agieren, obwohl heute die Zusammenarbeit mit Dutzenden von Teilzeit-Teammitgliedern notwendig ist. Abhängigkeiten werden vermieden, obwohl sie einen großen Mehrwert bieten. Es ist an der Zeit, die agilen Konzepte weiter voranzutreiben.
Wenn Agilität in einer Organisation scheitert, liegt es nicht am „Mindset“ oder an dem agilen Framework. Grundlegend für den Erfolg von Agilität ist eine leistungsstarke Automatisierung als Fundament. Automatisierung erfordert höchste Disziplin, die rasche Beseitigung von Fehlern und Schwachstellen sowie ein konsequentes Inkasso technischer Schulden.
Acting ist das dritte Framework. Während agile Frameworks kundenorientiert und mit schrittweisen Anpassungen in bestehenden Märkten arbeiten, ist Acting technologiegetrieben und disruptiv auf der Suche nach neuen Märkten. Der Descaling-Ansatz von Acting vereinfacht die Organisation und ihre Arbeitsweise, anstatt agile Praktiken und Methoden auf eine größere, komplexere Ebene zu skalieren.
Seit rund 25 Jahren ist Software in Umfang und Komplexität gewachsen, die Abhängigkeiten haben zugenommen und die Zahl der Beteiligten ist gestiegen. Gleichzeitig sind die Anforderungen an Compliance, Sicherheit, Bedienbarkeit und vieles mehr angestiegen. Die Zuständigkeiten der Entwicklungsteams wurden auf den Anwendungsbetrieb ausgeweitet. Scrum Master organisieren um das Kernteam herum die virtuelle Organisation mit einem Heer von Experten und Partnern.
Je mehr die Daten und nicht mehr die Kunden laufen, desto intensiver wird die Zusammenarbeit zwischen den Teams und ihrer Software. Scrum Master wirken als Netzwerk für die Dynamik einer Organisation.
Methoden der Softwareentwicklung dienen zunehmend als Blaupause für die gesamte Organisationen. Software wird ausschließlich von Menschen gemacht. Die Anforderungen einer dienstleistungsorientierten Gesellschaft spiegeln sich in verdichteter Form in der Softwareentwicklung wider.
Umsetzungsstarke Scrum Master sind die treibenden Führungskräfte des permanenten Wandels auf operativer Ebene. Die Bezeichnung Scrum Master ist jung, ihre Rolle gab es bereits in der Antike und ist als Quartiermeister bekannt.
Scrum Master führen ein Team zum High Performer. Damit beeinflussen sie direkt das wirtschaftliche Ergebnis. Umsätze und Gewinne, Aktienkurse und Renditen hängen signifikant von der Leistungsfähigkeit der Softwareentwicklung ab.
High Performer haben ein 50 Prozent höheres Wachstum der Marktkapitalisierung im Lauf von drei Jahren im Vergleich zu Low Performern.
Das Triple-A Framework befähigt Organisationen, ihre Produktivität zu stärken, Innovationen zu entfachen und Kosten zu senken.
Navigation durch die Kapitel
1 Gewinne statt Business-Esoterik
Dies ist keine Einführung in Scrum. Sie erfahren auch nicht viel über Motivation, Purpose oder Kreativitätstechniken. Sie können diese Themen an anderer Stelle lesen. Hier geht es um Veränderung in einem schwierigen Umfeld, um Scrum Master, die die Realität meistern.
Als Scrum Master gibt Ihnen dieses Buch das nötige Rüstzeug, um Ihr Projekt trotz aller Herausforderungen und Widerständen aktiv zum Erfolg zu führen.
Als Organisation lernen sie, wie Softwareentwicklung die rasant steigende Komplexität in drei Disziplinen professionell meistert und zum Umsatz- und Gewinntreiber wird.
1.1. Agile Wolkenschlösser
Mit dem Agilen Manifest von 2001 wurden Kundennutzen, Flexibilität und Zusammenarbeit in den Fokus gerückt. Weit über die Softwareentwicklung hinaus hat die Idee der Agilität Eingang in den Kanon der Geschäftswelt gefunden. Agilität soll alte Hierarchien, Silos und Autoritäten abschaffen. Ohne Angst würden die Teams für eine glückliche und prosperierende Zukunft arbeiten. Selbstorganisiert und selbstverwirklicht erstrahlen die beste IT-Architektur und die unglaublichste Software.
Agilität ist allzu oft nur ein wohlklingendes Buzzword, mit dem das altbekannte Chaos kaschiert wird. Man schmückt sich damit, hat aber den Kern nicht verstanden. Product Owner verstehen sich als Projektleiter alter Schule. Software-Qualität wird weiterhin als lästiges Übel betrachtet. Die Developer sind brave Befehlsempfänger. Scrum Master stehen am Rand und geben den Motivationsguru. Es blüht mehr Business-Esoterik als echte Agilität.
1.2. Führungskraft Scrum Master
Scrum Master sind Führungskräfte für die Organisation. Scrum Master stehen im Zentrum der organisatorischen Transformation. Sie sind die operativen Schlüsselakteure, die Teams als auch die gesamte Organisation befähigen, den kontinuierlichen Wandel zu steuern.
Leider springen viele Scrum Master zu kurz. Sie sind häufig als folgende Typen anzutreffen:
Animateur
: Versteht sich als Feel-Good-Manager und sorgt für fancy Meetings.
Bürokrat
: Erledigt die Scrum-Formalitäten, füllt Scrum aber nicht mit Leben.
Click Master
: Moderiert die Meetings und klickt durch die Tickets.
Zaungast
: Beobachtet das Team und gibt gelegentlich Tipps.
Scrum Master führen ein Projekt auch in einem herausfordernden und schwierigen Umfeld zum Erfolg. Sie beseitigen Hindernisse (impediments) für den Fortschritt des Scrum Teams. Sie gestalten aktiv und kraftvoll die Prozesse im Team und Organisation.
Dieses Buch vermittelt Scrum Master die erforderlichen Kenntnisse und passgenauen Werkzeuge für ihre Arbeit im Team und in der gesamten Organisation.
1.3. High Performer für Wachstum
Organisationen sind oft näher am Zusammenbruch als an der Perfektion. Pragmatismus und Engagement der Mitarbeiter verhindern ihren Untergang. Diese dunkle Seite einer Organisation ist das Betätigungsfeld der Scrum Master. Sie sind besonders gefragt, wenn es hart auf hart kommt. Scrum Master führen ein Team zum High Performer. Damit beeinflussen sie direkt das wirtschaftliche Ergebnis. Umsätze und Gewinne, Aktienkurse und Renditen hängen signifikant von der Leistungsfähigkeit der Softwareentwicklung ab.
Nicole Forsgren, Jez Humble und Gene Kim untersuchten mehrere Unternehmen2 und stellten fest:
High Performer in der Softwarebereitstellung erreichen 46-mal mehr Deployments als Low Performer, sind 440-mal schneller im Prozess von der Auftragsvergabe (commit) bis zur Fertigstellung und haben eine fünffach geringere Fehlerquote bei Änderungen.
High Performer haben ein 50 Prozent höheres Wachstum der Marktkapitalisierung im Lauf von drei Jahren im Vergleich zu Low Performern.
Wenn ein Unternehmen immer mehr auf eigenentwickelte Software angewiesen ist, kann es durch eine leistungsstarke Softwareentwicklung Umsatz und Gewinn steigern und gleichzeitig die Kosten senken. Gelingt dies nicht, ist das Verschwinden vom Markt unvermeidlich.
1.4. Triple-A: Automation, Agility, Acting
Agile Frameworks sind für eine Welt der Jahrhundertwende konzipiert. Teams sollen autark agieren, obwohl heute die Zusammenarbeit mit Dutzenden von Teilzeit-Teammitgliedern notwendig ist. Abhängigkeiten werden vermieden, obwohl sie einen großen Mehrwert bieten. Es ist an der Zeit die agilen Konzepte weiter voranzutreiben.
Neben Agilität braucht Softwareentwicklung ein starkes Fundament: Automatisierung. Durch die Automatisierung der gesamten Pipeline, von der Integration aller Softwaremodule über die Testautomatisierung bis hin zur vollautomatischen Installation, wird eine hohe Qualität und Produktivität erzielt.
Agile Methoden sind kundenzentriert. Disruptive Organisationen arbeiten jedoch nicht kundenzentriert, sondern technologiegetrieben, nicht reagierend, sondern agierend. Sie entwickeln keine verbesserten Produkte, sondern völlig neue. Agieren (Acting) statt nur reagieren ist die nächste Herausforderung für eine Organisation.
Das Triple-A-Framework basiert auf der Automatisierung, einer weiterentwickelten Agilität für die Kundenorientierung und der agierenden (acting) Organisation für die disruptive Schaffung neuer Märkte.
Triple-A verbindet Automatisierung, Agilität und Acting zu einem integrierten Framework für IT-Projekte und mehr.
2 Nicole Forsgren, Jez Humble, Gene Kim: Das Mindset von DevOps. Accelerate 2019
2 Die Essenz der Agilität
Software bildet eine wesentliche Grundlage für hohe Flexibilität und Anpassungsfähigkeit. Software kann viel leichter geändert werden als Hardware. Das bedeutet aber, dass industrielle Strukturen, die für die Entwicklung von Hardware konzipiert wurden, nicht für die Entwicklung von Software angewendet werden sollten. Andernfalls verspielt man einen entscheidenden Vorteil von Software: die Fähigkeit, sich schnell und flexibel an Marktveränderungen anzupassen.
Als Reaktion darauf entstanden um das Jahr 2000 agile Methoden. Sie sind effektiver und effizienter in der Softwareentwicklung als traditionelle Vorgehensweisen. Dieses Kapitel beleuchtet die grundlegenden Elemente der Agilität. Sie bilden den Ausgangspunkt für die weiteren Überlegungen.
2.1. Agile Beschleuniger
Software Engineering (1968) etablierte das Phasenmodell als Fundament der Softwareentwicklung. Agile Konzepte bauen auf dieser Grundlage auf und legen den Schwerpunkt auf kurze Iterationen, die durch eine Reihe ergänzender Elemente verstärkt werden.
2.1.1. Offen für die Zukunft
Wir können nur begrenzt in die Zukunft schauen. Agilität geht davon aus, dass eine vollständige Planung nicht machbar ist und Veränderungen jederzeit möglich sind. Vom preußischen Generalfeldmarschall Graf von Moltke ist der Satz überliefert: „Kein Plan überlebt die erste Feindberührung.“
Das Agile Manifest formuliert als vierten Wert:
„Reagieren auf Veränderung mehr als das Befolgen eines Plans“
Und weiter als 2. Prinzip:
„Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“
Agilität bietet Organisationen einen strukturierten Rahmen, um neue Anforderungen jederzeit professionell zu meistern. Anpassungsfähigkeit ist das Können, um auf Veränderungen zu reagieren. Agile Organisationen blicken daher offen in die Zukunft.
2.1.2. Phasen
Jede Entwicklung folgt dem Phasenmodell, auch Wasserfallmodell genannt. Natürlich sind Fachwissen und Anforderungen Voraussetzungen, bevor die Entwicklung beginnen kann.
Phasenmodell: Nach der Planung folgt die Entwicklung, dann die Zusammenführung und Integration der Komponenten (Build), anschließend die Qualitätssicherung (Testung), zuletzt die Verteilung (Deployment) und der Betrieb (Operation).
Die Softwareentwicklung durchläuft in der Regel mehrere Phasen von der ersten Idee bis zum fertigen Produkt. Die Planungsphase wird bestimmt durch die Anforderungsanalyse, in der die Bedürfnisse des Kunden ermittelt werden, und die Konzepterstellung.
In der Entwicklungsphase findet die eigentliche Programmierung statt. Der Zusammenbau (Build-Phase) schließt sich in der Regel direkt daran an. In dieser Phase werden die einzelnen Module zusammengeführt und der gesamte Quellcode in eine ausführbare Datei übersetzt, beispielsweise eine exe-Datei bei Windows-Anwendungen. Es folgt eine intensive Testphase, um sicherzustellen, dass die Software fehlerfrei funktioniert. Schließlich wird die Software installiert und in Betrieb genommen.
Dieser Prozess kann je nach Komplexität des Projekts und der gewählten Methodik variieren. Reibungslose Übergänge zwischen den Phasen erfordern strukturierte und gut koordinierte Übergaben (Handover).
2.1.3. Iteration
Einer Anekdote zufolge soll Albert Einstein seinen Studenten die gleiche Abschlussprüfung wie im Vorjahr gestellt haben. Ein Assistent wies ihn darauf hin. Die Antwort: „Es sind die gleichen Fragen, aber die Antworten haben sich geändert.“
Der ständige Wandel zwingt Organisationen, sich immer wieder anzupassen. Deshalb arbeiten wir in der Softwareentwicklung iterativ und reagieren in jeder Iteration auf die Veränderungen. Das war schon im sogenannten Wasserfallmodell so. Der Hauptunterschied zu heute bestand in den deutlich längeren Zeitabständen zwischen zwei Iterationen. In der Vergangenheit war die Automatisierung in der Softwareentwicklung weit weniger verbreitet. Dies erforderte langwierige manuelle Test- und Stabilisierungsphasen, die nur vierteljährliche oder halbjährliche Releases zuließen.
Heute arbeiten die Teams dank hoher Automatisierung in Iterationen von wenigen Wochen. Im agilen Framework Scrum wird eine Iteration als Sprint bezeichnet. Neben der schnelleren Anpassung ermöglicht die kurze Taktung auch ein früheres Feedback, sodass notwendige Korrekturen schneller erkannt werden.
In agilen Organisationen werden nicht nur Produkte iterativ entwickelt, um so früh wie möglich Wert zu schaffen, sondern auch die Organisation entwickelt sich mit jeder Iteration weiter. Entwicklung folgt generell einem iterativen Muster, sei es in der Natur (Evolution), in der Kunst oder in der Technik.
Jede von Menschen gestaltete Iteration umfasst Planung, Umsetzung und Lieferung. Dies gilt auch für agile Vorgehensweisen. Die Bildung eines Gegensatzes von traditionellem Wasserfallmodell und moderner Agilität ist nicht zielführend. Der entscheidende Unterschied zwischen der Softwareentwicklung früher und heute ist die wesentlich kürzere Zeitspanne für eine Iteration.
Der immer schneller werdende Wettbewerb erfordert kürzere Iterationen, und dank der Automatisierung sind sie auch möglich. Während früher eine Iteration mehrere Monate dauerte, sind es heute nur noch wenige Wochen. Die viel kürzeren Iterationen ermöglichen eine bessere Anpassungsfähigkeit. Dies ist der Schlüssel zur Agilität.
2.1.4. Zyklus
Der Software-Zyklus umfasst alle Phasen einer Iteration von der Planung bis zum Betrieb. Der Software-Lebenszyklus erstreckt sich über den gesamten Lebenszyklus der Software von der ersten Planung bis zur Außerbetriebnahme. Die Weiterentwicklung wird klassischerweise als Wartung bezeichnet. Der Entwicklungszyklus wurde bei manchen Projekten nur einmal durchlaufen, daher war ein Unterschied zwischen Zyklus und Lebenszyklus kaum erkennbar.
Heute wird Software viel intensiver und in kürzeren Abständen an Marktveränderungen angepasst. Während in der traditionellen Softwareentwicklung eine Iteration mehrere Monate dauert, arbeiten agile Teams typischerweise mit einer zweiwöchigen Iteration. Die Software befindet sich in einer kontinuierlichen Weiterentwicklung (Continuous Development).
Leistungsstarke Teams führen die Qualitätssicherung nicht erst am Ende einer Iteration durch, sondern bei jeder Änderung. Sobald ein Developer eine Änderung am Code freigibt, dem sogenannten Commit, wird eine Testautomatisierung ausgeführt, um das gesamte Softwaresystem zu überprüfen. Ein Testdurchlauf dauert typischerweise rund 15-60 Minuten. Dies stellt sicher, dass die Änderung korrekt funktioniert und keine unbeabsichtigten Nebeneffekte verursacht.
In der traditionellen Arbeitsweise folgt auf eine lange Entwicklungsphase die Testphase. Im agilen Prozessmodell wird die Entwicklung in kurze Iterationen (Sprints) unterteilt und fehlerfrei ausgeliefert. High Performer führen Tests nach jeder Änderung (Commit) durch.
Ein zentraler Treiber zur Beschleunigung liegt in der Automatisierung der Phasen. Die Abfolge der Phasen wird üblicherweise als Pipeline bezeichnet. Heute können die Phasen Aufbau, Testung, Verteilung und Betrieb vollständig automatisiert werden. Statt mehrerer Wochen oder gar Monate beanspruchen diese Phasen nun nur noch etwa eine Stunde. Dadurch verkürzt sich die Dauer der einzelnen Iterationen drastisch. Dies führt zu einer enormen Beschleunigung, einem Boost für den Time-to-Market.
Automatisierung beschleunigt die Phasen drastisch.
Innerhalb einer zweiwöchigen Iteration werden die Phasen von der Entwicklung bis zum Test wiederholt durchlaufen. Falls erforderlich, werden Änderungen sofort in der Produktion bereitgestellt, sodass ein Go-Live während eines Sprints häufiger erfolgen kann.
Wer Tausende von Änderungen sammelt und erst dann mit dem Testen beginnt, schafft Komplexität. Wer direkt nach jeder Änderung testet, zerlegt die Arbeit in eine Vielzahl einfacher Aufgaben.
Zur Erinnerung sei noch einmal die Studie von Nicole Forsgren, Jez Humble und Gene Kim zitiert: „High Performer im Bereich der Softwarebereitstellung schaffen 46-mal mehr Code-Fertigstellungen als Low Performer, sind 440-mal schneller im Prozess von der Auftragserteilung bis zur Fertigstellung.“
2.1.5. Takt
Das Ziel ist es, die Iterationen (Sprints) so kurz wie möglich zu takten. Wenn der Sprint jedoch zu kurz ist, kann der Aufwand für die Aktivitäten des agilen Frameworks die Produktivität verlangsamen.
Die ideale Dauer eines Sprints bemisst sich an der Iterationsleistung, d.h. so schnell wie möglich in einer Iteration maximalen Wert zu erreichen. Zu den entscheidenden Faktoren gehören die Leistung des Teams, die Komplexität des Produkts und das übergeordnete Ziel. High-Performer-Teams meistern nicht nur kurze Sprints, sondern werden dadurch sogar gepusht.
Der Schwierigkeitsgrad einer Software für ein Flugzeug ist sicherlich ein anderer als für eine Kundenverwaltung. Allerdings hängt auch das von der Leistungsfähigkeit des Teams ab. Was für das eine Team herausfordernd ist, kann für das andere zur Routine gehören. In vielen Organisationen dauert ein typischer Sprint heute zwei Wochen. Von Tesla wird berichtet, dass einige Teams mit drei-Stunden-Sprints arbeiten.3
In großen Organisationen bietet die Synchronisierung aller Teams Vorteile. Es gibt jedoch Gründe, von der allgemeinen Taktung abzuweichen und sogar die Taktung innerhalb eines Projekts zu ändern.4
2.1.6. Feedback
In engem Zusammenhang mit dem Iterationsprinzip steht das Feedback. Der Nutzen einer Software wird nach jeder Auslieferung durch das Verhalten der Kunden überprüft und den Kunden wird die Möglichkeit gegeben, direktes Feedback zu geben.
Das Ziel ist es, Feedback schnell und so früh wie möglich einzuholen. Die Software wird bereits während der Entwicklung laufend automatisiert getestet. Dies führt zu schnellem Feedback an die Developer und sichert die Qualität. Kontinuierliches Monitoring im Betrieb sorgt für ein Frühwarnsystem.
Darüber hinaus generieren Teams ihr eigenes Feedback durch Selbstreflexion in einer Retrospective. Eine Retrospective am Ende eines Sprints dient der Überprüfung, wie der letzte Sprint verlief. Ziel ist es, Verbesserungsmöglichkeiten für zukünftige Sprints zu identifizieren und die Qualität und Effektivität kontinuierlich zu steigern.
Es gibt einen großen Werkzeugkasten mit Methoden für eine Retrospective. Zum Beispiel können gewonnene Erkenntnisse mithilfe des KALM-Rahmens strukturiert werden:
Keep
: Behalte bewährte Praktiken bei, die den Arbeitsfluss und die Zusammenarbeit verbessern.
Add
: Führe neue Ideen oder Werkzeuge ein, die den Arbeitsablauf optimieren.
Less
: Reduziere Elemente, die die Produktivität behindern oder nur geringen Mehrwert bieten.
More
: Wende möglichst häufig effektive Praktiken an, um den Erfolg zu steigern.
Verbesserungsmaßnahmen können aus diesen Erkenntnissen abgeleitet werden. In klassischen Projekten werden Lessons-Learned Sitzungen erst am Ende des Projekts durchgeführt. Im agilen Kontext finden Retrospectives mindestens einmal pro Iteration statt. Und sie fließen direkt in die Verbesserung der folgenden Iterationen ein.
Feedback hilft den Entwicklungsteams, den Produktwert mit jeder Iteration zu steigern. Ständige Überprüfung und Anpassung, Inspect and Adapt, strukturieren Lernprozesse. Ziel ist die kontinuierliche Verbesserung: Improve Everything.
2.1.7. Shift Left
Eine alte Regel besagt, dass ein Fehler umso teurer wird, je später er entdeckt wird. Es gilt, Fehler bereits in der Entwicklungsphase zu erkennen und abzufangen, bevor sie beim Kunden sichtbar werden. Shift Left bedeutet, Probleme so früh wie möglich im Prozess zu lösen, also auf der linken Seite der Zeitleiste.
Dies gilt insbesondere für Entwicklungs- und Supportprozesse. Wenn nach jedem Commit automatisierte Tests die Qualität sicherstellen, wird ein Fehler oder eine Schwachstelle erkannt, solange die Developer die Codeänderungen noch frisch im Gedächtnis haben. Dies reduziert den Aufwand für die Fehlerbehebung.
Fehler oder Änderungsbedarf in der Softwareentwicklung werden umso teurer, je später sie erkannt werden.
Grundsätzlich stellt das Shift-Left-Prinzip sicher, dass Aufgaben so früh wie möglich abgeschlossen und Informationen frühzeitig eingeholt werden. Shift Left weiter gedacht führt zu gutem Design, so dass Fehler gar nicht erst entstehen. Quality by Design ist zusammen mit Produktorientierung, kontinuierlicher Verbesserung und Prozessautomatisierung Teil der agilen Agenda. Konzepte wie Selbstbedienungs- und selbstheilende Systeme, testgetriebene Entwicklung und datengesteuerte Optimierung stärken dieses Prinzip.
Defect
Im Laufe der Zeit haben sich verschiedene Bezeichnungen für Fehler (Defect) eingebürgert, die je nach Kontext verwendet werden. Die Verwendung kann jedoch von Organisation zu Organisation und sogar von Team zu Team variieren.
Bug: Ein Fehler im Softwarecode.
Error: Ein Fehler während der Programmausführung, der den Nutzern typischerweise als „Error“-Meldung angezeigt wird.
Incident: Eine unerwartete Betriebsstörung, die durch Probleme im Code, einen Hardwaredefekt oder andere Ursachen entstehen kann.
Issue: Ein allgemeines Problem, das durch einen oder mehrere Fehler verursacht werden kann.
Das Prinzip „Shift Left“ durchzieht die Idee der Agilität. Mit Stakeholdern wird von Anfang an und fortwährend zusammengearbeitet. Produkte werden frühzeitig an den Kunden geliefert. Ändern sich die Bedingungen, können sich Teams schnell anpassen.
2.1.8. Agiles Manifest
Das Agile Manifest (2001) ist der wichtigste Orientierungspunkt für die agile Softwareentwicklung. Die vier Werte und zwölf Prinzipien des agilen Manifests geben den Rahmen für agile Arbeitsweisen vor. Die Essenz des Manifests lautet: Liefere funktionierende Software. Das bedeutet, dass die Software Wert schafft, frei von bekannten Fehlern ist und zum vereinbarten Zeitpunkt geliefert wird. Dies sollte eine Selbstverständlichkeit sein. Leider sah und sieht die Realität anders aus, was die Motivation für das Agile Manifest war.
Kernaussagen des agilen Manifests
Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.Prozesse und Tools sind wichtig, sollten jedoch leichtgewichtig gehalten werden. Wesentlich wichtiger ist die intensive Kommunikation zwischen allen Beteiligten, damit es am Ende nicht heißt: „Ach, so war das gemeint.“
Funktionierende Software ist wichtiger als umfassende Dokumentation.Funktionierende Software hat Vorrang vor Softwarebürokratie. Dennoch ist die Dokumentation wichtig und hilfreich, auch wenn agile Entwicklung den Fokus auf die Ergebnisse legt.
Kundenzusammenarbeit ist wichtiger als Vertragsverhandlung.Eine vertrauensvolle Zusammenarbeit zwischen Kunde und Softwarelieferant bedeutet, dass sie wirklich zusammenarbeitet. Die Vertragsunterzeichnung ist lediglich der Anfang. Agile Verfahren sind auf den Kunden fokussiert. Durch häufige Softwarelieferungen können Kunden schneller testen und Feedback geben.
Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.Pläne und Konzepte sind wichtig und notwendig. Veränderungen sollten jedoch als Chance begriffen und nicht als Störung empfunden werden. Strukturen müssen für Veränderungen ausgelegt sein.
Die tiefere Idee des Manifests ist die Erkenntnis, dass Software von Menschen gemacht wird und dass die Zusammenarbeit von Menschen über das Wohl und Wehe von Software entscheidet. Daher lassen sich die agilen Konzepte über die Software hinaus anderweitig anwenden. Die Prinzipien und Methoden der IT können in der ganzen Organisation angewendet werden. Mehr noch: Ist erst einmal die IT agil ausgerichtet, zieht sie andere Bereiche nach sich, die ebenfalls agil werden. Deshalb spricht man inzwischen auch von einer agilen Organisation.
2.2. Scrum
Scrum ist ein agiles Framework um komplexe Aufgaben in der Softwareentwicklung zu meistern. Es basiert auf kleinen, selbstorganisierten Teams, die in kurzen Entwicklungszyklen, so genannten Sprints, arbeiten. Während eines Sprints, der in der Regel zwei bis vier Wochen dauert, entwickelt das Team das Produkt schrittweise weiter und steigert dessen Wert. Transparenz, Überprüfung und Anpassung bilden die Säulen von Scrum.
Die Teammitglieder kommunizieren und arbeiten in regelmäßigen Scrum-Events zusammen. Nach jedem Sprint findet eine Überprüfung der Arbeit statt, um Feedback einzuholen und den nächsten Sprint zu planen. Scrum fördert Flexibilität, kontinuierliche Verbesserung und die Fokussierung auf die Anforderungen des Kunden.
Scrum wurde ab 1993 von Jeff Sutherland und Ken Schwaber formalisiert. Der Scrum Guide wird regelmäßig weiterentwickelt, um Neuerungen einzubeziehen.
2.2.1. Taskforce
Die Wirkung von Scrum beruht auf dem Prinzip einer gut organisierten Taskforce, die ständig wiederverwendet und weiterentwickelt wird. Alle relevanten Personen sind vertreten und die Kommunikationswege sind kurz. Mit jedem Sprint verbessern sich der Produktwert, die organisatorischen Prozesse und die Teamleistung.
