Warum ich es gewagt finde, Scrum zur Organisationsentwicklung einzusetzen
Während aus der Softwareentwicklung kommende so genannte agile Coaches sich systemisches Wissen und Können aneignen, stürzen sich systemtheoretisch geschulte Organisationsentwickler gerade auf Scrum & Co. Warum irritiert mich das letztgenannte Phänomen?
Seit Mitte der 1990er Jahre kenne ich agile Softwareentwicklungsprinzipien aus eigener Erfahrung und ich möchte behaupten, Agilität ist in meinem Blut. Mein Kontakt zu systemischen und systemtheoretischen Ansätzen ergab sich erst später. Aktuell beobachte ich, dass viele systemisch ausgebildete Organisationsentwickler, die keine Informatiker sind, sich auf Scrum & Co stürzen. Sie versuchen, diese Ansätze zu verstehen und suchen darin ein gewisses Heil für ihre Profession. Und dabei fällt mir auf, dass ich als jemand, für den agile Softwareentwicklung nichts Neues ist, Scrum & Co kaum oder nur indirekt im Kontext der Organisationsentwicklung einsetze.
Dieser Kontrast wird mir gerade deutlich und ich frage mich, ob ich dabei etwas übersehe. Habe ich hier einen blinden Fleck?
Produktentwicklung
Scrum ist eine Methode zur Produktentwicklung und es enthält durchaus auch einige typisch systemische Elemente, bspw. ein zyklisch-reflektierendes Vorgehen mit Hilfe von Reviews, Retrospektiven u.Ä. Die wichtigsten Unterschiede und Gemeinsamkeiten systemischer und agiler Ansätze hatte ich schon einmal im Blogbeitrag “Unterschiede systemisch zu agil” beschrieben.
Im Hinblick darauf, die Anpassungsfähigkeit einer Organisation zu erhöhen, taugt Scrum meines Erachtens nur bedingt. Und das finde ich ebenso im Hinblick darauf, die innere Komplexität der Organisation zu steigern, um der externen Komplexität angemessen entgegentreten zu können.
In Scrum werden Produkteigenschaften in Form von Features und User Stories priorisiert. Dann werden die in einer Iteration umsetzbaren User Stories innerhalb einer Iteration umgesetzt und am Ende der Iteration entsprechend einer Fertig-Definition abgenommen. Die Iterationen sind typischerweise 2 – 4 Wochen lang.
Die Umsetzung erfolgt vor allem durch Programmierung, Design, automatisierte Test- und Build-Prozesse u.a. Das Bearbeitungsobjekt ist Software, wobei Scrum auch gut in der Hardwareentwicklung funktioniert. Es handelt sich hierbei um technische Produkte und Systeme in einem weitgehend kausalen Kontext. Die Test- und Buildprozesse sind bspw. zuverlässig reproduzierbar und dadurch automatisierbar. Die hergestellten Systeme verhalten sich typischerweise kausal, reproduzierbar und berechenbar.
Weniger vorhersehbar ist der beteiligte Mensch. Scrum wurde erfunden und eingeführt, um die Unberechenbarkeit des Menschen zu handhaben. Die Auftraggeber und Benutzer kennen zunächst ihre Anforderungen an das System nicht genug oder können diese nicht klar genug beschreiben. Erst während des Entwicklungsprozesses bekommen die Menschen ausreichend Einsichten, Erkenntnisse und Ideen, wie das herzustellende System eigentlich aussehen sollte, welche Anforderungen es erfüllen sollte und welche nicht.
Es ist ein herantastender Prozess, die schrittweise Annäherung an ein bewegliches Ziel, um die Kreativität, Unsicherheit und Unberechenbarkeit der Anforderungsgeber, Anwender und Auftraggeber systematisch in den Entwicklungsprozess integrieren zu können. Ebenso sich verändernde Rahmenbedingungen. Im Gegensatz zum vorher üblichen Wasserfallprozess (Planen, Entwerfen, Umsetzen, Testen, Ausliefern), der einen stabilen Kontext voraussetzte.
Natürlich treten auch beim Programmieren immer mal wieder Probleme auf, so dass die Herstellung einer Produkteigenschaft nicht in der Zeit gelingt, wie noch zwei Wochen vorher gedacht. In diesem Fall ermöglicht Scrum die Identifikation und Handhabung auch dieser Phänomene und sogar gewisse Lerneffekte auf der Metaebene.
Software sind hochkomplizierte Systeme und während der Programmierung zeigen sich auch durchaus immer wieder komplexe Phänomene, das heißt, dass sich die entwickelten Systeme manchmal unvorhersehbar verhalten. Hier haben Programmierer in den letzten zwei bis drei Jahrzehnten viel getan, um diese Phänomene zu minimieren: Test-Automatisierung, automatische und kontinuierliche Integration neuer Entwicklungsartefakte, Versions- und Konfigurationsmanagement, Modularisierungsstrategien (Objektorientierung, Microservices, Feature-Toggles etc.), Standardisierungen (Schnittstellenprotokolle, Plugin-Konzepte, Frameworks), mächtige Spracheigenschaften (dynamische Typisierungen, Virtualisierungen), mächtige Programmierwerkzeuge und vieles mehr.
Was ich sagen möchte: Die Bearbeitungsgegenstände (Software, Hardware) sind weitgehend kausal. Die eigentliche Komplexität bringt der Mensch. Auf der Ebene der bearbeiteten Artefakte können wir richtig und falsch unterscheiden: Wir unterscheiden fertig und nicht fertig an Hand einer Definition von Fertig und Tests laufen oder laufen nicht.
Organisationsentwicklung
Das ist bei der Organisationsentwicklung anders: hier ist das Bearbeitungsobjekt kein technisches, sondern ein soziales System. Es geht um die Kooperationsbeziehungen, ‑möglichkeiten und ‑fähigkeiten, die Aushandlung von Rollen und Zuständigkeiten und um Willensbildungs- und Entscheidungsprozesse von Organisationsmitgliedern.
Soziale Systeme verhalten sich nicht kausal im Sinne eines sicher vorhersehbaren oder reproduzierbaren Verhaltens. Die Unterscheidung von richtig und falsch ist weniger hilfreich als eine konstruktivistische Haltung der Realitätskonstruktion.
Deswegen finde ich es gewagt, Scrum zur Entwicklung sozialer Systeme einzusetzen.
Es würde uns wieder in die Haltung führen, organisationale Veränderungen, also letztendlich Verhaltensweisen von Menschen “implementieren” zu wollen. Wäre das möglich, wäre die Arbeit des Menschen zu automatisieren. Genau das passiert zwar ja auch, der Mensch muss immer weniger arbeiten und seine bisherige Arbeit kann von Maschinen übernommen werden. Aber dafür brauchen wir dann keine Organisationsentwicklung, sondern Digitalisierung, Automatisierung, Robotisierung, KI und Vergleichbares.
Solange Organisationen für uns soziale Systeme sind, die aus (menschlichen) Kommunikationen bestehen und wir unter Organisationsentwicklung entsprechend die Entwicklung menschlicher Kommunikationen in sozialen Systemen verstehen (und das im Kontext von KI zu hinterfragen, wäre ein anderen Thema), ist der Terminus “implementieren” unpassend.
Implementieren bezeichnet den Einbau oder die Umsetzung von spezifizierten und vorgegebenen Strukturen und Prozessabläufen in einem System. Es ist ein auf Kausalität basierender Vorgang. Für komplexe soziale Systeme und ihrer Veränderung ist der Begriff “implementieren” deswegen irreführend. Das Entwicklungs- bzw. Implementierungsteam steht aber im Mittelpunkt von Scrum.
Was ist die Wertschöpfung?
Ein weiterer Vorbehalt betrifft die Unterscheidung von Führungsarbeit und operativer Arbeit. Im Kontext von Scrum liegt der Fokus auf der Maximierung der Wertschöpfung, also der operativen Arbeit. Führungsarbeit ist, wie auch sonst, nur ein kleiner Teil der Arbeit und beschränkt sich vor allem auf Sprint-Planung, tägliche Stehungen, Review und Retrospektive. Der weitaus größte Anteil an der Arbeit der Beteiligten dient der direkten Wertschöpfung, also der Herstellung eines Produktes. Führung ist immer nur Mittel zum Zweck und daher typischerweise der kleinere und zu minimierende Teil der Arbeit.
Scrum ist ein System, dass die Leistungsfähigkeit der Entwickler ausbalanciert und mit dem die vorhandene Entwicklungskapazität optimal genutzt werden soll. Wenn mit Hilfe von Scrum nun jedoch indirekte Wertschöpfung prozessiert wird, also Organisationsentwicklung zum Produkt bzw. Zweck wird, kann das sogar kontraproduktiv gegenüber der eigentlichen Wertschöpfung und dem eigentlichen Zweck der Organisation wirken.
Fazit
Ich finde es sinnvoll, wenn sich systemische Organisationsentwickler mit agilen Softwareentwicklungsmethoden beschäftigen und sie verstehen lernen. Der Nutzen liegt jedoch nicht darin, Methoden wie Scrum, Software-Kanban, LeSS (Large-Scale Scrum), SAFe (Scaled Agile Framework) etc. komplett zu übernehmen. Vielmehr halte ich es für notwendig, die einzelnen Grundprinzipien und Elemente zu verinnerlichen und für den Kontext der Organisationsentwicklung zu adaptieren. Regelmäßige Priorisierungen, empirisches Vorgehen, Rollenklarheit, interdisziplinäre Wertschöpfung, Timeboxing, visuelle Planung etc. sind auch außerhalb von Softwareentwicklung sinnvoll.
Scrum auf die Organisationsentwicklung anzuwenden, halte ich für die falsche Herausforderung. Sinnvoller fände ich, ein agiles Grundprinzip wie beispielsweise das Sogprinzip (Pull-Prinzip) für die Organisationsentwicklung zu adaptieren und diesen Transfer als relevante Herausforderung zu begreifen.
Und bei alledem sollte uns bewusst sein, dass diese Elemente alleine nicht hinreichend sind. Wohin ein zu einseitiger Fokus auf die Übernahme der reinen Vorgehensmechanik führt, lässt sich meines Erachtens schon in der Differenz von Soziokratie und der daraus abgeleiteten Holokratie erkennen.