Home

05 Agile Entwicklung Teil 2: Scrum-Framework und praktische Anwendung

January 2026 (6321 Words, 36 Minutes)

lecture agile scrum sprints user-stories project-management

1. Einführung: Von Praktiken zum Prozess

In Teil 1 haben wir die philosophische Grundlage der agilen Entwicklung erkundet:

Wir haben diese Konzepte auch auf unser Road Profile Viewer-Projekt angewendet, User Stories mit Akzeptanzkriterien geschrieben und gelernt, wie man sie mit GitHub Issues verfolgt.

Aber Praktiken allein machen ein Projekt nicht erfolgreich. Sie brauchen auch ein Framework zur Organisation der Arbeit: Wer entscheidet, was als nächstes gebaut wird? Woher wissen Sie, wann etwas “fertig” ist? Wie verbessern Sie sich im Laufe der Zeit?

In dieser Vorlesung untersuchen wir Scrum — das am weitesten verbreitete agile Framework. Wir werden sehen, wie Scrums Rollen, Ereignisse und Artefakte Struktur bieten und gleichzeitig die agile Flexibilität beibehalten. Dann wenden wir Scrum auf einen konkreten Sprint für den Road Profile Viewer an und schließen mit realen Belegen, dass Agile auch in den anspruchsvollsten Umgebungen funktioniert.

2. Lernziele

Am Ende dieser Vorlesung werden Sie in der Lage sein:

  1. Die drei Scrum-Rollen zu beschreiben und ihre Verantwortlichkeiten (Product Owner, Entwicklungsteam, Scrum Master)
  2. Die fünf Scrum-Ereignisse zu erklären und ihren Zweck (Sprint, Planning, Daily Scrum, Review, Retrospektive)
  3. Die drei Scrum-Artefakte zu unterscheiden (Product Backlog, Sprint Backlog, Produktinkrement)
  4. Einen realistischen Sprint zu planen für ein kleines Teamprojekt, einschließlich Ziel, Backlog und Zeitplan
  5. Die Einführung von Agile in der realen Welt zu erkennen, einschließlich in hochregulierten Umgebungen wie dem US-Militär
  6. Scrum-Praktiken mit Testing zu verbinden — verstehen, wie Sprints sich mit TDD und CI integrieren

3. Scrum-Framework

Während XP technische Praktiken bereitstellt, bietet Scrum ein Management-Framework zur Organisation agiler Arbeit. Erstellt von Ken Schwaber und Jeff Sutherland in den frühen 1990er Jahren (und erstmals öffentlich auf der OOPSLA-Konferenz 1995 vorgestellt), ist Scrum zum weltweit am weitesten verbreiteten agilen Framework geworden.

3.1 Was ist Scrum?

Der offizielle Scrum Guide definiert Scrum als:

“Ein leichtgewichtiges Framework, das Menschen, Teams und Organisationen hilft, durch adaptive Lösungen für komplexe Probleme Wert zu generieren.”

Beachten Sie, was Scrum nicht ist: Es ist keine Methodologie, kein Prozess, kein Regelwerk, das blind befolgt werden muss. Es ist ein Framework — eine minimale Struktur, die Teams an ihren spezifischen Kontext anpassen.

Kurz gesagt funktioniert Scrum so:

  1. Ein Product Owner ordnet die Arbeit für ein komplexes Problem in einem Product Backlog
  2. Das Scrum-Team wandelt eine Auswahl der Arbeit während eines Sprints in ein Inkrement von Wert um
  3. Das Scrum-Team und seine Stakeholder inspizieren die Ergebnisse und passen für den nächsten Sprint an
  4. Wiederholen

Das ist alles. Alles andere in Scrum existiert, um diese vier Schritte effektiv zu machen.

3.2 Scrum-Theorie: Empirismus und Lean Thinking

Scrum basiert auf zwei intellektuellen Traditionen:

Empirismus — Wissen kommt aus Erfahrung und dem Treffen von Entscheidungen basierend auf dem, was beobachtet wird, nicht auf dem, was vorhergesagt wird. Dies verbindet sich direkt mit Herbert Simons begrenzter Rationalität aus Teil 1: Da wir komplexe Systeme nicht vollständig vorhersagen können, müssen wir durch Handeln lernen.

Lean Thinking — Verschwendung reduzieren und sich auf das Wesentliche konzentrieren. Jedes Element in Scrum existiert aus einem Grund; wenn etwas keinen Wert beiträgt, eliminieren Sie es.

