Strategische Leitplanken gibt es viele in Unternehmen. Ob und wie diese sinnvoll für Scrum sein können, betrachte ich in diesem Artikel über die Guardrails. Dabei schauen wir uns an, welche es geben kann, welche in der Realität vorkommen und wo der Gedanke grundsätzlich herkommt.
Was bedeuten Guardrails?
Starten wir mit dem grundsätzlichen Verständnis über die Guardrails. Ich finde die Übersetzung des englischen Begriffs schon sehr treffend: Leitplanken. Guardrails sind Leitplanken, die sich strategisch steuern sollen. Sie spannen also einen Rahmen oder Raum auf, in dem du dich als Organisation, als Team, als Produkt, ... bewegen kannst.
Synonym: Guardrails sind Leitplanken
Das Synonym der Guardrails sind die Leitplanken, die wir auch als visuelles Bild im folgenden Artikel nutzen wollen.
Wo werden Guardrails eingesetzt?
Die überwiegende Anwendung von Guardrails findet nicht im Scrum Kontext statt, sondern fast ausschließlich im größeren, organisatorischen Kontext. Ich möchte den Bereich der strategischen Betrachtung bei einer Skalierung nennen, der sich auf ein Ebenen Modell bezieht. Ebenemodelle sind zum Beispiel das SAFe oder agiles Portfoliomanagement.
Hier musst du immer aufpassen, denn nicht jede Skalierung benötigt solche Leitplanken explizit. In einem Ebenen Modell wie einem SAFe findest du solche Guardrails, in einem Einheiten Modell wie dem LeSS nicht. Dort werden solche Guardrails im Grunde durch die Produktdefinition bzw. das Organisationsdesign berücksichtig und sind nicht explizit nötig.
Dabei muss man oft unterscheiden, was Guardrails sind und wie diese wirklich interpretiert werden. Das ist in der Praxis - wie so oft - sehr unterschiedlich.
Guardrails in Scrum
Es gibt keine expliziten Guardrails in Scrum
Warum gibt es keine Guardrails in Scrum? Guardrails sind grundsätzlich eine Technik, die wir stark im Bereich vom Management, Führung und Strategie von großen Systemen finden.
Da wir in Scrum erstmal ein Team betrachten, finden wir den Begriff schon mal nicht im Scrum Guide, was absolut verständlich ist. Doch auch bei einer Skalierung mit LeSS (Scrum mit Scrum skalieren) finden wir diesen Begriff nicht. Aber im Kontext eines Scaled Agile Framework schon.
Das Produkt kann eine Guardrail sein
Scrum selbst ist sehr auf das Produkt ausgerichtet. Es gibt dafür das Product Backlog für alles, was wir für das Produkt brauchen. Der Product Owner sortiert dieses und ist implizit damit für alle Leitplanken selbst verantwortlich.
Lebensphasen eines Produktes können Guardrails sein
Produkte haben verschiedenen Lebensphasen und innerhalb dieser Lebensphasen kann es sinnvoll sein, unterschiedlich Budget oder Arbeit zu investieren und damit auch einen Einfluss auf die Product Backlog Items zu üben.
Um dir da mal ein Bild zu geben, kannst du dir zum Beispiel von Roman Pichler eine Grafik zum Lebenszyklus ansehen oder auch die Variante von Jurgen Appelo betrachten. Es ist immer das gleiche und vom Standpunkt des Lebenszyklus. Ich will keinen kompletten Vergleich anstellen, aber jeder - inkl. SAFe - betrachtet diesen Aspekt von einem anderen Standpunkt auf das gleiche Thema.
Quelle: Roman Pichler https://www.romanpichler.com/blog/strategic-options-for-mature-products/ (28.06.2022)
Quelle: Jurgen Apello https://unfix.work/blog/lets-unfix-safe (28.06.2022)
Im Grunde weiß ein guter Product Owner, wann er was hinsichtlich seines Produktes investieren muss. In Scrum ist das oft nicht so wirklich explizit. Da aber auch Scrum ein Framework ist, kannst du dieses natürlich mit mehr konkretem "wie" umsetzen.
Guardrails setzt der Product Owner
In einer funktionierenden Scrum Implementierung setzt ein Product Owner diese Leitplanken. Je weniger eine Scrum Implementierung funktioniert und je mehr von Scrum abgewichen wird, desto eher findest du formale Guardrails.
Ich komme später noch einmal genauer darauf zu sprechen, Guardrails sind oft eine Rahmenbedingung, die eingeführt werden, wenn etwas anderes schon nicht mehr funktioniert.
Guardrails in SAFe
Das Scaled Agile Framework beruft sich auf vier Guardrails, die auch direkt im SAFe beschrieben sind. Wenn wir dort etwas weiter in die Details schauen, stellen wir fest: Das kommt nicht von den Erfindern vom SAFe, sondern findet sich in Quellen über Lean Management, Mc Kinsey und auch Lean Startup.
Werfen wir hier aber auch einen Blick auf die vier Guardrails in SAFe:
Horizons
Anhand von einem Lebenszyklus kann findet im Grunde eine Capacity Allocation auf eine Lebensphase statt. Was genau diese Capacity Allocation ist, zeige ich dir noch im nächsten Abschnitt. Dabei wird hier versucht einen guten Mix der Investitionen über die Lebensphasen zu erreichen, damit kurzfristige Chancen (z.B. MVPs) und längerfristige Strategie und Wachstum in Einklang gebracht werden können.
Für den Horizon Guardrails gibt es unterschiedliche Einteilungen:
Du kannst grob sagen, dass Horizont 3 und 2 dafür da sind, dein Business wachsen zu lassen. Bei Investing & Extracting verdienst du Geld (Horizont 1)
Capacity Allocation
Eine Capacity Allocation hilft dir Product Backlog Items, die normalerweise nicht oben in dem Product Backlog stehen trotzdem auszuwählen. Deine erste Frage sollte sein, warum solltest du das tun, wenn diese Items eben nicht ganz oben stehen?
Oft werden zum Beispiel Architekturthemen angeführt, die Businessthemen überholen müssen, damit das Produkt auch längerfristig noch funktioniert.
Erfahrung: Oft findet rund um Capacity Allocation eine Diskussion statt, die niemandem wirklich hilft: Machen wir 20% Architektur? Und was ist dann bei 21%? Und manche Teams brauchen mehr oder weniger dann! Ach so, soll nur eine Richtlinie sein ... okay, wozu brauchen wir es dann überhaupt?
Überprüfe unbedingt, ob und wie du Capacity Allocation tatsächlich benötigst.
Siginificant Initiatives
Das Scaled Agile Framework schlägt vor, dass bestimmte Initiativen einen Schwellenwert haben. Dieser Schwellenwert ist damit auch eine Leitplanke. So kann es sein, dass ein EPIC einen besonders hohen Invest hat, man diesen aber zum Beispiel nicht oder gerade deswegen doch, auf dem Portfolio sehen möchte. Mit diesem Schwellenwert hat die Organisation einen Hebel dazu.
Business Owner Engagement
Die Guardrail ist im Grunde und sehr einfach ausgedrückt, die Intelligenz des Product Owners selbst. In SAFe wollen wir den Business Owner (neue Rolle, denen "gehört" das Business) mit einbinden und so tauchen diese als "Kommunikationseinheit" auch in den Guardrails auf. Das sollte aus meiner Sicht selbstverständlich sein. Hier wird es im Sinne des Aligments aber noch einmal extra hervorgehoben.
Problematiken mit Guardrails
Wenn man es abstrakt betrachtet, dann ist das Bild von Guardrails schlüssig, doch aus meiner Sicht lauern dort einige Gefahren:
Fazit zu Guardrails in Scrum
Wenn du aus der Sicht von Scrum schaust, wirst du mit Guardrails eher gar nicht bis wenig in Berührung kommen. Wenn du ein Lean Portfolio Management Training machst, wirst du mit diesen Leitplanken in Berührung kommen.
In Scrum gibt es im Grunde eine ähnliche Guardrail, wie auch im SAFe. Nämlich das Business Owner Engagement. Allerdings gibt es natürlich die Rolle des Business Owners nicht. Hier kannst du aber den Product Owner nennen.
Möchtest du Guardrails nutzen, dann achte unbedingt auf typische Dysfunktionen und frage dich bei jedem Schritt, ob du ihn wirklich benötigst.
