Warum ich es gewagt finde, Scrum zur Organisationsentwicklung einzusetzen

Wäh­rend aus der Soft­ware­ent­wick­lung kom­men­de so genann­te agi­le Coa­ches sich sys­te­mi­sches Wis­sen und Kön­nen aneig­nen, stür­zen sich sys­tem­theo­re­tisch geschul­te Orga­ni­sa­ti­ons­ent­wick­ler gera­de auf Scrum & Co. War­um irri­tiert mich das letzt­ge­nann­te Phä­no­men?

Seit Mit­te der 1990er Jah­re ken­ne ich agi­le Soft­ware­ent­wick­lungs­prin­zi­pi­en aus eige­ner Erfah­rung und ich möch­te behaup­ten, Agi­li­tät ist in mei­nem Blut. Mein Kon­takt zu sys­te­mi­schen und sys­tem­theo­re­ti­schen Ansät­zen ergab sich erst spä­ter. Aktu­ell beob­ach­te ich, dass vie­le sys­te­misch aus­ge­bil­de­te Orga­ni­sa­ti­ons­ent­wick­ler, die kei­ne Infor­ma­ti­ker sind, sich auf Scrum & Co stür­zen. Sie ver­su­chen, die­se Ansät­ze zu ver­ste­hen und suchen dar­in ein gewis­ses Heil für ihre Pro­fes­si­on. Und dabei fällt mir auf, dass ich als jemand, für den agi­le Soft­ware­ent­wick­lung nichts Neu­es ist, Scrum & Co kaum oder nur indi­rekt im Kon­text der Orga­ni­sa­ti­ons­ent­wick­lung ein­set­ze.

Die­ser Kon­trast wird mir gera­de deut­lich und ich fra­ge mich, ob ich dabei etwas über­se­he. Habe ich hier einen blin­den Fleck?

Produktentwicklung

Scrum ist eine Metho­de zur Pro­dukt­ent­wick­lung und es ent­hält durch­aus auch eini­ge typisch sys­te­mi­sche Ele­men­te, bspw. ein zyklisch‐reflektierendes Vor­ge­hen mit Hil­fe von Reviews, Retro­spek­ti­ven u.Ä. Die wich­tigs­ten Unter­schie­de und Gemein­sam­kei­ten sys­te­mi­scher und agi­ler Ansät­ze hat­te ich schon ein­mal im Blog­bei­trag “Unter­schie­de sys­te­misch zu agil” beschrie­ben.

Im Hin­blick dar­auf, die Anpas­sungs­fä­hig­keit einer Orga­ni­sa­ti­on zu erhö­hen, taugt Scrum mei­nes Erach­tens nur bedingt. Und das fin­de ich eben­so im Hin­blick dar­auf, die inne­re Kom­ple­xi­tät der Orga­ni­sa­ti­on zu stei­gern, um der exter­nen Kom­ple­xi­tät ange­mes­sen ent­ge­gen­tre­ten zu kön­nen.

In Scrum wer­den Pro­duk­t­ei­gen­schaf­ten in Form von Fea­tures und User Sto­ries prio­ri­siert. Dann wer­den die in einer Ite­ra­ti­on umsetz­ba­ren User Sto­ries inner­halb einer Ite­ra­ti­on umge­setzt und am Ende der Ite­ra­ti­on ent­spre­chend einer Fertig‐Definition abge­nom­men. Die Ite­ra­tio­nen sind typi­scher­wei­se 2 – 4 Wochen lang.

Die Umset­zung erfolgt vor allem durch Pro­gram­mie­rung, Design, auto­ma­ti­sier­te Test‐ und Build‐Prozesse u.a. Das Bear­bei­tungs­ob­jekt ist Soft­ware, wobei Scrum auch gut in der Hard­ware­ent­wick­lung funk­tio­niert. Es han­delt sich hier­bei um tech­ni­sche Pro­duk­te und Sys­te­me in einem weit­ge­hend kau­sa­len Kon­text. Die Test‐ und Build­pro­zes­se sind bspw. zuver­läs­sig repro­du­zier­bar und dadurch auto­ma­ti­sier­bar. Die her­ge­stell­ten Sys­te­me ver­hal­ten sich typi­scher­wei­se kau­sal, repro­du­zier­bar und bere­chen­bar.

Weni­ger vor­her­seh­bar ist der betei­lig­te Mensch. Scrum wur­de erfun­den und ein­ge­führt, um die Unbe­re­chen­bar­keit des Men­schen zu hand­ha­ben. Die Auf­trag­ge­ber und Benut­zer ken­nen zunächst ihre Anfor­de­run­gen an das Sys­tem nicht genug oder kön­nen die­se nicht klar genug beschrei­ben. Erst wäh­rend des Ent­wick­lungs­pro­zes­ses bekom­men die Men­schen aus­rei­chend Ein­sich­ten, Erkennt­nis­se und Ide­en, wie das her­zu­stel­len­de Sys­tem eigent­lich aus­se­hen soll­te, wel­che Anfor­de­run­gen es erfül­len soll­te und wel­che nicht.