Diese Grundlagen manifestieren sich in Scrums drei Säulen:

graph LR
    subgraph Pillars["Drei Säulen von Scrum"]
        T[Transparenz] --> I[Inspektion]
        I --> A[Anpassung]
    end
Säule Bedeutung In der Praxis
Transparenz Die Arbeit und der Prozess müssen für diejenigen sichtbar sein, die die Arbeit ausführen und erhalten Sprint-Boards, Daily Standups, öffentliche Backlogs
Inspektion Häufiges Überprüfen von Fortschritt und Artefakten, um Probleme früh zu erkennen Sprint Reviews, Retrospektiven, tägliche Check-ins
Anpassung Wenn die Inspektion Probleme aufdeckt, sofort den Prozess oder das Produkt anpassen Backlog-Neupriorisierung, Prozessverbesserungen, Scope-Verhandlung

Die zentrale Erkenntnis: Inspektion ohne Transparenz ist irreführend. Anpassung ohne Inspektion ist sinnlos. Alle drei Säulen müssen zusammenwirken.

3.3 Die fünf Scrum-Werte

Der Scrum Guide betont, dass erfolgreiche Scrum-Anwendung davon abhängt, dass Menschen “kompetenter darin werden, fünf Werte zu leben”:

Commitment, Fokus, Offenheit, Respekt und Mut

Dies sind nicht nur nette Worte auf einem Poster. Jeder Wert dient einem praktischen Zweck:

Für Ihr Road Profile Viewer-Projekt: Wenn ein Teammitglied mit einer Funktion kämpft, bedeutet Respekt, darauf zu vertrauen, dass sie es lösen können, während Offenheit bedeutet, dass sie um Hilfe bitten, wenn nötig. Mut bedeutet zuzugeben “Ich verstehe diese Anforderung nicht”, anstatt das Falsche zu bauen.

3.4 Die Struktur: 3-5-3

Scrum definiert eine minimale, aber vollständige Struktur:

Jedes Artefakt hat auch eine Verpflichtung, die Fokus bietet:

Lassen Sie uns jede Komponente im Detail betrachten.

3.5 Die drei Verantwortlichkeiten

Rolle Verantwortlichkeiten NICHT verantwortlich für
Product Owner
  • Definiert und priorisiert das Product Backlog
  • Repräsentiert den Kunden/Stakeholder
  • Akzeptiert oder lehnt abgeschlossene Arbeit ab
  • Kommuniziert die Produktvision
  • Technische Implementierungsentscheidungen
  • Aufgaben an Einzelpersonen zuweisen
  • Das Entwicklungsteam managen
Entwicklungsteam
  • Selbstorganisierend (entscheidet, wie die Arbeit erledigt wird)
  • Cross-funktional (hat alle benötigten Fähigkeiten)
  • Liefert ein potenziell releasefähiges Inkrement jeden Sprint
  • Typischerweise 3-9 Personen
  • Das Backlog priorisieren
  • Stakeholder-Kommunikation (das ist die Aufgabe des PO)
  • Sub-Teams oder Hierarchien
Scrum Master
  • Moderiert Scrum-Ereignisse
  • Entfernt Hindernisse, die das Team blockieren
  • Coacht das Team in Scrum-Praktiken
  • Schützt das Team vor äußeren Störungen
  • Das Team managen (keine Manager-Rolle)
  • Technische Entscheidungen treffen
  • Arbeit zuweisen

3.6 Die fünf Ereignisse

Scrum definiert fünf zeitlich begrenzte Ereignisse (Zeremonien):

graph LR
    subgraph Sprint["Sprint (1-4 Wochen)"]
        SP[Sprint Planning] --> DS[Daily Scrum]
        DS --> DS
        DS --> SR[Sprint Review]
        SR --> RT[Retrospektive]
    end
    RT --> SP2[Nächstes Sprint Planning]
