Wir machen Scrum - wir sind agil
Manchmal haben Scrum und Agilität nur wenig miteinander zu tun. Oft genug sehen wir im Alltag starre Scrum-Implementationen. Der Versuch wirklich agil zu werden, scheitert an dem bisher Gelernten und dem, was vermeintlich richtig erscheint. Organisationen leben in eigenen Paradigmen, Kulturen und Strukturen. Sie haben über Jahre (oder Jahrzehnte) Vorgehensweisen entwickelt, die nun nur schwer aufzulösen sind. Dabei geht es weniger um die tatsächlichen Prozesse, sondern viel mehr um die Grundhaltung und die eigenen Überzeugungen.
Scrum und das agile Manifest
Scrum als Methoden-Framework ist ein Versuch, das agile Manifest und die zwölf agilen Prinzipien in die Realität zu holen. Es ist eine Vorgehensweise, die inhaltlich auf dem agilen Manifest fußt. Die Schwierigkeit daran ist, dass es auch ohne eine Auseinandersetzung mit den agilen Prinzipien möglich ist, Scrum anzuwenden. Dann ist zwar eine vermeintlich agile Vorgehensweise implementiert, diese hat aber mit Agilität wenig zu tun, weil weiterhin nach starren Vorgaben und bisher gelebten Paradigmen und Prinzipien gearbeitet wird. In der Folge verändert sich viel auf der Methodenebene, aber wenig an der tatsächlichen Haltung der Beteiligten. Der gewünschte Erfolg bleibt aus. Die agile Transformation ist gescheitert — unabhängig davon, ob dies nun so bewertet wird oder nicht.
Individuen und Interaktionen über Prozesse und Werkzeuge
Das agile Manifest betont die Bedeutung von Menschen und ihrer Zusammenarbeit. Prozesse und Werkzeuge sind wichtig, in der täglichen Arbeit sollten diese aber nicht Mittelpunkt stehen. Agilität setzt darauf, dass die besten Lösungen durch direkte Kommunikation und Kooperation entstehen.
In der Praxis bedeutet das, dass wir uns auf die Beziehungen innerhalb und außerhalb von Teams konzentrieren müssen. Offene Kommunikation, psychologische Sicherheit und interne wie externe Feedbackschleifen sind elementar. Vertrauen fördern, (kommunikative) Fähigkeiten entwickeln und Konflikte bearbeiten stehen entscheidend im Fokus.
Scrum als Framework versucht diese Punkte an unterschiedlichen Stellen zu lösen: Sei es die regelmäßige Retrospektive mit Vegas-Regel und oberster Direktive, das Daily Scrum zum täglichen Austausch oder auch das Review mit Stakeholder-Beteiligung. Die Meetings allein reichen jedoch nicht aus, um für Vertrauen, Fähigkeiten und aufrichtige Kommunikation zu sorgen. Sie sind Hilfsmittel, deren Wirkung ohne entsprechenden Fokus komplett verpufft.
Ohne diesen Fokus entstehen lediglich neue Prozesse und Werkzeuge, die als gegeben hingenommen werden. Die “so gehören”, weil es so im Buch steht. Eine echte Auseinandersetzung mit Missverständnissen, Bedürfnissen und der tieferen Ebene findet nicht statt. Die neuen Prozesse und Vorgehensweisen werden stoisch abgearbeitet und erfüllt. Die Sinnhaftigkeit und Wirksamkeit einzelner Punkte werden nicht in Frage gestellt. Auf der kommunikativen Ebene bleibt alles wie immer.
Funktionierende Software über umfassende Dokumentation
Wir alle wissen, dass ein Großteil der agilen Vorgehensweisen und auch das agile Manifest selbst ihren Ursprung in der Softwareentwicklung haben. Das die Dokumentation betreffende Prinzip lässt sich sehr gut und schnell auf andere Bereiche und Branchen übertragen. Wir zum Beispiel sagen für uns: “Für die Kund*innen fertige Produkte sind mehr als umfassende Dokumentation”. Dabei geht es um die Wertigkeit der beiden Aspekte im Zusammenspiel. Für uns heißt das ganz konkret: Es ist uns wichtiger einen Workshop anzubieten, als sofort klar zu haben, wie wir die Anmeldungen und Teilnehmenden verwalten. Klar, wir müssen Anmeldungen sinnvoll dokumentieren, damit am Ende auch alle die richtigen Informationen haben. Doch diese Dokumentation hat Zeit, bis sie wirklich anfällt. Eine Excel-Tabelle mit Namen und E-Mail-Adressen können wir auch dann anlegen, wenn die erste Anmeldung erfolgt. Die Workshop-Ausschreibung beeinflusst das nicht. Unser Produkt ist vorher fertig.
Der Scrum Guide sagt auf den ersten Blick gar nicht viel zu diesem Aspekt. Das Wort “Dokumentation” ist in der deutschen Variante nicht einmal zu finden. Stattdessen finden wir Definitionen für “Increment” und “Definition of Done”: Die Definition of Done soll vor allem Transparenz schaffen, welche Arbeiten als Teil des Increments zu verstehen sind; während ein Increment immer Teil eines Produktziels ist, das verwendbar ist.
In der Realität ist es häufig so, dass sich Storys (also Inkremente) über mehrere Sprints oder Iterationen ziehen, dass sie in der Umsetzung wachsen und aufgebläht werden, weil jeder Teilaspekt berücksichtigt werden soll. Das inkrementelle Vorgehen wird wenig gelebt. Product Owner*innen, Stakeholder und auch Umsetzungsteam tappen in die Falle des bisher Gelebten: Erst dann, wenn etwas zu 100% komplett ist, können wir es als fertig betrachten. Eine Diskussion darüber, was ein verwendbares Inkrement ist und wie dieses im Einzelfall als eine Art Zwischenlösung fungieren kann, findet nicht statt. Genauso wenig wie eine Auseinandersetzung mit den Fragen: “Was können wir weglassen? Was können wir mit einer Art Zwiebelprinzip auch später machen, damit wir jetzt ein verwendbares Inkrement bekommen?” Stattdessen gilt die Grundhaltung: “Bei uns ist das nun mal so, Storys sind so groß, dass sie sich über Sprints ziehen.”
Zusammenarbeit mit dem Kunden über Vertragsverhandlungen
Jahrzehntelang galt in vielen Unternehmen der Grundsatz: “Der Kunde ist König.” In dem oben genannten Wertepaar des agilen Manifests steckt ein entscheidender Mindset-Shift: Der Kunde ist nicht König*in, sondern Partner*in auf Augenhöhe. Wir wollen mit unseren Kund*innen zusammenarbeiten, um bestmögliche Lösungen zu entwickeln. Das heißt nicht, dass Verträge irrelevant werden oder es keine verbindlichen Vereinbarungen mehr gibt.
Scrum bietet hier mehrere Lösungswege:
indem es mit einem Produkt-Ziel arbeitet, das eine Dienstleistung, ein physisches Produkt oder auch etwas Abstrakteres sein kann.
in dem es das Produkt-Ziel immer wieder in Sprint-Ziele herunterbricht, damit allen klar wird, wieso der Sprint für die Stakeholder*innen von Wert ist.
indem es Product Owner*innen benennt, die die Ansprüche und Bedürfnisse der Stakeholder*innen im Backlog berücksichtigen sollen
indem Scrum Master*innen das Verständnis zwischen Stakeholder*innen fördern sollen.
indem das Scrum Team die wichtigsten Ergebnisse von Sprints in regelmäßigen Reviews den Stakeholder*innen präsentiert.
Diese Liste ist definitiv nicht vollständig, an ihr wird aber in nur fünf Punkten deutlich, dass Scrum sehr viele Mittel und Wege benennt, die Zusammenarbeit mit den Kund*innen aktiv zu fördern.
In der realen Praxis findet die direkte Auseinandersetzung mit relevanten Stakeholder*innen aber nur selten statt. Da werden Zwischenebenen eingezogen, wie Key Accounts oder Projektmanager*innen, die mit Kund*innen kommunizieren. Product Owner*innen werden degradiert zu Ticketersteller*innen. Veröffentlichungs- oder Releasezyklen sind so lang, dass Kund*innen die Ergebnisse doch erst nach Monaten tatsächlich zu Gesicht bekommen. Die Frage, ob es sich um eine neue Anforderung, einen sog. Change Request oder die Ausmerzung eines Fehlers handelt, wird zentraler Diskussionsgegenstand und Sprint-Ziele werden entweder gar nicht definiert oder sind so sinnlos und schwammig, dass die Sprints auch Namen von Comicfiguren tragen könnten.
Die Frage, wie eine aufrichtige und verbindliche Zusammenarbeit mit Kund*innen funktioniert, wird nicht gestellt. Weil das bisher Gelernte eindeutig sagt: Wir sind Dienstleister*in oder Lieferant*in. Im Zweifel müssen wir für unser Recht kämpfen, genau wie unsere Kund*innen für ihr Recht einstehen müssen. Alle ziehen sich auf Vertragsvereinbarungen zurück, weil Vorerfahrungen besagen, dass Organisationen nun einmal nicht offen und ehrlich miteinander umgehen: Im Zweifel wollen uns andere etwas Böses. Was stattdessen helfen würde: echte Aufrichtigkeit. Gespräche darüber, inwiefern die aktuelle Umsetzung auf Kurs ist. Ein echtes Einbinden von Kund*innen sowie die Grundhaltung: Wir wollen hier gemeinsam unter Berücksichtigung aller Bedürfnisse das beste Ergebnis für alle Beteiligten rausholen. Das ist schwer und nicht von heute auf morgen erreicht, weil es eine Veränderung von tiefsitzenden Paradigmen voraussetzt. Wer aber damit nicht anfängt, wird sich immer wieder damit konfrontiert sehen, zwar irgendwie Scrum zu machen, aber im Zweifel doch wieder nicht das zu liefern, was die Stakeholder*innen sich vorgestellt haben.
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Gehen wir einmal zurück in die Softwareentwicklung und schauen uns Releasezyklen an. Nicht selten umfassen diese drei Monate. Oder aber wir nehmen Skalierungs-Frameworks von Scrum in den Blick: Sie sehen eine Art Quartalsplanung vor. Grob werden die Tätigkeiten von Teams meist für einen Zeitraum von mindestens drei Monaten geplant, weil man meint, heute zu wissen, was in drei Monaten fertig sein sollte. Ganz verkehrt ist das nicht. Ganz richtig aber eben auch nicht. Das Problem ist, dass solche Vorgehensweisen gelernte Paradigmen bedienen. Die Kunst der Agilität hingegen ist es, zwar möglichst klare Produkt- und Sprint-Ziele zu haben, gleichzeitig aber flexibel genug zu bleiben, um auf Änderungen reagieren zu können. Die Idee hinter groben Plänen ist also: Wir überlegen heute, was voraussichtlich getan werden muss, damit wir die Richtung definieren können. Die Details klären wir aber nur für die direkt kommende Iteration. Manchmal auch 2-3 Iterationen in die Zukunft — das ist okay und gerade in komplexen Projekten mit vielen Anforderungen auch durchaus erforderlich.
Aber: In der Realität kostet diese grobe Planung häufig sehr viel Zeit, weil sich Organisationen und Teams in Details verlieren. Sie arbeiten sehr genau aus, was getan werden muss und ob all diese Dinge auch in der passenden Zeit zu schaffen sind. Teams analysieren und diskutieren ihre Velocity, um eine verbindliche Aussage treffen zu können und nehmen sich damit die Chance, in echten Inkrementen und Iterationen zu denken. Im schlimmsten Fall wird festgelegt, welche Features auf jeden Fall Teil der Versionsplanung sein werden. Diese werden an Kund*innen kommuniziert und Teams sehen sich mit starren Vorgaben konfrontiert. Dabei ist all dies gar nicht so gedacht.
Der Scrum Guide erläutert die Arbeit in Iterationen ausführlich und sagt dabei sehr deutlich: das Planning, das Daily Scrum und andere Absprachen innerhalb des Entwicklungsteams dienen dazu, einen Plan für die jeweilige Iteration (den Sprint) zu erstellen und diesen Plan auf akute Veränderungen anzupassen. Das heißt nicht, dass einmal geplante Storys und Inkremente ständig verworfen werden sollten (dann stimmt in der Backlog-Priorisierung davor etwas nicht). Es heißt aber auch: Ob das gesetzte Ziel erreicht werden kann und welche Maßnahmen es dafür braucht, wird regelmäßig überprüft. Wenn wir nun eine Versions-oder Quartalsplanung haben, müsste dies folgerichtig auch auf dieser Ebene geschehen. Häufig passiert aber genau das nicht. Wieso? Weil die Abhängigkeiten riesig sind. Weil sich niemand traut, die wertvoll investierte Zeit in den Papierkorb zu werfen. Weil Pläne als starres Konstrukt angesehen werden, welches umgesetzt werden muss. Niemand möchte die Person sein, die darauf hinweist: “Die Umstände haben sich geändert, unser Plan ist nun leider murks”. Lieber wird geschwiegen. Das Problem daran: Die Tatsache verändert sich ja nicht. Wenn ein Plan nicht mehr umzusetzen ist, ist er nicht mehr umzusetzen. Das ist eine Veränderung, auf die reagiert werden muss. Vorerfahrungen, Organisationskultur und Paradigmen verhindern aber ein Gespräch hierüber. Product Owner*innen oder Teamleiter*innen teilen im Zweifel ungern mit “wir haben uns verschätzt” oder “es hat sich etwas in den Prioritäten verändert”, weil sie sich ggf. in ihrer Kompetenz in Frage gestellt fühlen. Denn “einen Plan haben” wird auch heute noch mit Kompetent-Sein gleichgesetzt.
Scrum und Agilität wollen einen Paradigmenwechsel: Sie wollen ein ernsthaft iteratives Vorgehen, das darauf basiert, dass jegliche Planung murks sein darf. Ein Vorgehen, das Flexiblität ermöglicht, um die besten Lösungen zu finden und aus Fehlern zu lernen. Wenn wir Scrum als Methoden-Framework nutzen, uns aber nicht im selben Atemzug daran halten, nur das zu planen, was wir wirklich ganz sicher wissen, dann entsteht ein Szenario in dem feststehende Anforderungen in Iterationen abgearbeitet werden. Und ja, dann darf man sich schon mal fragen, ob es wirklich ein zweiwöchiges Sprint-Planning braucht, oder ob man nicht einfach die geplanten Dinge wie geplant durchexerzieren kann.
Scrum als Methoden-Framework möchte das agile Manifest mit Leben füllen. Der Scrum Guide bietet hierfür zahlreiche “Vorgaben” und Anhaltspunkte. In der Umsetzung werden diese aber häufig nicht berücksichtigt. Stattdessen wird der Scrum Guide als eine Art Regelwerk verstanden, weil er auch Paradigmen trifft, die tief in Organisationen und Teams verankert sind. Wer wirklich agil werden möchte, muss diese Paradigmen suchen, erkennen und bearbeiten. Weil der Mehrwert von Agilität nur dann spürbar und erlebbar wird. Eine Umsetzung von Scrum ohne Paradigmen zu bearbeiten ist nichts anderes als “alter Wein in neuen Schläuchen”. Die bisherige starre Struktur und Vorgehensweise wird durch eine andere starre Struktur und Vorgehensweise abgelöst. Es gibt keinen sichtbaren Gewinn. Die Wirksamkeit verpufft.
Mehr über das Methoden-Framework Scrum mit seinen Artefakten, Rollen und Ritualen lernt ihr in unserem Team-Workshop Agiles Arbeiten und Methoden und bringt es dort auch zur Anwendung.