Es ist ein her­an­tas­ten­der Pro­zess, die schritt­wei­se Annä­he­rung an ein beweg­li­ches Ziel, um die Krea­ti­vi­tät, Unsi­cher­heit und Unbe­re­chen­bar­keit der Anfor­de­rungs­ge­ber, Anwen­der und Auf­trag­ge­ber sys­te­ma­tisch in den Ent­wick­lungs­pro­zess inte­grie­ren zu kön­nen. Eben­so sich ver­än­dern­de Rah­men­be­din­gun­gen. Im Gegen­satz zum vor­her übli­chen Was­ser­fall­pro­zess (Pla­nen, Ent­wer­fen, Umset­zen, Tes­ten, Aus­lie­fern), der einen sta­bi­len Kon­text vor­aus­setz­te.

Natür­lich tre­ten auch beim Pro­gram­mie­ren immer mal wie­der Pro­ble­me auf, so dass die Her­stel­lung einer Pro­duk­t­ei­gen­schaft nicht in der Zeit gelingt, wie noch zwei Wochen vor­her gedacht. In die­sem Fall ermög­licht Scrum die Iden­ti­fi­ka­ti­on und Hand­ha­bung auch die­ser Phä­no­me­ne und sogar gewis­se Lern­ef­fek­te auf der Meta­ebe­ne.

Soft­ware sind hoch­kom­pli­zier­te Sys­te­me und wäh­rend der Pro­gram­mie­rung zei­gen sich auch durch­aus immer wie­der kom­ple­xe Phä­no­me­ne, das heißt, dass sich die ent­wi­ckel­ten Sys­te­me manch­mal unvor­her­seh­bar ver­hal­ten. Hier haben Pro­gram­mie­rer in den letz­ten zwei bis drei Jahr­zehn­ten viel getan, um die­se Phä­no­me­ne zu mini­mie­ren: Test‐Automatisierung, auto­ma­ti­sche und kon­ti­nu­ier­li­che Inte­gra­ti­on neu­er Ent­wick­lungs­ar­te­fak­te, Versions‐ und Kon­fi­gu­ra­ti­ons­ma­nage­ment, Modu­la­ri­sie­rungs­stra­te­gi­en (Objekt­ori­en­tie­rung, Micro­ser­vices, Feature‐Toggles etc.), Stan­dar­di­sie­run­gen (Schnitt­stel­len­pro­to­kol­le, Plugin‐Konzepte, Frame­works), mäch­ti­ge Sprach­ei­gen­schaf­ten (dyna­mi­sche Typi­sie­run­gen, Vir­tua­li­sie­run­gen), mäch­ti­ge Pro­gram­mier­werk­zeu­ge und vie­les mehr.

Was ich sagen möch­te: Die Bear­bei­tungs­ge­gen­stän­de (Soft­ware, Hard­ware) sind weit­ge­hend kau­sal. Die eigent­li­che Kom­ple­xi­tät bringt der Mensch. Auf der Ebe­ne der bear­bei­te­ten Arte­fak­te kön­nen wir rich­tig und falsch unter­schei­den: Wir unter­schei­den fer­tig und nicht fer­tig an Hand einer Defi­ni­ti­on von Fer­tig und Tests lau­fen oder lau­fen nicht.

Organisationsentwicklung

Das ist bei der Orga­ni­sa­ti­ons­ent­wick­lung anders: hier ist das Bear­bei­tungs­ob­jekt kein tech­ni­sches, son­dern ein sozia­les Sys­tem. Es geht um die Koope­ra­ti­ons­be­zie­hun­gen, -mög­lich­kei­ten und -fähig­kei­ten, die Aus­hand­lung von Rol­len und Zustän­dig­kei­ten und um Willensbildungs‐ und Ent­schei­dungs­pro­zes­se von Orga­ni­sa­ti­ons­mit­glie­dern.

Sozia­le Sys­te­me ver­hal­ten sich nicht kau­sal im Sin­ne eines sicher vor­her­seh­ba­ren oder repro­du­zier­ba­ren Ver­hal­tens. Die Unter­schei­dung von rich­tig und falsch ist weni­ger hilf­reich als eine kon­struk­ti­vis­ti­sche Hal­tung der Rea­li­täts­kon­struk­ti­on.

Des­we­gen fin­de ich es gewagt, Scrum zur Ent­wick­lung sozia­ler Sys­te­me ein­zu­set­zen.

Es wür­de uns wie­der in die Hal­tung füh­ren, orga­ni­sa­tio­na­le Ver­än­de­run­gen, also letzt­end­lich Ver­hal­tens­wei­sen von Men­schen “imple­men­tie­ren” zu wol­len. Wäre das mög­lich, wäre die Arbeit des Men­schen zu auto­ma­ti­sie­ren. Genau das pas­siert zwar ja auch, der Mensch muss immer weni­ger arbei­ten und sei­ne bis­he­ri­ge Arbeit kann von Maschi­nen über­nom­men wer­den. Aber dafür brau­chen wir dann kei­ne Orga­ni­sa­ti­ons­ent­wick­lung, son­dern Digi­ta­li­sie­rung, Auto­ma­ti­sie­rung, Robo­ti­sie­rung, KI und Ver­gleich­ba­res.