Ereignis Dauer Zweck Ergebnis
Sprint 1-4 Wochen (fest) Container für alle anderen Ereignisse; Zeit, um ein Inkrement zu produzieren Potenziell releasefähiges Produktinkrement
Sprint Planning 2-4 Stunden Arbeit für den Sprint auswählen; Sprint-Ziel definieren Sprint Backlog und Sprint-Ziel
Daily Scrum 15 Minuten Team synchronisieren; Blocker identifizieren; nächste 24 Stunden planen Aktualisierter Plan für den Tag
Sprint Review 1-2 Stunden Abgeschlossene Arbeit den Stakeholdern demonstrieren; Feedback sammeln Feedback für Product-Backlog-Updates
Sprint-Retrospektive 1-2 Stunden Über den Prozess reflektieren; Verbesserungen identifizieren Aktionspunkte für den nächsten Sprint

3.7 Die drei Artefakte

Artefakt Beschreibung Eigentümer Beispiel
Product Backlog Priorisierte Liste von allem, was im Produkt benötigt werden könnte Product Owner Alle User Stories, Bugs, Technical-Debt-Elemente
Sprint Backlog Aus dem Product Backlog ausgewählte Elemente für den aktuellen Sprint + Plan zur Lieferung Entwicklungsteam Für Sprint 3 ausgewählte Stories + Aufschlüsselung in Aufgaben
Produktinkrement Summe aller abgeschlossenen Product-Backlog-Elemente + alle vorherigen Inkremente Entwicklungsteam Funktionierende Software mit neuen Features aus dem aktuellen Sprint

3.8 Der Sprint-Zyklus

Das folgende Diagramm zeigt, wie alle Scrum-Elemente in einem kontinuierlichen Zyklus zusammenarbeiten. Beachten Sie, wie Feedback in die Planung zurückfließt und ein selbstverbesserndes System schafft:

Sprint 1-4 Wochen
Product Backlog
Stakeholder-Feedback
📝 Sprint Planning
📑 Sprint Backlog
🔄 Daily Scrum
💻 Entwicklungs-arbeit
📦 Produkt-inkrement
🔍 Sprint Review
🪞 Retrospektive
📈 Prozess-verbesserung
Planungsphase
Ausführungsphase
Review-Phase
Verbesserungsphase

Den Zyklus im Uhrzeigersinn von oben lesen:

  1. Planungsphase (blau): Sprint Planning wählt Elemente aus dem Product Backlog aus und erstellt das Sprint Backlog
  2. Ausführungsphase (grün): Daily Scrums synchronisieren das Team während der Feature-Entwicklung
  3. Review-Phase (lila): Abgeschlossene Arbeit wird zum Produktinkrement, demonstriert im Sprint Review
  4. Verbesserungsphase (amber): Die Retrospektive identifiziert Prozessverbesserungen, die in den nächsten Sprint einfließen

Der Zyklus wiederholt sich kontinuierlich, wobei Stakeholder-Feedback in das Product Backlog für zukünftige Priorisierung zurückfließt.

3.9 Velocity: Wie Teams lernen zu schätzen

Velocity ist ein Maß dafür, wie viel Arbeit ein Team in einem einzigen Sprint abschließen kann. Sie wird typischerweise in Story Points ausgedrückt — einem abstrakten Maß für Aufwand statt Stunden.

Wie Velocity funktioniert:

  1. Erster Sprint: Das Team schätzt Stories und wählt aus, was erreichbar erscheint
  2. Nach dem Sprint: Zählen der Punkte der abgeschlossenen Stories (nicht angefangen, nicht “fast fertig” — fertig)
  3. Nächster Sprint: Diese Zahl als Richtlinie verwenden, wie viel ausgewählt werden soll
  4. Im Laufe der Zeit: Velocity stabilisiert sich und macht die Planung vorhersagbarer

Beispiel für Road Profile Viewer:

Sprint Versuchte Stories Abgeschlossene Stories Velocity
1 15 Punkte 10 Punkte 10
2 12 Punkte 11 Punkte 11
3 13 Punkte 12 Punkte 12
4 12 Punkte 12 Punkte 12

Nach 4 Sprints weiß das Team, dass es zuverlässig ~12 Punkte pro Sprint abschließen kann. Das macht die Planung realistisch.

Wichtig: Velocity ist ein Planungswerkzeug, keine Leistungskennzahl. Velocities zwischen Teams zu vergleichen ist bedeutungslos — Story-Point-Skalen unterscheiden sich. Velocity zu nutzen, um Teams zu drängen, “mehr zu tun”, zerstört ihren Wert als ehrliches Planungswerkzeug.

3.10 Der unverletzliche Sprint: Warum Deadlines fest sind

Ein kritisches Scrum-Prinzip, das viele Neulinge überrascht:

