SCRUM und das Viable System Model


bildschirmfoto-2016-10-10-um-23-43-22

Kurze Nachlese zur Metaphorum Konferenz 2016

Im Nachgang zur Metaphorum Konferenz hier die Folien meines Vortrags zum Thema SCRUM und das Viable System Model. Hierbei habe ich die Gedanken und Anmerkungen von Ralf und Frank bzgl. des seinerzeitigen Online-Experiments intensiv reflektiert.

Soviel vorab: Einige Ideen haben mich in der weiteren Analyse und Ausarbeitung beeinflusst, andere Impulse habe ich bewusst und sehenden Auges nicht aufgegriffen. 🙂

Zusammenfassung & Ergänzungen

Hier meine Anmerkungen, welche sich komplementär zu den ersten Erkenntnissen aus dem Experiment heraus ergeben haben:

Zur Methodik & Parallelität der SCRUM-Rollen im VSM

Der Ansatz einer zeitbasierten, prozessualen Untersuchung wurde von der kritischen Teilnehmerschaft der Konferenz positiv aufgenommen. Gleichermaßen stellte es für die “VSM-Experten” kein Problem dar, die Parallelität der verschiedenen SCRUM-Rollen in den verschiedenen Systemen nachzuvollziehen. Als Beispiel noch mal nachgeschoben: Auch wir als Menschen sind offensichtlich lebensfähige Systeme und haben dauernd parallel mit den Herausforderungen des “Klarkommens im hier und jetzt” und den “Chancen und Risiken der Zukunft” zu tun. Wir sind nie ausschließlich in einem Modus unterwegs. Daher habe ich im Vortrag auch darauf hingewiesen, dass die dargestellte Parallelität der statischen Darstellung geschuldet ist. Eigentlich müsste man sich die Visualisierung als permanentes Überblenden vorstellen.

Ich möchte sogar so weit gehen und behaupten, dass durch diese Analyse erst deutlich wird, welche in der Tat großen Aufgaben SCRUM Teams zu bewältigen haben. Man könnte nun trefflich darüber streiten, ob SCRUM dann überhaupt noch Sinn macht, weil es die Komplexität scheinbar steigert. Aus persönlicher Beobachtung heraus erscheint mir aber genau das Gegenteil der Fall zu sein: Kybernetisch formuliert – die Requisite Variety wird erhöht.

Keine eierlegende Wollmilchsau

Ebenso kam ich nicht umhin darauf hinzuweisen, dass SCRUM natürlich kein Allheilmittel ist. Weder für die Software-Entwicklung, noch für sonstige Wissensarbeit. Für SCRUM gilt das Gleiche was Stafford Beer über das VSM gesagt hat: Es ist ein Werkzeug, d.h. es ist mehr oder weniger nützlich, aber niemals die “Wahrheit”. Nur in bestimmten Arbeits- und Wertschöpfungs-Kontexten kann “SCRUM by the Book” m.E. überhaupt seine Potenziale entfalten. Platt formuliert: Je inkrementeller der Wertschöpfungsprozess, desto wahrscheinlicher das SCRUM nützlich sein kann.

Konsent ist King

Des weiteren habe ich von meinen persönlichen Erfahrungen berichtet, in denen ich SCRUM scheitern sah. Denn es macht – freundlich formuliert – überhaupt keinen Sinn eine Methode einem Team “einfach so” überzustülpen. Wenn es innerhalb des Teams kein Übereinkommen (im Sinne eines Konsent) hinsichtlich des Einsatzes von SCRUM gibt, dann wird es schlichtweg nicht funktionieren. Wie auch? Besonders in diesem Kontext gilt das Commitment, welches als Wert im Prozess Guide erwähnt wird, zuvorderst dem Vorgehensmodell selbst. Wenn man das nicht kann oder will, dann macht SCRUM auch keinen Sinn. Und auch dieses berühmte Commitment muss hinsichtlich seiner Bedeutung und Tragweite reflektiert werden, denn zurecht entsteht unnötig Leid durch ein unterkomplexes Verständnis von Begriffen wir “Versprechen”, “Planung” und “Aufgabe erledigt”.  Wichtig ist mir zu betonen: Ich meine das alles völlig wertfrei. Ich finde niemanden automatisch toll, weil er SCRUM benutzt und genauso wenig finde ich Leute doof, die SCRUM nicht gut finden.

Personal Mastery

