Der modische Gebrauch agiler Arbeitsweisen, wie z.B. Scrum scheint auch einen Wettbewerb über den „richtigen“ Weg deren Umsetzung mit sich zu bringen. Ich denke, dass das Befolgen einer vordefinierten Arbeitsweise erstens nicht möglich ist, und zweitens keinen Wert an sich darstellt.
Stattdessen sollte sich aus meiner Sicht eine (ggf. erforderliche) Beurteilung daran orientieren wie wirksam die (agile) Arbeitsweise in Bezug auf das selbst gesteckte Ziel ist, und, ob sie für den erforderlichen Zeitraum etabliert werden kann – also, Wirksamkeit und Umsetzbarkeit.
- Zum undogmatischen Umgang mit Scrum-orientierter Arbeitsweise
- Verwendung von Scrum-Terminologie
- Müssen mit Scrum immer Produkte entwickelt werden ?
- Einige Beispiele für Scrum in der Praxis
- Schlussbemerkungen
Zum undogmatischen Umgang mit Scrum-orientierter Arbeitsweise
Immer mal wieder ist mir selbst, und auch in Äußerungen von anderen der Satz untergekommen: „Aber, das ist ja gar kein (echtes) Scrum.“, worin auch ein gewisser Vorwurf und Geringschätzung stecken konnte.
Dahinter steckten zwei grundlegende Vorstellungen:
- Es ist besser „echtes“ Scrum gemäß Scrum Guide[1]https://scrumguides.org/index.html (oder einem anderen definerten Rahmen, z.B. Scaled Agile Framework (SAFe)[2]https://scaledagileframework.com/), umzusetzen, anstatt irgend so einen selbstgestrickten Pseudo-Scrum-Kram zu machen und
- wer Scrum-Begriffe verwendet hat gefälligst nach Scrum Guide zu arbeiten.
Einige Projekte später sehe ich die Sache etwas anders. Ich habe in unterschiedlichen Konstellationen erlebt, wie sich Scrum-Ansätze in der Praxis umsetzen lassen, und wie sie sich nicht umsetzen lassen. Dabei wurde in allen Projekten recht schnell deutlich, dass die simplifizierten Rollen- und Prozessbeschreibungen nach Scrum Guide durchaus wertvoll sind, auch wenn sie sich in meinem Umfeld so niemals umsetzen ließen. Der Wert bestand darin, eine klare Ausgangsituation und Arbeitsstruktur zu haben, von der aus sich je nach Projekt geeignete Arbeitsweisen etablieren konnten. Insofern kann ich zum ersten Punkt sagen, dass eine Umsetzung von Scrum an sich keinen Wert mit sich bringt. Scrum als Referenz, um von dort aus den eigenen agilen Weg zu entwickeln, habe ich aber als hervorragendes Vorgehen erlebt. Daher verwende ich im Folgenden „Scrum“ auch ohne „but“ als Begriff für eine Scrum-orientierte Arbeitsweise.
Scrum kann eine klare Ausgangsituation und Struktur schaffen, um davon ausgehend eigene Arbeitsweisen zu etablieren.
Verwendung von Scrum-Terminologie
Am zweiten Punkt
wer Scrum-Begriffe verwendet hat gefälligst nach Scrum Guide zu arbeiten
bleibe ich bei der Bewertung, dass der Einsatz von Begriffen, die dem Scrum Guide entlehnt sind, aber im Rahmen gänzlich anderer Arbeitsweisen eingesetzt werden einfach falsch ist. Wenn z.B. eine beliebige Zeitspanne zwischen zwei Board-Reviews „Sprint“ genannt wird, ist das so, als würde ich einen „Stuhl“ „Sofa“ nennen, nur, weil man auch darauf sitzen kann.
Heißt das für mich, dass es Scrum Master und Product Owner nur geben kann, wenn der Scrum Guide 100% umgesetzt wird? Nein, denn ich denke, dass es gar nicht erstrebenswert ist, den Scrum Guide umzusetzen.
Erstrebenswert ist es aus meiner Sicht Rollen und Arbeitsweisen aufbauend auf dem Scrum Guide zu etablieren und bei der Verwendung der jeweiligen Begrifflichkeiten sensibel damit umzugehen wie weit sich die eigene Arbeitsweise vom Scrum Guide entfernt hat – es ist ja keine Schande z.B. mit einem agilen Coach anstatt einem Scrum Master zu arbeiten. Gleichzeitig sollte ein „Product Owner“ maßgeblich Verantwortung für einen Arbeitsvorrat bzw. Backlog tragen und nicht einfach jemand sein, der dem Management gegenüber rechenschaftspflichtig für ein „Produkt“ ist.
Es ist gar nicht erstrebenswert den Scrum Guide umzusetzen.
Müssen mit Scrum immer Produkte entwickelt werden ?
Nicht die Definition des Produkts ist entscheidend, sondern, dass die angestrebten Ergebnisse werthaltig, umsetzbar und wirksam sind.
Hier ist schon der nächste herausfordernde Punkt: Scrum ist zur Produktentwicklung gedacht. Was aber das Produkt jeweils ist, ließ sich in meinen Erfahrungen teils nur schwierig beschreiben, was sich teils als wirklich problematisch, teils als egal heraus stellte.
Mit der Definition des Produkts einher geht die Ableitung releasefähiger Inkremente, die ja nach Scrum das Ziel jedes Sprints sind. Wenn es kein klar beschreibbares Produkt gibt, fällt es schwer am Ende jedes Sprints funktionierende Teilprodukte davon zu erstellen.
Für mich hat sich als wichtig herausgestellt, dass der Backlog Inhalte enthält, die zu sinnvollen und werthaltigen Ergebnissen führen sollen. Ob diese Backloginhalte dann gemeinsam zur Entwicklung eines Produkts führen, spielt nicht unbedingt eine Rolle.
Was gut funktionieren kann, ist ein Fokus auf umsetzbare und wirksame Ergebnisse der jeweiligen Backlogeinträge. Hier liegt der Wert dann nicht in der Betonung auf Teil-Produkt, sondern auf releasefähig. Wobei auch releasefähig in einem nicht-IT-Projekt umgedeutet werden muss – in meinen Erfahrungen war das Ziel Backlogeinträge zum Ende eines Sprints möglichst unmittelbar anwendbar und wirksam fertig gestellt zu haben. Das kann z.B. durch eine Fokussierung auf einen Einzelfall, wie beispielsweise einen bestimmten Abschnitt einer Prozessbeschreibung erfolgen, der dann als Prototyp für die breitere Anwendung seine Tauglichkeit demonstriert.
Einige Beispiele für Scrum in der Praxis
Damit meine oben geäußerten Meinungen und Erfahrungen nicht allzu abstrakt bleiben, habe ich hier einige Interpretationen von Scrum in der Praxis ausgeführt, in denen ich selbst eine aktive Rolle gespielt habe. Es sind kurz gefasste Beispiele, die keine Anspruch auf eine vollständige Beschreibung und erst recht nicht auf allgemeingültige Anwendbarkeit erheben. Sie können im besten Fall als Anregung für den eigenen geeigneten Scrum-Weg dienen.
Scrum Team eingebettet in ein Meilenstein-Projekt
Entwicklung einer Software als Phase innerhalb eines Projekts zur Prozessverbesserung.
Hierbei war die Entwicklung einer IT-Lösung eingebettet in ein recht typisch an Meilensteinen entlang geplantem Projekt. Im Gegensatz zur Beschreibung im Scrum Guide war die Product Owner Rolle in geteilter Verantwortung. Neben dem Projektleiter übernahm auch der Teamleiter des Entwicklerteams PO-Tätigkeiten, z.B. das Schreiben von umsetzbaren User Stories. Nach außen, sprich in Richtung der Auftraggeber und anderer Stakeholder und Beteiligter nahm der Projektleiter typische Aufgaben des PO wahr.
Während das Entwickler Team mit Scrum Master und Backlog sehr nahe an der im Scrum Guide beschriebenen Arbeitsweise agieren konnte, war das eigentliche Projekt eingebettet in eine recht hierarchische Umgebung. Die umgesetzten Kombination erwies sich als außerordentlich effektiv, da mittels Scrum-Prozess ein klar definiertes Produkt – die IT-Lösung – anwenderorientiert entwickelt und in den Routinebetrieb übergeben werden konnte.
Initiativen-orientiertes Scrum Team
Teams werden themenspezifisch für eine begrenzte Anzahl von Sprints zusammengestellt.
Das Scrum Set-Up unterstützte eine stabile Arbeitsweise, obwohl sich die Besetzung des Entwicklerteams und die Stakeholder immer wieder änderten. Während der Sprints war die Besetzung allerdings fest. Das Funktionieren dieser Interpretation von Scrum hing essentiell an der Überzeugung für die Effektivität der Arbeitsweise und die enge Zusammenarbeit von PO und Scrum Master.
Sprints statt Meilensteile: Fokussierteres Arbeiten durch Scrum
Konsequente Arbeit am Backlog, um Team-Ressourcen effizient und zielgerichtet zu nutzen.
Eher klassisch aufgesetzte Projekte entlang von Meilensteinen können erheblich in Schwierigkeiten geraten, wenn Teilprojektleiter untereinander um knappe Ressourcen kämpfen (müssen). Mit dieser Erfahrung haben wir uns entschieden die Meilensteinpläne einzelner Teilprojekte zugunsten eines Backlogs aufzugeben und die umstrittenen Ressourcen in einem Entwicklerteam zusammenzuführen.
Auf diese Weise konnten wir im Gesamtinteresse priorisieren, um von der Ausgangslage in Richtung der Zielsituation zu arbeiten Scrum, als Methode zur Entwicklung von Produkten bei denen am Anfang des Endergebnis noch nicht vollständig bekannt ist, hat sich auch hierbei als effektiver Rahmen erwiesen – wir konnten die Zielsituation zwar recht allgemein beschreiben, die Details unserer Lösung waren aber nicht im Vorhinein bekannt und haben sich erst im Laufe der Projektlaufzeit entwickelt. Es ist keine Überraschung, dass es sich als viel besser herausgestellt hat von Sprint zu Sprint den Backlog weiterzuentwickeln, als ständig die Meilensteine von Teilprojekten umzuformulieren .
Flexibles, skaliertes Scrum
Kontinuierliche Weiterentwicklung von Geschäftsprozessen mit mehreren parallel arbeitenden Scrum-Teams. Die Koordination soll auf möglichst schlanke Weise erfolgen.
Scrum zu skalieren ist nicht einfach. Rahmenwerke, wie z.B. SAFe[3]https://scaledagileframework.com/ und https://de.wikipedia.org/wiki/Scaled_Agile_Framework oder Nexus[4]https://www.scrum.org/resources/nexus-guide geben Orientierung und geben teils sehr spezifisch beschriebene Strukturen vor. Ich kenne einige Anwendungsfälle, in denen SAFe erfolgreich in der Praxis umgesetzt wird.
Folgende Gründe sprachen für uns gegen eine direkte Umsetzung von SAFe:
- Ein eher traditionell orientiertes Umfeld. In Verbindung mit mangelnder (und guter) Erfahrung agiler Arbeitsweisen hätte eine SAFe-orientierte Struktur eine zu weitreichende Veränderung mit sich gebracht. Das betraf in erster Linie die Notwendigkeit die Unterstützung des Abteilungsmanagements zu gewinnen.
- Der Zweck Geschäftsprozesses kontinuierlich weiterzuentwickeln und nicht definierte Produkte zu entwickeln. Allein der Transfer, der erforderlich gewesen wäre, um Release Trains mit annähernd äquivalenter Bedeutung im Kontext sehr unterschiedlicher Geschäftsprozesse zu formulieren war abschreckend.
- Die Erwartung, dass sowohl die Teammitglieder, als auch die notwendigen Experten weiterhin ihre Routineaufgaben haben würden, und somit die Verfügbarkeit der Ressourcen nicht als stabil betrachtet werden konnten.
Stattdessen haben wir eine Struktur etabliert, in der (halb unabhängige) Scrum-Teams parallel arbeiten und die inhaltliche und methodische Abstimmung mittels eines Programm-Teams erfolgt. Diese Scrum Teams nennen wir Streams mit je einem Stream Owner (statt Product Owner), einem Scrum Master und einem crossfunktionalem Entwickler Team. Jeder Stream hat seine eigenen Stakeholder. Dabei kommt es durchaus vor, dass bestimmte Personen als Stakeholder in mehreren Stream engagiert sind.
Eine Abstimmung zwischen den Streams erfolgt in einem Programm Team, das aus den Stream Ownern, Scrum Mastern und zwei „Programm-Managern“ besteht. Die beiden Programm-Manager übernehmen koordinierende Aufgaben, unterstützen die übrigen Rollen bei Bedarf und stehen zur Vertretung aller anderen Rollen bei Abwesenheiten zur Verfügung.
Schlussbemerkungen
Anhand der obigen Beispiele lässt sich erkennen, dass der Scrum Rahmen vielfältige Möglichkeiten bieten kann, auch in eher hierarchischem Organisationsumfeld Räume zu schaffen, in denen Teams iterativ und mit hoher Eigenverantwortung arbeiten können. Für mich haben sich drei wichtige Faktoren herauskristallisiert, die erfolgreiche Umsetzung der Arbeitsweise beeinflussen:
- Der Wert der Ergebnisse (Produkte) muss für das verantwortliche Management offensichtlich sein;
- Alle Personen, die von der Arbeitsweise betroffen sind, müssen eine scrum-orientierte Arbeitsweise wollen;
- Es muss eine Bereitschaft geben die Arbeitsweise kontinuierlich weiterzuentwickeln, ohne hektisch Notmaßnahmen zu ergreifen, falls es mal nicht so rund läuft.
Nachdem seit dem Schreiben der ersten Zeilen dieses Artikels einige Zeit ins Land gegangen ist, verwundert es mich nicht, neulich über Artikel gestolpert zu sein, in dem die agile Arbeitsweise sehr kritisch beleuchtet wird[5]Nur Mut! – Endlich raus aus der Scrum-Hölle | heise online](https://www.heise.de/blog/Nur-Mut-Endlich-raus-aus-der-Scrum-Hoelle-9860999.html. Denn, ein Rahmenwerk wie Scrum oder das agile Manifest an sich, ändern irregeleiteten Management-Vorstellungen von produktiver Arbeit nicht.
Mein Eindruck ist, dass wirklich überzeugt von der agilen Arbeitsweise nur diejenigen waren (und sind), die auch mit klassischen Projektmanagementmethoden sensibel und angemessen umgehen können.
Titelbild: Jürgen (nach de Chirico), Hektor und Andromache
Letztes Update
References
| ↑1 | https://scrumguides.org/index.html |
|---|---|
| ↑2 | https://scaledagileframework.com/ |
| ↑3 | https://scaledagileframework.com/ und https://de.wikipedia.org/wiki/Scaled_Agile_Framework |
| ↑4 | https://www.scrum.org/resources/nexus-guide |
| ↑5 | Nur Mut! – Endlich raus aus der Scrum-Hölle | heise online](https://www.heise.de/blog/Nur-Mut-Endlich-raus-aus-der-Scrum-Hoelle-9860999.html |