.st0{fill:#FFFFFF;}

Scrum Skalierung

Muster: Ebenen oder Einheiten

 April 4, 2021

von  Sebastian

Es gibt ein sehr schönes Muster bei der Skalierung von agilen Ansätzen. In diesem Artikel zeige ich dir den Unterschied zwischen den zwei Mustern der Ebenen und Einheiten. Während die reinen Agilisten das Einheiten-Muster präferieren, tendieren größere Unternehmen meist zu einem Ebenen Muster. Beide sind nicht falsch, gut oder böse - die Frage ist, was der Anwender damit bezwecken möchte.

Was sind Muster?

Muster sind wiederholende Abläufe oder Vorgehen, die wir in Organisationen die ganze Zeit beobachten können. Auch die sind erstmal nicht gut oder schlecht, sondern etablieren sich in der Regel auf Basis der Struktur, der daraus folgenden Kultur und zuletzt auch von sogenannten Denkfehlern. Doch dazu später mehr.

Die Muster im Vergleich

Ebenen und Einheiten

In diesem Abschnitt möchte ich dir gerne die beiden Muster der Ebenen und der Einheiten kurz vorstellen und jeweils beschreiben. Wir gehen dabei auf die Beschreibung ein, was diese Muster ausmachen und wo Reflexionsfragen dir weiter helfen können.

Ich weiß, dass diese Muster in der Praxis sehr polarisieren und unterschiedlich gesehen werden. Ich möchte hier auch keine Verurteilung oder eine Bewertung treffen, da ich denke, dass das Kundenproblem im Mittelpunkt stehen sollte. Dabei können beide Ansätze helfen. Ich denke, nur wer sich in das Unternehmen reindenken kann und die Perspektive einnimmt, der lernt, welches Muster helfen kann.

Ebenen

In meinem Artikel zum Agiles Portfoliomanagement habe ich die Ebenen mit im agilen Portfoliomanagement angerissen. In diesem Artikel stehen die Ebenen noch mal genauer unter der Beobachtung.

Man merkt schnell daran, ob es sich um "Ebenen" handelt, wenn die Rollen für die Organisation explodieren oder zumindest die Diskussion darüber geführt wird. So gibt es nicht nur den Product Owner, sondern auch schnell z.B. die Rolle Produktmanager oder extra Architekten, Manager, Qualiätsteams und ähnliches. Und schon geht es schnell: Der Produktmanager darf aber nicht auf der gleichen "Ebene" wie das Team stehen und der Architekt darf doch bestimmt alle Entscheidungen revidieren, die die Teammitglieder machen, oder?

Diese Diskussionen finden mitunter zügig in Organisationen statt. Wenn Unternehmen nicht besonders reif hinsichtlich Agilität sind, dann verwenden diese gerne so eine Ebenenkonstruktion. Das muss nicht falsch sein und mag dem Entwicklungsstand des Unternehmens absolut entsprechen. So helfen diese Ebenen tatsächlich einen ersten Schritt zu Experimenten oder einen anderen Organisationsmodell zu gehen.

Die Gefahr an dieser Stelle ist aber auch, dass die Unternehmen dann in solchen Mustern verharren. Gerade, wenn etwas nicht einfach ist, dann wird es kompliziert. Und wenn es kompliziert wird, dann verlieren Menschen schnell den Fokus, die Lust und auch die Motivation. Und je nach Ausprägung und Implementierung, deskalieren diese Unternehmen nicht, sondern machen die Dinge nur noch komplizierter. Dann hat das mit Agilität nichts zu tun, mit Scrum auch nicht - ob es hilft bleibt fraglich.

Doch auch nicht jede Ausprägung des Muster von Ebenen muss schlecht sein. Es gibt auch hier schlanke Lösungen, auf die ein Fokus gelegt werden kann. Andere sind absolute Anti-Pattern, die niemand wirklich möchte.

Reflexionspunkte für die Ebenen

  • Bei dem Modell der Ebenen ist schnell die Hierarchie im Spiel und alte Rollen werden behalten. Es kann sein, dass wenig Veränderung in der Organisation stattfindet und alles beim Alten bleibt.
  • Ein Übergang zwischen Ebenen erzeugt in der Regel immer Kommunikation. Du musst dich immer fragen, ob der Mehraufwand im Verhältnis zum Nutzen steht. 
  • Die scheinbare Kontrolle durch die Ebenen kann falsch verstanden werden. Wenn wir von oben und unten sprechen, dann erzeugt das schnell eine Hierarchie, Bewertung und Abhängigkeit. Nicht jeder kann damit richtig umgehen.
  • Auch wenn scheinbar "Ebenen" oder "Verantwortungen" gefordert werden, sollte das Warum stark hinterfragt werden. Oft ist das (zum Beispiel durch Normen o.ä.) bei genauerer Betrachtung gar nicht der Fall. 

Einheiten

Im Muster der Einheiten ist alles eine Einheit, es gibt keine Ebenen und alles ist nur eine Produktentwicklung. Du kannst dir das wie eine Zelle oder einen Organismus vorstellen. Die Einheit liefert alles was es für das Produkt benötigt, ist autark und am besten auch noch redundant in einem Netzwerk von Teams. Doch so weit muss ein Unternehmen gar nicht gehen. Auch wenn das Unternehmen es schafft, mit der richtigen Produktdefinition ein einziges Produkt zu definieren ist das oft ein überragender Erfolg und ermöglicht es zu echter Agilität zu kommen.

Autonome, wertliefernde Einheiten zu erstellen ist in der Tat gar nicht so trivial. Wir Menschen (und gerade mit hierarchischer Prägung) tendieren immer gerne zu verschiedenen Ebenen und Verantwortungen.

Wenig überraschend erfordert dieser Ansatz massiv Reife im Unternehmen. Es müssen im Grunde alle Strukturen in der Organisation überprüft und nicht selten auf den Kopf gestellt werden. Gerade wenn wir uns Teams anschauen, dann ist es unabdingbar, dass diese in einer gute Art der Multidisziplinarität aufgestellt sein müssen.

Es lässt sich auch ganz gut sagen, dass du dann im Grunde nichts außer Scrum in einer Organisation brauchst, da die Organisation so aufgestellt ist, damit das reicht und zum Erfolg führt.

Reflexionspunkte für die Einheiten

  • Eine Einheit ist oft der einzige Weg zur richtigen Agilität ohne Abhängigkeiten in der - oder als - Organisation zu bekommen. Was benötigt es dazu bei dir?
  • Die Produktdefinition ist ein ganz entscheidendes Thema, wenn wir uns Einheiten ansehen, denn sind es doch oft genau diese Produktdefinitionen, die einen Ansatz der Einheiten schwierig machen.
  • Gerade wenn du hörst "das kann bei uns nie klappen", solltest du genau hinterfragen warum. Meisten liegt das Problem in Produktdefinition und Team begraben. 

Sebastian

Ein paar Worte über den Autor

Agile Team Facilitator Sebastian Schneider
ICP-ACC Sebastian Schneider
Sebastian Schneider CSP
Sebastian Schneider CSP-PO

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.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Sei auch mit dabei: Der Newsletter zu Scrum aus Augsburg.

>