Sprints werden NIE verlängert. Wenn Arbeit nicht fertig ist, kehrt sie ins Product Backlog zurück.

Das scheint hart, aber es dient wesentlichen Zwecken:

Warum feste Sprints wichtig sind:

  1. Erzwingt realistische Planung — Teams lernen, was sie tatsächlich erreichen können
  2. Schafft vorhersagbaren Rhythmus — Stakeholder wissen, wann sie Demos erwarten können
  3. Verhindert Scope Creep — Kein “nur noch ein Tag mehr”, der zur Woche wird
  4. Deckt Schätzprobleme früh auf — Anstatt sie mit Verlängerungen zu verstecken

Was passiert, wenn Arbeit nicht abgeschlossen wird:

graph LR
    US[Unfertige Story] --> PB[Zurück ins Product Backlog]
    PB --> PO[Product Owner priorisiert neu]
    PO --> NS[Kann für nächsten Sprint ausgewählt werden]
    PO --> L[Oder wird deprioritisiert]

Die Reaktion des Teams sollte sein:

NICHT: Überstunden machen, um fertig zu werden, den Sprint verlängern oder unvollständige Arbeit als “fertig” markieren.

3.11 Das Scrum Board: Arbeit sichtbar machen

Das Scrum Board (oder Sprint Board) ist eine visuelle Darstellung der Arbeit im aktuellen Sprint. Ursprünglich ein physisches Whiteboard mit Klebezetteln, ist es heute oft digital.

Typische Spalten:

Zu erledigen 3
ROAD-4 5 Pkt
Zwei Profile nebeneinander vergleichen
feature ui
ROAD-5 3 Pkt
Profil als PDF exportieren
feature
ROAD-4.1
Vergleichs-Layout entwerfen
MK
Max K.
In Arbeit 2
ROAD-3 5 Pkt
Profile via JSON hochladen
upload
LS
Lisa S.
ROAD-3.2
JSON-Validierung hinzufügen
LS
Lisa S.
Im Review 2
ROAD-2 3 Pkt
Interaktives Diagramm mit Zoom
ui
TM
Tom M.
ROAD-2.3
Touch-Gesten für Mobile hinzufügen
TM
Tom M.
Fertig 3
ROAD-1 2 Pkt
Gespeicherte Straßenprofile anzeigen
database
ROAD-1.1
Datenbankschema erstellen
ROAD-1.2
Profillisten-API erstellen

Vorteile visueller Boards:

Physische vs. digitale Boards:

Physisches Board Digitales Board (Jira, GitHub Projects)
Hochgradig sichtbar im gemeinsamen Büroraum Zugänglich für verteilte Teams
Haptisch — befriedigend, Karten zu bewegen Automatisierte Metriken und Burndown-Charts
Keine Lernkurve Integration mit CI/CD und Versionskontrolle
Erfordert gemeinsamen Standort Funktioniert über Zeitzonen hinweg

Für Ihr Road Profile Viewer-Projekt bietet GitHub Projects ein hervorragendes kostenloses digitales Board, das sich direkt mit Ihren Issues und Pull Requests integriert.

3.12 Warum Scrum funktioniert: Empirische Belege

Nach zwei Jahrzehnten Scrum-Einführung, was berichten Teams tatsächlich? Studien und Fallstudien identifizieren konsequent diese Vorteile:

1. Handhabbare Teile

“Das Produkt wird in eine Reihe von handhabbaren und verständlichen Teilen zerlegt, mit denen sich Stakeholder identifizieren können.” — Sommerville (2015)

Anstatt einer monolithischen “der Software”, die nach Monaten unsichtbarer Arbeit geliefert wird, sehen Stakeholder jeden Sprint greifbaren Fortschritt.

2. Instabile Anforderungen blockieren den Fortschritt nicht

Bei traditionellem Wasserfall bedeuteten sich ändernde Anforderungen, anzuhalten und neu zu planen. Bei Scrum ist Änderung einfach eine Neupriorisierung des Backlogs — die Entwicklung geht ohne Unterbrechung weiter.

3. Team-Sichtbarkeit und Moral

“Das gesamte Team hat Einblick in alles, und folglich werden Teamkommunikation und Moral verbessert.”

Niemand wird von “diesem Feature, an dem jemand anderes gearbeitet hat” überrascht. Das Daily Scrum und das gemeinsame Board halten alle informiert.

