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
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
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.