Offene Fragen zu Scrum und dem Viable System Model

Ist Scrum eine Methode, die die Lebensfähigkeit einer Organisation befördert? Diese Frage haben Mark Lambertz und Heiko Bartlog in einem Video diskutiert. Mark hat ein Buch über das Viable System Model (VSM) von Stafford Beer geschrieben, Heiko ist Scrum-Experte.

Das VSM hat den Anspruch, ganz fundamental und allgemein zu beschreiben, aus welchen Komponenten ein (über)lebensfähiges System aufgebaut sein muss. Es soll gleichermaßen gültig sein für Organismen (biologische Systeme) wie für Organisationen (soziale Systeme).

Ich finde, das ist ein spannender Ansatz – wenn auch manchmal noch ein wenig abstrakt dargestellt in Marks Buch.

Doch genau da sollte das Experiment von Mark und Heiko ansetzen. Es sollte das VSM ein Stück erden durch in Bezug setzen zu einer Methode, die weithin bekannt und ganz pragmatisch ist: Scrum.

Eine schöne Idee.

Mit dem Ergebnis hadere ich jedoch. Es macht mich aus mehreren Gründen nicht happy. Konkret ist es zwar. Aber dennoch... Hm... Ich weiß nicht, ob die (von mir herausgelesene) Hypothese in dieser Weise bestätigt wurde, dass Scrum alles hat, was ein VSM braucht.

Überladene Rollen

Zuerst das Offensichtliche: Es wurden nur Rollen gemappt. Im Text steht noch etwas von Prozessphasen – doch die sind am Ende nicht zu sehen.

Zu sehen sind lediglich die Scrum-Rollen, die sich stark "im Kopf" des VSM ballen. Alle Rollen sind im VSM mehrfach verortet. Da frage ich mich, ob das für den angestrebten Zweck Überleben nützlich ist. Denn für mich ist nun vor allem herausgekommen: Überladung. Rollen sind mit Aufgaben überladen, ich würde sogar sagen: überlastet. Trägt das zu einer Lebensfähigkeit bei? Ist das eine gute Sache? Hm... Ich habe da so meine Zweifel. Für mich kein Punkt für Scrum.

Unvollständige Umwelt

Dann fehlt mir im Bild schlicht das Unternehmen, zu dem ein Scrum-Team gehört.

Überleben findet ja im Austausch mit der ganzen Umwelt statt. Das lebende System nimmt aus der Umwelt auf und gibt an sie ab und erhält sich autopoietisch in diesem Prozess selbst – und wächst und pflanzt sich womöglich sogar fort. Alles, was es braucht, bekommt es von der Umwelt.

Für ein Unternehmen besteht die Umwelt aus Kunden (das sind die mit dem Geld), Nutzern (das sind die, die mit den Produkten etwas anfangen), Zulieferern, Ressourcen, Behörden usw. usf.

Wenn nun aber ein Unternehmensteil, eine Sub-Organisation in den Blick genommen wird, dann reicht es nicht, nur Kunden und Nutzer in der Umwelt zu platzieren. Das Teilsystem kann nur für sich überleben, weil das Restsystem zu seiner Umwelt gehört. Nur so kann eine Spezialisierung stattfinden. Ein Scrum-Team muss Aufgaben abgeben an den Rest des Unternehmens, z.B. Verkauf, Marketing, Buchhaltung, Strategieentwicklung usw. usf.

Deshalb gehört das (Rest)Unternehmen in die Umwelt.

Solange das Unternehmen nicht in der Umwelt auftaucht, kann Scrum nicht auf seine Unterstützung der Viability geprüft werden. Ohne das Unternehmen in der Umwelt werden auch viele Probleme, die Scrum-Teams haben, gar nicht plausibel.

Es kommt nicht von ungefähr, dass Agilität sich eben nicht so einfach in Unternehmen einführen lässt. Da werden Sub-Organisationen mit dem Auftrag losgeschickt, schonmal agil zu werden... und das klappt dann nicht. Wie kommt das? Weil sie eben nicht nur Kunden und Nutzer in der Umwelt haben, sondern auch den ganzen Rest des Unternehmens.

Solange das nicht gesehen wird, herrscht aus meiner Sicht eine Agile Organization Illusion.

Fehlende Scrum-Institute

Und schließlich: Warum wurden Rollen und nicht Scrum-Institute gemappt? So nenne ich Sprint Planning, Daily Standup, Sprint Review, Sprint Retro und Sprint.

Beim VSM stehen die Kästchen ja für Tätigkeiten. Sie transformieren. Dafür verlaufen zwischen ihnen Linien, auf denen etwas fließt, das dämpft oder verstärkt. Aus gutem Grund enthält das VSM keine Rollen, sondern nur, was getan werden muss, also stetig laufende Transformationsprozesse. Etwas muss erledigt werden – wer das tut, ist egal. Rollen sind Schall und Rauch. Es ist sogar egal, ob Überlebenswichtiges durch Menschen getan wird oder Software.

Diese grundsätzliche Eigenschaft des VSM wurde nun jedoch beim Mapping nicht berücksichtigt. Sehr schade. Denn das scheint mir die wichtigste Frage: Enthält Scrum alle notwendigen Tätigkeiten bzw. Prozesse, die Lebensfähigkeit erfordert?

Welchem VSM-System entspricht eine Retro, ein Daily, ein Planning, ein Sprint, ein Review?

Hieraus ließen sich auch zwei Gütekriterien ableiten, glaube ich. Scrum (oder eine andere Methode) kann nur der Überlebensfähigkeit solide dienen, wenn...

1. alle VSM-Systeme durch Scrum-Institute besetzt sind und
2. jedes Scrum-Institut nur ein VSM-System besetzt.

Vollständig und eindeutig sollte also das Mapping sein.

• Wenn VSM-Systeme nicht besetzt sind, dann fehlt offensichtlich etwas zum Überleben.
• Wenn VSM-Systeme jedoch mehrfach besetzt sind, dann werden Scrum-Institute überlastet. Nicht nur leitet das schädlichem Multitasking Vorschub, viel schlimmer wäre das eine Geburtsstätte für Zielkonflikte.

Dass VSM-Systeme Zielkonflikte untereinander haben, ist klar. Auch deshalb muss ja in Rückkopplungsschleifen immer wieder Balance hergestellt werden. Deshalb gibt es auch VSM-Systeme mit unterschiedlichen Aufgaben.

Innerhalb eines VSM-Systems darf es jedoch keine Zielkonflikte geben. Deshalb ist die Überladung von Rollen oder Instituten zu vermeiden.

Wozu Überladung führt, zeigt das tägliche Drama in den heutigen Organisationen: Manager fühlen sich hin und her gerissen zwischen der Sache und der Karriere, zwischen kurzfristigen Zielen und langfristigem Erfolg usw. Zielkonflikte sind eine zentrale Friktion in heutigen Unternehmen.

***

Also: Eine schöne Idee, VSM und Scrum einmal zu vergleichen. Für mich ist jedoch noch nicht klar geworden, ob Scrum alles hat, was ein lebensfähiges System braucht. The jury is still out... ;-)