Agiles Arbeiten

Kurzfassung

Agiles Arbeiten heißt, ein Vorhaben in kurzen Zyklen voranzubringen, in denen ein Team jeweils ein nutzbares Teilergebnis erzeugt, es mit Nutzern prüft und Plan und Vorgehen danach anpasst. Die bekanntesten Formen sind Scrum, Kanban und Extreme Programming. Gemeinsamer Bezugspunkt ist das Agile Manifest von 2001.

Der Ansatz passt dort, wo Anforderungen unsicher sind und sich Teilergebnisse früh nutzen lassen, also vor allem in der Softwareentwicklung. Belegt ist ein positiver Zusammenhang zwischen agilen Methoden und Projekterfolg, meist aus Befragungen. Dass agiles Arbeiten die Ursache des Erfolgs ist, zeigen diese Studien nicht.

Umstritten sind vor allem zwei Fragen: ob sich agiles Arbeiten mit Rahmenwerken wie SAFe auf ganze Organisationen ausweiten lässt und wie weit es sich über Software hinaus übertragen lässt. Die Kritik kommt auch aus der agilen Bewegung selbst.

Was agiles Arbeiten ist und welche Formen es gibt

Allen agilen Ansätzen gemeinsam sind drei Merkmale:

• Iterativ: Die Arbeit läuft in wiederkehrenden Zyklen, in denen geplant, umgesetzt und geprüft wird.
• Inkrementell: Jeder Zyklus liefert ein Stück, das sich nutzen oder zumindest vorführen lässt, statt eines Zwischendokuments.
• Empirisch: Entscheidungen beruhen auf dem, was die Prüfung des letzten Stücks ergeben hat, nicht auf einem Plan, der zu Beginn festgelegt wurde.

Die Methoden setzen diese Merkmale unterschiedlich um.

Scrum regelt die Zusammenarbeit, sagt aber nichts über technische Praktiken. Extreme Programming ist umgekehrt vor allem ein Bündel solcher Praktiken. In vielen Teams werden beide kombiniert. Kanban beginnt bei dem, was ein Team ohnehin tut, und verändert es schrittweise. In Organisationen ist zudem häufig eine Mischform zu sehen: agile Teams innerhalb eines klassisch gesteuerten Projekts nach PRINCE2 oder Kanban im Servicebetrieb nach ITIL 4.

Skalierung. Sobald viele Teams an einem Produkt arbeiten, stellt sich die Frage der Abstimmung. Dafür gibt es eigene Rahmenwerke. Das Scaled Agile Framework (SAFe) von Dean Leffingwell legt mehrere Ebenen mit eigenen Rollen und Planungsterminen fest. Large-Scale Scrum (LeSS) von Craig Larman und Bas Vodde versucht, mit möglichst wenig zusätzlicher Struktur auszukommen. Die beiden stehen für zwei Antworten auf dieselbe Frage: mehr Koordinationsregeln oder weniger Abhängigkeiten zwischen den Teams.

Nutzen und Beleglage

Die Belege lassen sich nach ihrer Stärke ordnen. Kontrollierte Vergleiche ganzer Vorgehensweisen gibt es kaum, weil sich Projekte nicht zufällig einer Methode zuteilen lassen.

Befragungen mit Vergleich. Pedro Serrador und Jeffrey Pinto werteten 2015 Angaben zu mehr als 1.000 Projekten aus verschiedenen Branchen und Ländern aus. Projekte, die stärker agil arbeiteten, erreichten nach Angaben der Befragten häufiger ihre Ziele, besonders die Zufriedenheit von Kunden und Auftraggebern. Das ist ein Zusammenhang, kein Wirkungsnachweis. Die Daten beruhen auf Selbstauskünften von Projektbeteiligten, die je ein erfolgreicheres und ein weniger erfolgreiches Projekt beschrieben. Ein bemerkenswertes Nebenergebnis: Agile Projekte planten vorab nicht weniger als andere, sie planten aber während des Projekts weiter.