4. Kundenvertrauen

“Kunden sehen die pünktliche Lieferung von Inkrementen und erhalten Feedback, wie das Produkt funktioniert. Sie werden nicht mit Überraschungen in letzter Minute konfrontiert.”

Jeder Sprint liefert funktionierende Software. Probleme werden früh entdeckt, nicht bei der Endlieferung.

5. Positive Kultur

“Vertrauen zwischen Kunden und Entwicklern wird aufgebaut, und eine positive Kultur entsteht, in der jeder erwartet, dass das Projekt erfolgreich sein wird.”

3.13 Verteiltes Scrum: Arbeiten über Standorte hinweg

Scrum wurde für Teams am gleichen Standort entwickelt, die sich täglich persönlich treffen konnten. Aber moderne Softwareentwicklung umfasst oft verteilte Teams über Städte, Länder oder Kontinente hinweg.

Anpassungen für verteiltes Scrum:

Scrum-Element Ansatz am gleichen Standort Verteilte Anpassung
Daily Scrum Standup-Meeting am Team-Whiteboard Videoanruf oder asynchrone Slack-Updates
Sprint Board Physisches Whiteboard mit Klebezetteln GitHub Projects, Jira oder Linear
Pair Programming Gemeinsame Tastatur/Monitor VS Code Live Share, Bildschirmfreigabe
Sprint Planning Besprechungsraum mit Product Owner Videokonferenz mit geteiltem Bildschirm
Informelle Kommunikation Flurgespräche Slack-Kanäle, Videoanrufe

Schlüsselanforderungen für erfolgreiche verteilte Scrum-Anwendung:

  1. Scrum Master beim Team — Der SM sollte idealerweise am gleichen Ort wie die meisten Entwickler sein, um tägliche Herausforderungen zu verstehen
  2. Product-Owner-Besuche — Der PO sollte das Entwicklungsteam regelmäßig besuchen, um Beziehungen und Vertrauen aufzubauen
  3. Überlappende Stunden — Teams in verschiedenen Zeitzonen brauchen einige gemeinsame Arbeitszeiten für synchrone Kommunikation
  4. Continuous Integration — Automatisierte Builds und Tests, damit alle Teammitglieder den aktuellen Systemzustand sehen
  5. Gemeinsame Entwicklungsumgebung — Docker, Devcontainer oder standardisiertes Tooling, damit “funktioniert auf meinem Rechner” kein Problem ist

3.14 Skalierung von Scrum: Mehrere Teams

Was passiert, wenn ein Projekt zu groß für ein einzelnes Scrum-Team (7±2 Personen) ist?

Multi-Team-Scrum bringt Koordinationsherausforderungen mit sich:

Wichtige Skalierungsmuster:

1. Rollen-Replikation

Jedes Team hat seinen eigenen Product Owner und Scrum Master. Für große Produkte kann es einen Chief Product Owner geben, der teamübergreifend koordiniert.

2. Produktarchitekten

Jedes Team nominiert einen technischen Vertreter. Diese Architekten treffen sich regelmäßig, um die Gesamtsystemarchitektur zu entwerfen und weiterzuentwickeln und sicherzustellen, dass die Arbeit der Teams reibungslos integriert wird.

3. Release-Abstimmung

Alle Teams stimmen ihre Sprint-Termine ab, damit Releases koordiniert werden können. Am Ende jedes Sprints sollte ein demonstrierbares integriertes System existieren.

4. Scrum of Scrums

Ein tägliches Meeting, bei dem Vertreter jedes Teams synchronisieren:

graph TD
    T1[Team 1 Daily Scrum] --> SoS[Scrum of Scrums]
    T2[Team 2 Daily Scrum] --> SoS
    T3[Team 3 Daily Scrum] --> SoS
    SoS --> COORD[Teamübergreifende Koordination]

Skalierungsframeworks:

Für große Unternehmen existieren formale Skalierungsframeworks:

Für Ihr Road Profile Viewer-Projekt mit 3 Personen werden Sie diese nicht brauchen — aber in der Industrie werden Sie wahrscheinlich darauf stoßen.

4. Beispiel-Sprint für Road Profile Viewer

Sehen wir, wie ein Team einen Sprint für das Road Profile Viewer-Projekt durchführen könnte.

4.1 Sprint-Ziel

