Agilität steht für Offenheit, Innovation, Flexibilität und wohl auch Vielfalt. Trotzdem höre ich in der Praxis als Konkretisierung von agilem Projektmanagement so gut wie immer nur ein Modell: Scrum. Kürzlich las ich in einem Angebot auch die Formulierung: „Unser Vorgehen beruht auf dem Industriestandard Scrum“. Also so etwas wie „Stand der Technik“. Ist also Scrum de facto alternativlos, das letztlich einzige praxistaugliche Modell, um agile Softwareentwicklung zu betreiben? Wäre ja schön, wenn wir uns alle einig wären und nur noch eine Methodik lernen müssten.
„Nie wieder denken!“ so hat vor einigen Jahren ein Methodenberater sein Framework angepriesen. Allerdings hat er uns in dem Projekt, wo er als Berater engagiert worden war, gut 9 Monate gekostet, bis es mir mit einigen Mitstreitern gelungen ist, die Projektarbeit auf eine vernunftbasierte und ergebnisorientierte Arbeitsweise umzustellen. Ich bin seither allergisch gegenüber umfassenden Geltungsansprüchen, oder salopp gesprochen auf Leute, die meinen, die Wahrheit gepachtet zu haben.
Wenn aber Scrum so erfolgreich ist, dann hat das sicher einen Grund. Ein entscheidender Grund ist meiner Überzeugung nach, dass Scrum einfach und klar ist. Eine hervorragende Darstellung geben die 24. Ich muss hier nicht auf die Details eingehen, die meisten Leser meines Newsletters wissen ohnehin sehr genau, wie Scrum definiert ist.
Scrum kompakt dargestellt (Quelle: Agile Fanatics)
Im Scrum-Guide schreiben die „Erfinder“ von Scrum, Ken Schwaber und Jeff Sutherland dazu: „Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.“ Und weiter: „Scrum ist einfach. Probiere es so aus, wie es ist, und finde heraus, ob seine Philosophie, Theorie und Struktur dabei helfen, Ziele zu erreichen und Wert zu schaffen. Das Scrum-Rahmenwerk ist absichtlich unvollständig und definiert nur die Teile, die zur Umsetzung der Scrum-Theorie erforderlich sind. Scrum baut auf der kollektiven Intelligenz der Personen auf, die es anwenden. Anstatt den Menschen detaillierte Anweisungen zu geben, leiten die Regeln von Scrum ihre Beziehungen und Interaktionen.“
Wenn in der Praxis Scrum von manchen agilen Coaches verabsolutiert wird, liegt das nicht an den Autoren des Scrum-Guides, den diese als bewusst unvollständig und als nicht immer passend charakterisieren.
Ich bin „Disciplined Agile Senior Scrum Master“, stehe daher hoffentlich nicht im Verdacht, Scrum nicht zu verstehen oder pauschal abzulehnen. Ich habe auch in der Praxis schon mit Scrum-Teams (erfolgreich) gearbeitet. Aus diesen Erfahrungen heraus muss ich allerdings einige kritische Hinweise zur Scrum-Praxis geben.
Wo ist Scrum unvollständig?
a. Scrum ist keine Projektmanagement-Methodik.
Das Wort „Projekt“ kommt im Guide nur einmal vor: „Jeder Sprint kann als ein kurzes Projekt betrachtet werden.“ Das kann man so sehen. Allerdings ist jeder Sprint selbst Teil eines Projektes und es gibt in jedem Projekt zahlreiche Elemente, die nicht sinnvoll gemäß Scrum abgewickelt werden. So z.B. Beschaffungsprozesse für Standardsoftware und Hardware, Steuerung und Integration von Entwicklungsarbeiten, die nicht vom Scrum-Team durchgeführt werden etc. Wie vielfältig Projektmanagement ist, zeigt allein die Tatsache, dass PMI den Aufgabenbereich des Projektmanagements durch 49 Prozesse innerhalb der folgenden fünf Prozessgruppen beschreibt:
1. Initiierung
2. Planung
3. Ausführung
4. Überwachung und Steuerung
5. Abschluss oder Umsetzung.
Scrum adressiert die Prozessgruppen 3 und 4 und gibt dafür sehr konkrete und in vielen Fällen sinnvolle Vorgaben. Aber es bleibt viel offen. Der Scrum-Guide betont zwar: „Das Scrum-Rahmenwerk ist absichtlich unvollständig und definiert nur die Teile, die zur Umsetzung der Scrum-Theorie erforderlich sind.“ An anderer Stelle steht allerdings (Hervorhebung von mir): „Innerhalb des Rahmenwerks können verschiedene Prozesse, Techniken und Methoden eingesetzt werden. Scrum umhüllt bestehende Praktiken oder macht sie überflüssig.“ Es sollte klargestellt werden, dass Scrum bestehende Praktiken außerhalb des Scrum-Rahmenwerkes nicht überflüssig macht, im Gegenteil, diese sogar zwingend voraussetzt. Dazu gehört alles, was ein Projekt außerhalb der Entwicklung im engeren Sinne beinhalten muss, um erfolgreich zu sein.
b. Scrum setzt Architekturentscheidungen stillschweigend voraus
Die Entscheidung für eine bestimmte technische Plattform, für oder gegen eine Standardsoftware, die Art der Integration einer neuen Anwendung in die Applikationslandschaft, die Nutzung oder Nicht-Nutzung einer Business Rule Engine etc. sind Weichenstellungen, die enorme Auswirkungen auf den Erfolg eines IT-Projektes haben. Diese Weichenstellungen erfolgen typischerweise vor dem Start der iterativen Entwicklung gemäß dem Scrum-Paradigma. Da Scrum ein Prozessmodell ist, das sich gegenüber Inhalten völlig agnostisch verhält, ist dieser blinde Fleck kein Bug, sondern ein Feature.
c. Scrum wälzt zu viel Verantwortung auf den/die Product Owner:in ab
Die Reihenfolge der Umsetzung von Anforderungen hängt wesentlich auch von der Architektur der technischen Lösung ab. Wenn also ein Product-Owner „die Reihenfolge der Product-Backlog-Einträge festzulegen“ hat und insgesamt „ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt“ist, so blendet das völlig aus, dass solche Entscheidungen eine Abstimmung zwischen Business und IT erfordern. Implementierungsschritte bauen aufeinander auf. So muss z.B. eine Basiskomponente gebaut werden, mit der dann Konfigurationen möglich sind. Würde der Product Owner darauf bestehen, dass gewisse Funktionen vorher implementiert werden, könnte das nur durch hartes Codieren erfolgen und dieses Provisorium müsste dann wieder ausgebaut werden, wenn die Konfigurationsmöglichkeit bereit ist. Bei einer konfigurierbaren Standardsoftware kann hingegen sofort mit der Konfiguration von Funktionen begonnen werden und die Reihenfolge kann nach fachlichen Gesichtspunkten bestimmt werden. Ich habe als Product Owner großes Erstaunen bei in der Wolle gefärbten Scrummern geerntet, wenn ich sie aufgefordert habe, mir ihre Empfehlung zur Reihenfolge der Umsetzung zu geben.
Es wird auch übersehen, dass Priorisierung ein mehrdimensionales Konzept ist, zumindest muss zwischen Wichtigkeit und Dringlichkeit unterschieden werden. Vor der Produktivsetzung können wichtige und daher unverzichtbare Features auch relativ spät implementiert werden, ohne dass die Entwicklung dadurch Schaden leidet. Das gilt etwa für Schnittstellen oder auch Berechnungsroutinen, die einige Zeit durch Mockups hinreichend substituiert werden können.
Wie sollten wir Scrum nutzen?
Scrum bietet eine Reihe von Methoden, die bei der Abwicklung von IT-Projekten hohen Nutzen bieten können. Allerdings muss man diese Aussage wirklich ernst nehmen: „Scrum baut auf der kollektiven Intelligenz der Personen auf, die es anwenden. Anstatt den Menschen detaillierte Anweisungen zu geben, leiten die Regeln von Scrum ihre Beziehungen und Interaktionen“. Um zum Methodenberater vom Anfang zurückzukehren, gilt: Denken! Immer!
Scrum ist nicht immer das ideale Vorgehensmodell. Lean oder XP sind Alternativen, die man nicht außer Acht lassen darf. Natürlich kann man auch Elemente wie Pair Programming oder Test Driven Development innerhalb eines Scrum-Projektes nutzen. Ich sehe auch regelmäßig, dass Scrum-Teams ein Kanban-Board nutzen, obwohl sie nicht insgesamt einem Lean-Ansatz folgen.
Methodischer Eklektizismus ist kein Verrat an den Prinzipien agiler Softwareentwicklung, sondern meiner Meinung nach Best Practice. Es muss „nur“ funktionieren. Wenn allerdings etwas in einem Projekt nicht funktioniert, dann muss man das Vorgehen ändern und sich nicht krampfhaft an den Standard klammern.