Literaturübersichten zur Skalierung. Kim Dikert, Maria Paasivaara und Casper Lassenius von der Aalto-Universität sichteten 2016 die Literatur zu großen agilen Umstellungen. Von 52 einbezogenen Veröffentlichungen über 42 Fälle waren rund 90 Prozent Erfahrungsberichte. Am häufigsten genannte Erfolgsbedingungen waren Unterstützung durch die Leitung, die Auswahl und Anpassung des Modells, Schulung und Begleitung sowie ein gemeinsames Verständnis des Vorhabens. Über die Wirkung großer Umstellungen ist damit wenig gesichert.

Herstellerbefragungen. Der jährlich erscheinende State of Agile Report, heute vom Softwareanbieter Digital.ai herausgegeben, wird oft als Beleg zitiert. Er ist eine Umfrage unter Interessierten ohne Zufallsstichprobe und ohne Vergleichsgruppe. Er zeigt, was Befragte berichten, nicht, was agiles Arbeiten bewirkt.

Fallberichte jenseits von Software. Darrell Rigby von der Beratung Bain, Jeff Sutherland und Hirotaka Takeuchi beschrieben 2016 in der Harvard Business Review den Einsatz agiler Methoden etwa bei National Public Radio für neue Sendungen, bei John Deere für neue Maschinen und bei Saab für Kampfflugzeuge. Solche Berichte zeigen, dass die Übertragung möglich ist, aber nicht, unter welchen Bedingungen sie sich lohnt.

Worauf agiles Arbeiten beruht

Der Ansatz setzt mehrere Bedingungen voraus. Fehlt eine davon, verliert er einen Teil seines Nutzens.

1. Unsicherheit über das Ziel. Agiles Arbeiten ersetzt Vorabplanung durch Lernen aus Rückmeldung. Das lohnt sich, wo sich vorher nicht klären lässt, was gebraucht wird. Im Cynefin-Modell sind das komplexe Lagen.
2. Teilergebnisse lassen sich früh prüfen. Ein Zyklus bringt nur dann Erkenntnis, wenn sein Ergebnis von Nutzern beurteilt werden kann.
3. Das Team darf entscheiden. Ein Product Owner ohne Einfluss auf Prioritäten oder ein Team, das Aufgaben nur zugeteilt bekommt, kann aus Rückmeldung nichts machen.
4. Das Umfeld passt. Jahresbudgets mit festem Umfang, Einzelzielvereinbarungen und lange Freigabewege arbeiten gegen kurze Zyklen.
5. Offenheit ist möglich. Retrospektiven und Reviews nützen nur, wenn Probleme ausgesprochen werden können (siehe psychologische Sicherheit).

Das Feld unten rechts ist der typische Ort für Kanban: Die Arbeit ist bekannt, aber sie trifft laufend ein und lässt sich in kleinen Stücken erledigen.

Herkunft, Schulen und Streitfragen

Agiles Arbeiten hat mehrere Wurzeln. Iterative Softwareentwicklung ist nach Craig Larman und Victor Basili seit den 1950er-Jahren belegt. Hirotaka Takeuchi und Ikujiro Nonaka beschrieben 1986 Produktentwicklung in mehreren Unternehmen als überlappendes Zusammenspiel eines Teams und prägten dafür das Bild des Rugby-Gedränges, aus dem der Name Scrum stammt. Kanban geht auf das Produktionssystem von Toyota zurück. In den 1990er-Jahren entstanden Scrum, Extreme Programming und weitere „leichtgewichtige“ Methoden, deren Vertreter 2001 das Agile Manifest verfassten.

Aus dieser Geschichte ergeben sich drei Streitfragen.

Methode oder Haltung? Eine Seite sieht agiles Arbeiten als Haltung, die sich in vielen Formen zeigen kann. Die andere misst es an überprüfbaren Praktiken. Dave Thomas, Mitautor des Manifests, hielt das Wort „agil“ 2014 für so vereinnahmt, dass es nichts mehr bedeute, und schlug vor, nur noch von agility als Eigenschaft der Arbeit zu sprechen.