Es erscheint mir ohnehin eine Binsenweisheit zu sein, dass jede Methodik nur so authentisch realisiert werden kann wie es den einzelnen Mitgliedern der Gruppe gelingt, den jeweiligen Zweck des Instruments durch individuelle Reflexion zu integrieren. Gelingt das nicht, bleibt’s immer ein Kratzen an der Oberfläche. Es braucht in der Gruppe eine kritische Masse von “innerer Bereitschaft”, damit sich eine Methodik überhaupt stabil etablieren kann. Das kann man nicht befehlen und liebes Wünschen genügt da m.E. auch nicht. Da spielt es auch keine Rolle, ob wir über SCRUM oder Soziokratie parlieren – ohne Haltung geht es nicht.

Was es aufgrund meiner Beobachtung braucht sind Menschen, welche eine “gewisse” Ebene der “Personal Mastery” erreicht haben. Dies bezieht sich für mich auf sehr persönliche, Reflexionen und die daraus resultierenden sozialen Fähigkeiten. Die folgende Phrase fasst es vielleicht ganz gut zusammen: It’s not about ‘being’ but ‘becoming’.

SCRUM erscheint mir somit wie ein Aufmerksamkeits-Lenkungs-Tool zu wirken. Wenn die o.g. Bedingungen gegeben sind, dann etablieren sich Rituale einer lernenden Organisation. Ich schaue daher auf SCRUM wie auf ein Spiel mit klaren Rollen, Regeln und Belohnungen. Das ist für mich auch nicht die heilige Schrift – ich habe es schon von jeher geliebt, bestehende Regeln zu modifizieren. Hauptsache “es” funktioniert.

Break it, fix it, adapt it

Somit sehe ich auch kein Problem darin von SCRUM abzuweichen – solange dies bewusst geschieht und für die dann resultierenden Lücken entsprechende Lösungen gefunden und erfolgreich eingesetzt werden. Mir ging es in dieser Untersuchung zu keiner Zeit darum ein quasi-dogmatisches Vorgehen zu fordern, geschweige denn zu fördern. Es viele verschiedene Ansätze (“work hacks”) die miteinander kombiniert werden können – ich glaube eh nicht an Patentrezepte. In der täglichen Praxis besteht die Kunst darin weder zu statisch, noch zu dynamisch zu werden wenn es darum geht, ein Ziel zu erreichen. Die Parallelitäten bzw. scheinbare Paradoxien lassen einen auch hier wieder nicht los.

Enterprise SCRUM

Im Experiment habe ich mich zunächst auf die Rekursionsebene “Team” konzentriert, da SCRUM für diesen Rahmen erdacht wurde. Hierfür wurde ich kritisiert, muss aber klarstellen, dass ich den Aspekt der Umwelt (also Unternehmen), in das das Team eingebettet ist bewusst nicht betrachtet habe. Es ging im ersten Schritt darum erstmal zu verifizieren, ob der prozessuale Ansatz des VSM-Mappings funktioniert.

Die weitere Reflexion und Beobachtung hat ergeben, dass Enterprise SCRUM durchaus ein vernünftiger Ansatz sein kann wenn:

Die wertschöpfenden Teams miteinander synchronisiert werden. Es ist nicht unwahrscheinlich, dass es im Rahmen eines “SCRUM of SCRUM” Übergabepunkte gibt, bei denen Teilergebnisse im Rahmen einer Prozesskette von einem Team zum anderen weitergereicht werden. Das bedeutet das dann die Geschäftsführung auch tatsächlich ihr Commitment zum resultierenden Arbeitsrhythmus geben muss und nicht durch eigene Interventionen die Methodik konterkariert – frei nach dem Motto “eat your own dog food”. In diesem Zusammenhang bieten die Prinzipien und Axiome des Managements von Stafford noch weitere Erkenntnisse, deren Ausführung aber jetzt den Rahmen des Textes sprengen würden.

Wichtig: Die Unterstützer der Wertschöpfung (Marketing, Vertrieb, HR, …) müssen dann ebenso mit diesem Takt/Pulsschlag umgehen können. Jedoch erscheint mir ein reines SCRUM z.B. in der Buchhaltung Quatsch zu sein. Für diese Art von Aufgaben bietet sich vielmehr Kanban in Kombination mit weiteren agilen Work Hacks an.

Fazit & Ausblick