Solan­ge Orga­ni­sa­tio­nen für uns sozia­le Sys­te­me sind, die aus (mensch­li­chen) Kom­mu­ni­ka­tio­nen bestehen und wir unter Orga­ni­sa­ti­ons­ent­wick­lung ent­spre­chend die Ent­wick­lung mensch­li­cher Kom­mu­ni­ka­tio­nen in sozia­len Sys­te­men ver­ste­hen (und das im Kon­text von KI zu hin­ter­fra­gen, wäre ein ande­ren The­ma), ist der Ter­mi­nus “imple­men­tie­ren” unpas­send.

Imple­men­tie­ren bezeich­net den Ein­bau oder die Umset­zung von spe­zi­fi­zier­ten und vor­ge­ge­be­nen Struk­tu­ren und Prozess­abläufen in einem Sys­tem. Es ist ein auf Kau­sa­li­tät basie­ren­der Vor­gang. Für kom­ple­xe sozia­le Sys­te­me und ihrer Ver­än­de­rung ist der Begriff “imple­men­tie­ren” des­we­gen irre­füh­rend. Das Entwicklungs‐ bzw. Imple­men­tie­rungs­team steht aber im Mit­tel­punkt von Scrum.

Was ist die Wertschöpfung?

Ein wei­te­rer Vor­be­halt betrifft die Unter­schei­dung von Füh­rungs­ar­beit und ope­ra­ti­ver Arbeit. Im Kon­text von Scrum liegt der Fokus auf der Maxi­mie­rung der Wert­schöp­fung, also der ope­ra­ti­ven Arbeit. Füh­rungs­ar­beit ist, wie auch sonst, nur ein klei­ner Teil der Arbeit und beschränkt sich vor allem auf Sprint‐Planung, täg­li­che Ste­hun­gen, Review und Retro­spek­ti­ve. Der weit­aus größ­te Anteil an der Arbeit der Betei­lig­ten dient der direk­ten Wert­schöp­fung, also der Her­stel­lung eines Pro­duk­tes. Füh­rung ist immer nur Mit­tel zum Zweck und daher typi­scher­wei­se der klei­ne­re und zu mini­mie­ren­de Teil der Arbeit.

Scrum ist ein Sys­tem, dass die Leis­tungs­fä­hig­keit der Ent­wick­ler aus­ba­lan­ciert und mit dem die vor­han­de­ne Ent­wick­lungs­ka­pa­zi­tät opti­mal genutzt wer­den soll. Wenn mit Hil­fe von Scrum nun jedoch indi­rek­te Wert­schöp­fung pro­zes­siert wird, also Orga­ni­sa­ti­ons­ent­wick­lung zum Pro­dukt bzw. Zweck wird, kann das sogar kon­tra­pro­duk­tiv gegen­über der eigent­li­chen Wert­schöp­fung und dem eigent­li­chen Zweck der Orga­ni­sa­ti­on wir­ken.

Fazit

Ich fin­de es sinn­voll, wenn sich sys­te­mi­sche Orga­ni­sa­ti­ons­ent­wick­ler mit agi­len Soft­ware­ent­wick­lungs­me­tho­den beschäf­ti­gen und sie ver­ste­hen ler­nen. Der Nut­zen liegt jedoch nicht dar­in, Metho­den wie Scrum, Software‐Kanban, LeSS (Large‐Scale Scrum), SAFe (Sca­led Agi­le Frame­work) etc. kom­plett zu über­neh­men. Viel­mehr hal­te ich es für not­wen­dig, die ein­zel­nen Grund­prin­zi­pi­en und Ele­men­te zu ver­in­ner­li­chen und für den Kon­text der Orga­ni­sa­ti­ons­ent­wick­lung zu adap­tie­ren. Regel­mä­ßi­ge Prio­ri­sie­run­gen, empi­ri­sches Vor­ge­hen, Rol­len­klar­heit, inter­dis­zi­pli­nä­re Wert­schöp­fung, Time­boxing, visu­el­le Pla­nung etc. sind auch außer­halb von Soft­ware­ent­wick­lung sinn­voll.

Scrum auf die Orga­ni­sa­ti­ons­ent­wick­lung anzu­wen­den, hal­te ich für die fal­sche Her­aus­for­de­rung. Sinn­vol­ler fän­de ich, ein agi­les Grund­prin­zip wie bei­spiels­wei­se das Sog­prin­zip (Pull‐Prinzip) für die Orga­ni­sa­ti­ons­ent­wick­lung zu adap­tie­ren und die­sen Trans­fer als rele­van­te Her­aus­for­de­rung zu begrei­fen.

Und bei alle­dem soll­te uns bewusst sein, dass die­se Ele­men­te allei­ne nicht hin­rei­chend sind. Wohin ein zu ein­sei­ti­ger Fokus auf die Über­nah­me der rei­nen Vor­ge­hens­me­cha­nik führt, lässt sich mei­nes Erach­tens schon in der Dif­fe­renz von Sozio­kra­tie und der dar­aus abge­lei­te­ten Holok­ra­tie erken­nen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.