Wie skaliert man? SAFe ist weit verbreitet und zugleich umstritten. Ken Schwaber, Mitbegründer von Scrum, verglich es 2013 mit dem älteren Rational Unified Process und hielt es für komplizierter als nötig. David Anderson, Begründer der Kanban-Methode, wandte ein, aus der Bewährung einzelner Praktiken folge nicht, dass das Ganze funktioniere, und SAFe werde in einem großen Schritt eingeführt statt schrittweise. Unabhängige Vergleichsstudien zwischen den Rahmenwerken fehlen.

Agile Teams oder agile Organisation? Ein Team kann agil arbeiten, während Budgetierung, Personalführung und Strategie unverändert bleiben. Ob die ganze Organisation sich ändern muss, wird unterschiedlich beantwortet. John Kotter schlägt ein duales Betriebssystem vor, in dem ein Netzwerk neben der Hierarchie arbeitet. Die Forschung zur lernenden Organisation fragt grundsätzlicher, wie eine Organisation aus Erfahrung lernt. Für die Einführung selbst gelten die Fragen des Change Managements.

Grenzen und Kritik

• Rituale ohne Entscheidungsspielraum. Wo Sprints, Daily Scrums und Boards eingeführt werden, ohne dass das Team über Prioritäten mitentscheidet, bleibt die Form ohne Inhalt. Ron Jeffries, Mitbegründer von Extreme Programming, riet Entwicklern 2018 deshalb, sich von solchem „Faux Agile“ abzuwenden.
• Verordnung von oben. Große Umstellungen werden oft als Programm verordnet. Das widerspricht dem Gedanken, dass Teams ihr Vorgehen selbst anpassen.
• Schwache Belege. Die meisten Aussagen zur Wirkung beruhen auf Befragungen, Erfahrungsberichten und Herstellerumfragen. Ein Zusammenhang zwischen agilen Methoden und Erfolg ist gut beschrieben, die Ursache nicht.
• Unpassende Lagen. Wo Ziele bekannt sind oder Teilergebnisse nicht geprüft werden können, kostet die ständige Abstimmung Zeit, ohne dass Lernen entsteht.
• Tempo als Missverständnis. Agiles Arbeiten wird oft mit schnellerem Arbeiten gleichgesetzt. Das Manifest betont dagegen ein Tempo, das sich dauerhaft halten lässt. Wird Agilität eingeführt, um mit weniger Menschen mehr zu leisten, widerspricht das diesem Prinzip.

Agiles Arbeiten ist damit ein Vorgehen für eine bestimmte Lage: unsichere Ziele, früh prüfbare Teilergebnisse und Teams, die entscheiden dürfen. Wie weit es darüber hinaus nützt, ist offen.

Quellen

• Schwaber, K. & Sutherland, J. (2020): The Scrum Guide.
• Anderson, D. J. (2010): Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.
• Beck, K. (1999): Extreme Programming Explained: Embrace Change. Addison-Wesley.
• Beck, K. et al. (2001): Manifest für Agile Softwareentwicklung.
• Takeuchi, H. & Nonaka, I. (1986): The New New Product Development Game. Harvard Business Review 64(1).
• Larman, C. & Basili, V. R. (2003): Iterative and Incremental Development: A Brief History. Computer 36(6), 47–56.
• Serrador, P. & Pinto, J. K. (2015): Does Agile work? A quantitative analysis of agile project success. International Journal of Project Management 33(5), 1040–1051. Zusammenfassung der APM.
• Dikert, K., Paasivaara, M. & Lassenius, C. (2016): Challenges and success factors for large-scale agile transformations: A systematic literature review. Journal of Systems and Software 119, 87–108.
• Rigby, D. K., Sutherland, J. & Takeuchi, H. (2016): Embracing Agile. Harvard Business Review 94(5).
• InfoQ (2013): Kritik an SAFe von Ken Schwaber, David Anderson und anderen.
• Larman, C. & Vodde, B. (2016): Large-Scale Scrum: More with LeSS. Addison-Wesley.
• Thomas, D. (2014): Agile is Dead (Long Live Agility).
• Jeffries, R. (2018): Developers Should Abandon Agile. Zusammenfassung bei InfoQ.
• Digital.ai: State of Agile Report (jährliche Umfrage).