6. Agiles Arbeiten

Von Robert C. Martin stammt eine minimale Umschreibung, die ich sehr treffend finde:

• Small Problems
• Small Teams
• Small Things

Kleine Probleme, kleine Teams, kleine Schritte. Dafür müssen Anforderungen in kleine Aufgaben zerlegbar sein.

2001 haben unter anderem Robert C. Martin, Kent Beck, Ward Cunningham, Jeff Sutherland und Martin Fowler das Agile Manifest formuliert.

Vier Wertpaare (jeweils gilt beides, der linke Teil mehr):

• Individuen und Interaktionen vor Prozessen und Werkzeugen (Individuals and interactions over processes and tools)
• Funktionierende Software vor umfassender Dokumentation (Working software over comprehensive documentation)
• Zusammenarbeit mit dem Kunden vor Vertragsverhandlung (Customer collaboration over contract negotiation)
• Reagieren auf Veränderung vor dem Befolgen eines Plans (Responding to change over following a plan)

Zwölf Prinzipien in Kurzform:

• Frühe und fortlaufende Lieferung wertvoller Software
• Anforderungsänderungen auch spät willkommen heißen
• Häufig liefern (Wochen statt Monate)
• Tägliche Zusammenarbeit von Fachseite und Entwicklung
• Motivierte Menschen, denen man vertraut
• Persönliches Gespräch als wirksamste Kommunikation
• Funktionierende Software als Fortschrittsmaß
• Nachhaltiges Tempo
• Technische Exzellenz und gutes Design
• Einfachheit: so viel Arbeit wie möglich nicht tun
• Gute Architektur entsteht in selbstorganisierten Teams
• Das Team reflektiert regelmäßig und passt sich an

Es gibt mehrere Rahmen: Kanban, Scrum, auf Organisationsebene etwa SAFe. Sie teilen die Idee wiederholter Iterationen, unterscheiden sich aber in Rollen, Cadence und Skalierung. SAFe ist nicht einfach „Scrum für Großunternehmen“, sondern ein eigenes Modell.

Eine Iteration umfasst typischerweise:

• Vision: gemeinsames Zielverständnis
• Ideenverwaltung: ein Product-Verantwortlicher pflegt und bewertet ein Backlog
• Planung: ausgewählte Ideen werden in Aufgaben zerlegt
• Umsetzung: festes Zeitfenster für diese Aufgaben
• Review: fertige Ergebnisse zeigen und – soweit möglich – in Nutzung geben
• Retrospektive: getrennt davon den Arbeitsprozess der Iteration verbessern

Review betrifft das Produkt, die Retrospektive den Ablauf. Beides nicht in einem Termin vermischen.

Scrum als konkretes Verfahren steht unter 6.1. Scrum.