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.