Ich hoffe das es mir trotz des Abstraktionsgrads gelungen ist, eine differenzierte Sichtweise auf die Methodik und die resultierenden Ergebnisse zu vermitteln. Im nächsten Verlauf werde ich weitere Frameworks untersuchen und ihre Lebensfähigkeit im Sinne des VSM analysieren.

 


2 responses to “SCRUM und das Viable System Model”

  1. Vielen Dank für das interessante Experiment. Auch in meinen Augen hätte die Umwelt mit einbezogen werden müssen. Meine Kommentar soll aber keine Kritik sondern vielmehr Anregung sein. Die Idee, das VSM auf Softwareentwicklung anzuwenden finde ich super. Ich bin gespannt auf weitere Überlegungen.

    Es gibt erfolgreiche Softwareentwicklung mit Scrum. Allein aus diesem Grund ist Scrum per Definition lebensfähig. Andernfalls würde die Entwicklung nach Scrum niemals zu einem sinnvollen Ergebnis führen.

    Lebensfähigkeit steht aber immer im Kontext zu einem Lebensraum und kann nicht losgelöst von diesem betrachtet werden. So ist ein Fisch im Lebensraum Wasser lebensfähig, nicht jedoch in der Wüste. Da Lebensräume einer permanenten Veränderung unterliegen ist die Anpassungsfähigkeit ein wichtiges Kriterium der Lebensfähigkeit. Mit einem moderaten Algenwachstum mag ein Fisch leben können. Eine Austrocknen würde weder das Individuum noch die Art überstehen. Die Beurteilung der Lebensfähigkeit kann deshalb nur im Kontext zur Umwelt erfolgen.

    Bezieht man die Umwelt in die Frage der Lebensfähigkeit von Scrum mit ein, komme ich zu dem Schluss, dass es um die Lebensfähigkeit nicht ganz so gut bestellt ist. Zweifellos gibt es Situationen für die Scrum hervorragend geeignet ist und gute Ergebnisse liefert. Allerdings sind das weit weniger Situationen als die große Verbreitung vermuten lässt. Mit dem Einzug von Scrum in ein Unternehmen kommt auch häufig die Forderung auf, dass sich das Unternehmen, bzw. Kunden an die geänderte Arbeitsweise anpassen müssen. Erst recht, wenn es die ersten Schwierigkeiten gibt. Dies stellt das Prinzip der Lebensfähigkeit auf den Kopf. Nicht die Umwelt muss sich an das System anpassen, sondern umgekehrt. Diese Forderung ist ein Indiz dafür, dass Scrum nur in einer künstlichen Umwelt lebensfähig ist.

    Bei weiterer Betrachtung wird man sehr schnell Situationen finden, in denen das reine Scrum keine Operationen für Umwelteinflüsse bereithält. Zum Beispiel, wenn eine Reaktionszeit von unter einer Sprintlänge benötigt wird. Bei diesem Argument wird oft entgegnet, dass dies nicht vorkommen darf. Es kommt aber vor und bei der Lösung dieses Problems dürfen Gründe keine Rolle spielen! Regelkreise müssen unabhängig von der Ursache einer Störung reagieren können. Dies gilt auch für Regelkreise in sozialen Systemen.

  2. Hi Gunter, lieben Dank für das Feedback! Es spornt mich im besten Sinne dazu an in einer weiteren Runde das Thema Umwelt et. al. zu sezieren. 🙂 SAFe erscheint mir im Zusammenhang “Umwelt” durchaus probat um ein SCRUM of SCRUMs zu steuern. Auf jeden Fall braucht’s eine passende Umwelt – keine Frage!

    Zwei Aspekte wollte ich kurz aufgreifen:

    1. Ich kenne ja genau die o.g. Probleme und kann Deinen Eindruck nur bestätigen. Das erinnert mich auch an die 60-70% der sog. Change Management-Projekte, die kläglich scheitern. Denn SCRUM ist – wie jede Methode – eine Frage der Haltung, des Mindset, geltenden Paradigmas, you name it. Es gelingt daher auch nur selten.

    2. Erfahrene SCRUM-Teams wissen das es Umwelteinflüsse gibt, welche eine Reaktionszeit erfordern die unter einer Sprint-Länge liegen (Critical Bugs, Hot fixes, etc.). Das “reine” SCRUM kann es m.E. nicht geben – und das ist IMHO auch gut so, denn die Viabilität ist wichtiger als das beharren auf irgendeinem Tool. Insofern gilt für mich: kontextuelles Cherry Picking 😉

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.