Sprint-Ziel: Benutzer befähigen, Straßenprofile auszuwählen und hochzuladen mit Datenbankpersistenz.

4.2 Sprint Backlog

Story Aufgaben Status
Datenbank-Setup
  • SQLite-Schema entwerfen
  • Datenbankmodul implementieren
  • Seed-Skript erstellen
  • Unit-Tests schreiben
 Fertig
Datenvalidierung
  • Pydantic-Modell definieren
  • Validierungsregeln hinzufügen
  • Unit-Tests schreiben
 Fertig
Profilauswahl
  • Dropdown-Komponente hinzufügen
  • Mit Datenbankabfragen verbinden
  • Diagramm bei Auswahl aktualisieren
  • Integrationstests schreiben
 In Arbeit
Profil-Upload
  • /upload-Route erstellen
  • Upload-Formular bauen
  • Vorschau-Graph implementieren
  • Mit Validierung & Datenbank verbinden
  • Integrationstests schreiben
 Zu erledigen

4.3 Zwei-Wochen-Sprint-Zeitplan

Woche 1:

Woche 2:

4.4 Sprint-Board-Visualisierung

Zu erledigen
3 Elemente
→
In Arbeit
2 Elemente
→
Im Review
2 Elemente
→
Fertig
3 Elemente
↩ Nacharbeit: Review → In Arbeit

Moderne Tools wie Jira, Linear oder GitHub Projects bieten digitale Sprint-Boards. Für das Road Profile Viewer-Projekt würde sich GitHub Projects gut mit Ihrem bestehenden Repository integrieren.

5. Reale Belege: US-Militär-Agile-Einführung

Ein häufiger Einwand gegen Agile ist: “Das mag für Web-Apps funktionieren, aber nicht für ernsthafte Projekte.” Die jüngste Hinwendung des US-Militärs zu Agile widerspricht diesem Argument direkt.

5.1 Warum Militärsoftware der ultimative Stresstest ist

Bevor wir die Agile-Einführung des Militärs untersuchen, lassen Sie uns verstehen, warum dies bedeutsam ist. Militärische Softwaresysteme stellen vielleicht die herausforderndste Umgebung für jede Entwicklungsmethodologie dar. Sommerville (2015) identifiziert sechs Faktoren, die große Systeme schwierig machen — Militärsoftware hat alle davon:

Herausforderungsfaktor Beschreibung Militärisches Beispiel
System of Systems Mehrere separate Systeme, die kommunizieren und integrieren müssen Flugzeuge, Bodenfahrzeuge, Kommandozentralen, Satelliten — alle müssen Daten teilen
Brownfield-Entwicklung Neue Software muss sich mit bestehenden Legacy-Systemen integrieren Jahrzehntealte Radarsysteme, Kommunikationsprotokolle, Datenbankformate
Regulatorische Auflagen Externe Regeln für Entwicklung, Tests und Dokumentation Sicherheitsfreigaben, Sicherheitszertifizierungen, Beschaffungsvorschriften
Langwierige Beschaffung Lange Zeiträume von der ersten Spezifikation bis zur Bereitstellung Große Waffensysteme können 10+ Jahre vom Konzept bis zur Feldeinführung benötigen
Diverse Stakeholder Viele verschiedene Benutzer und Entscheidungsträger mit konkurrierenden Prioritäten Soldaten, Kommandeure, Auftragnehmer, Kongress, verbündete Nationen
Lebenskritische Systeme Softwarefehler können zu Verlust von Menschenleben führen Waffenzielerfassung, Fahrzeugsteuerung, medizinische Systeme

Das traditionelle Argument: Diese Herausforderungen erfordern umfangreiche Vorausplanung, detaillierte Spezifikationen und rigorose Phase-Gate-Prozesse. Agiles Flexibilität würde inakzeptable Risiken einführen.

Die aufkommende Realität: Diese Herausforderungen machen Agile tatsächlich wertvoller, nicht weniger. Wenn sich Anforderungen unweigerlich ändern (wie es in sich entwickelnden Bedrohungsumgebungen der Fall ist), wird die Fähigkeit zur schnellen Anpassung zu einem strategischen Vorteil.

5.2 US-Armee-Richtlinie (März 2024)

Im März 2024 kündigte die US-Armee eine weitreichende neue Richtlinie an, die agile Softwareentwicklungspraktiken in der gesamten Organisation vorschreibt.

Armeeministerin Christine Wormuth:

“Wir lernen aus aktuellen Konflikten — einschließlich in der Ukraine — dass der Erfolg der Armee auf zukünftigen Schlachtfeldern von unserer Fähigkeit abhängen wird, Software schnell zu aktualisieren und an die Einsatztruppe zu verteilen.”

Die Richtlinie institutionalisiert fünf große Änderungen:

Traditioneller Armee-Ansatz Neuer agiler Ansatz
Detaillierte, präskriptive Anforderungsdokumente Prägnante, hochrangige Bedarfe mit kontinuierlicher Soldatenbeteiligung
Starre Beschaffungsstrategien Software Acquisition Pathway mit modularer Auftragsvergabe
Doppelte Testphasen Optimiertes, kontinuierliches Testen integriert mit Entwicklung
Entwicklung endet bei Bereitstellung Kontinuierliche Verbesserung über den gesamten Lebenszyklus
Verstreute Expertise Digital Capabilities Contracting Center of Excellence

5.3 Platform One DevSecOps

Die Platform One der US Air Force bietet eine cloud-native DevSecOps-Plattform für Militärsoftware. Sie stellt einen grundlegenden Wandel dar, wie das Militär an Softwareinfrastruktur herangeht.

Was Platform One bietet:

Warum das revolutionär ist:

Traditionelle militärische Softwarebeschaffung könnte so aussehen:

  1. Detaillierte Anforderungen schreiben (6-12 Monate)
  2. Auftragnehmer auswählen (6-12 Monate)
  3. Entwicklung (2-5 Jahre)
  4. Sicherheitszertifizierung (6-18 Monate)
  5. Bereitstellung

Mit Platform One und agilen Praktiken:

  1. Kontinuierliche Zusammenarbeit mit Benutzern
  2. Sprint-basierte Entwicklung mit häufigen Releases
  3. Automatisierte Sicherheitstests bei jedem Commit
  4. Kontinuierliches Deployment auf vorzertifizierter Infrastruktur

Das Ergebnis: Software, deren Bereitstellung Jahre gedauert hätte, erreicht jetzt Soldaten in Monaten oder Wochen.

5.4 Der Ukraine-Faktor: Agile unter Feuer

Die russische Invasion der Ukraine 2022 hat einen beispiellosen realen Test für Software-Agilität in der Kriegsführung geliefert. Ukrainische Streitkräfte haben demonstriert:

Das Zitat von Ministerin Wormuth bezieht sich direkt auf diese Lektionen:

“Wir lernen aus aktuellen Konflikten — einschließlich in der Ukraine — dass der Erfolg der Armee auf zukünftigen Schlachtfeldern von unserer Fähigkeit abhängen wird, Software schnell zu aktualisieren und an die Einsatztruppe zu verteilen.”

Das ist keine abstrakte Theorie — es ist die beobachtete Realität moderner Kriegsführung, wo Software-Updates so wichtig sein können wie Munitionsnachschub.

5.5 Implikationen für das Software Engineering

Wenn das US-Militär — eine der am stärksten regulierten, lebenskritischen und sicherheitsbewusstesten Organisationen der Erde — agile Praktiken einführt, was bedeutet das für die Softwarebranche?

1. Der Mythos “Agile skaliert nicht” ist tot

Militärische Systeme gehören zu den größten, komplexesten Softwareprojekten der Erde. Wenn Agile dort funktioniert, gilt das Argument “es funktioniert nur für kleine Web-Apps” nicht mehr.

2. Sicherheit und Agile sind kompatibel

DevSecOps beweist, dass rigorose Sicherheit kein Wasserfall erfordert. Automatisierte Tests, kontinuierliche Compliance-Überwachung und Security-by-Design können mit schneller Iteration koexistieren.

3. Regulierte Branchen werden folgen

Gesundheitswesen, Finanzen, Luft- und Raumfahrt, Automobilindustrie — diese Branchen stehen vor ähnlichem Druck (wenn auch weniger extrem). Die erfolgreiche Einführung durch das Militär schafft eine Vorlage für andere regulierte Domänen.

4. Die eigentliche Frage hat sich geändert

Es geht nicht mehr um “Sollten wir Agile nutzen?”, sondern “Wie passen wir Agile an unsere spezifischen Einschränkungen an und behalten dabei seine Kernvorteile bei?”

