.st0{fill:#FFFFFF;}

Scrum Toolbox

Guardrails: Was die Leitplanken bewirken

 Juni 28, 2022

von  Sebastian Schneider

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.

Roman Pichler Product

Quelle: Roman Pichler https://www.romanpichler.com/blog/strategic-options-for-mature-products/ (28.06.2022)

Jurgen Appelo Business Lifecycle Stages

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

Guardrails im Scaled Agile Framework

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:

  • Horizon 3 / Evaluating. In diesem Bereich geht es sehr stark um die Evaluierung, bei der du mit MVP's arbeitest.
  • Horizon 2 / Emerging. Hier tauchen neue Chancen und Geschäfte auf.
  • Horizon 1 / Investing & Extracting. Hier ist das Business und das Produkt spielt das Geld ein.
  • Horizon 0 Retiring. Irgendwann ist eine Ende eines Produktes vorbestimmt und es wird vom Markt genommen.

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:

  • Erhöhung des WIP. Beachte genau, ob du nicht indirekt dein Work in Progess erhöhst. Wo du sonst nur ein Backlog hast, kann es nun passieren, dass du mit doppelter Arbeit zu kämpfen hast.
  • Klarheit vs. Diskussion. Ist alles nur eine lange sortierte Liste von dem, was du zu tun hast - ist die Welt einfach. Änderst du das, benötigst du viele Diskussionen und viel Verständnis in deiner Organisation. Die Einfachheit kann durch Komplexität ersetzt werden.
  • Aufwand. Ich habe schon Mannjahre in die Diskussion und den Aufwand zur Definition von solchen Guardrails (z.B. Capacity Allocation) verschwinden gesehen. Es ist nicht einfach, je mehr du messen möchtest, desto mehr ist auch zu tun und so mehr befassen sich Menschen mit Dingen, die nicht zur Wertschöpfung beitragen.
  • Abgrenzung. Wenn du 20% für etwas reservierst, geht schnell die Diskussion los, was passiert bei 21%? Kann man das auch messen? Ist das sinnvoll? Muss das jeder genau so machen?

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.

Sebastian Schneider

Ein paar Worte über den Autor

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

Sebastian Schneider CSP-PO
Sebastian Schneider CSP
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Hole dir auch den kostenlosen Online Scrum Kurs

>