Die Lektion für Ihre Karriere: Agile ist nicht nur für Startups, die mobile Apps bauen. Es ist für jede Organisation, die:

Wenn Sie sich bei traditionellen Unternehmen bewerben und diese sagen “wir machen Wasserfall, weil unsere Domäne es erfordert”, können Sie jetzt das US-Militär als Gegenbeispiel anführen.

6. Zusammenfassung

Konzept Kernpunkt Verbindung zu Testing
Scrum-Rollen Product Owner (was), Entwicklungsteam (wie), Scrum Master (Prozess) Team entscheidet über Teststrategie; SM beseitigt Test-Hindernisse
Scrum-Ereignisse Sprint, Planning, Daily, Review, Retrospektive Review demonstriert getestete Features; Retro verbessert Testpraktiken
Scrum-Artefakte Product Backlog, Sprint Backlog, Inkrement Inkrement muss "potenziell releasefähig" sein — erfordert getesteten Code
Sprint Planning Stories auswählen, Ziel definieren, in Aufgaben zerlegen Aufgaben beinhalten "Tests schreiben" für jedes Feature
Militär-Einführung Selbst hochregulierte Umgebungen (US-Armee) schreiben agile Praktiken vor DevSecOps integriert Sicherheitstests in CI/CD-Pipeline

6.1 Zentrale Erkenntnisse

  1. Scrum bietet Struktur ohne agile Flexibilität zu opfern — Rollen, Ereignisse und Artefakte schaffen Vorhersagbarkeit.
  2. Sprints schaffen Rhythmus — zeitlich begrenzte Iterationen mit klaren Zielen und Verantwortlichkeit.
  3. Der Product Owner besitzt “was”, das Entwicklungsteam besitzt “wie” — klare Trennung der Zuständigkeiten.
  4. Retrospektiven treiben Verbesserung voran — das Team verfeinert kontinuierlich seinen Prozess.
  5. Reale Belege validieren Agile — selbst das US-Militär führt diese Praktiken für missionskritische Systeme ein.

7. Reflexionsfragen

  1. Rollenzuordnung: Wer würde in Ihrem Road Profile Viewer-Team als Product Owner dienen? Scrum Master? Wie würden Sie diese Rollen mit nur 3 Teammitgliedern handhaben?

  2. Sprint-Größe: Ihr Road Profile Viewer-Team hat 3 Mitglieder und 3 Wochen. Entwerfen Sie einen realistischen Sprint-Zeitplan. Wie lang wären Ihre Sprints? Welche Ereignisse würden Sie beibehalten oder modifizieren?

  3. Backlog-Priorisierung: Gegeben die 5 User Stories aus Teil 1, in welcher Reihenfolge würden Sie sie angehen? Welche Abhängigkeiten beeinflussen Ihre Reihenfolge?

  4. Daily-Scrum-Wert: Manche Teams finden das Daily Scrum repetitiv. Welchen Wert bietet es? Wann könnte ein Team es auslassen?

  5. Militär-Fallstudie: Was hat Sie an der Agile-Einführung der US-Armee überrascht? Wie verändert dies Ihre Wahrnehmung der Anwendbarkeit von Agile auf verschiedene Domänen?

  6. Prozessanpassung: Der Scrum Guide sagt “Scrum ist ein Framework, keine Methodologie.” Was bedeutet das dafür, wie Sie Scrum für ein 3-Personen-Studententeam anpassen könnten?

8. Weiterführende Literatur

8.1 Bücher

8.2 Artikel und Ressourcen

8.3 Tools

9. Wie geht es weiter

Mit den agilen Grundlagen (Teil 1) und dem Scrum-Framework (Teil 2) abgeschlossen, haben Sie jetzt die Werkzeuge, um:

In Ihrem Road Profile Viewer-Projekt wenden Sie diese Konzepte an:

  1. Erstellen Sie ein Product Backlog als GitHub Issues
  2. Planen Sie einen Sprint mit einem klaren Ziel
  3. Nutzen Sie Daily Standups (auch asynchron auf Slack/Discord), um synchron zu bleiben
  4. Halten Sie ein Sprint Review ab, um Ihren Fortschritt zu demonstrieren
  5. Führen Sie eine Retrospektive durch, um Verbesserungen zu identifizieren

Der beste Weg, Agile zu lernen, ist es zu praktizieren.

© 2026 Dominik Mueller   •  Powered by Soopr   •  Theme  Moonwalk