Unterschiede systemisch zu agil

Orga­ni­sa­tio­nen aller Art wol­len, sol­len oder müs­sen jetzt agil wer­den. Inso­fern ist das The­ma Agi­li­tät auch für die Orga­ni­sa­ti­ons­ent­wick­lung rele­vant. Die­se ist wie­der­um klas­si­scher­wei­se sys­te­misch geprägt. Zwi­schen sys­te­mi­schen und agi­len Ansät­zen gibt es vie­le Ähn­lich­kei­ten und auch eini­ge Unter­schie­de. Wo wider­spre­chen oder ergän­zen sich die Ansät­ze? Wo bie­ten sie kom­ple­men­tä­re Sicht­wei­sen und Ideen? In die­sem Bei­trag gebe ich hier­zu einen ers­ten und sicher­lich unvoll­stän­di­gen Überblick.

Die Ursprün­ge und his­to­ri­schen Zusam­men­hän­ge der ver­schie­de­nen Ansät­ze hat­te ich bereits in einem frü­he­ren Blog­bei­trag dar­ge­stellt: Agil, sozio­kra­tisch, holok­ra­tisch, teal, sys­te­misch etc. – eine klei­ne Ori­en­tie­rung.

Da es nicht den sys­te­mi­schen und agi­len Ansatz schlecht­hin gibt, son­dern dies Con­tai­ner­be­grif­fe für jeweils ganz unter­schied­li­che Ideen, Theo­rien, Model­le, Prak­ti­ken und Prin­zi­pi­en sind, ist die Unter­schei­dung sys­te­misch zu agil an sich bereits gewagt. Trotz­dem: Wir kön­nen aus der Unter­schei­dung ler­nen und Anre­gun­gen und Ideen für unser bera­te­ri­sches Han­deln gewinnen.

Ohne eine beson­de­re Rei­hen­fol­ge stel­le ich nach­fol­gend wich­ti­ge Unter­schie­de und Zusam­men­hänbge dar.

Sogprinzip (Pull)

Agi­le Metho­den wie Scrum, Kan­ban oder agi­les Pro­jekt­ma­nage­ment (APM) basie­ren auf dem Sogprinzip.

In Kan­ban ist es das zen­tra­le Prin­zip, dass der Arbeits­fluss vom Ende zum Anfang betrach­tet wird. Wur­de in einem Arbeits­schritt die Arbeit erle­digt und besteht wie­der Kapa­zi­tät für neue Arbeit, dann wird geprüft, ob neue Arbeit vom vor­he­ri­gen Schritt über­nom­men wer­den kann. Inner­halb des Arbeits­flus­ses wird die Arbeit jeweils vom Vor­gän­ger­schritt gezogen.

Auch in Scrum ist die­ses Prin­zip zu fin­den. Hier arbei­tet das Ent­wick­ler­team ite­ra­tiv, bei­spiels­wei­se in zwei­wö­chi­gen Zeit­blö­cken. Zum Start eines neu­en Zeit­blo­ckes über­nimmt das Ent­wick­ler­team so vie­le neue Anfor­de­run­gen aus einer prio­ri­sier­ten Anfor­de­rungs­lis­te, wie das Team inner­halb des Zeit­blo­ckes meint, abschlie­ßen zu kön­nen. Auch hier zieht es sich Arbeit. Außer­halb des Teams kön­nen die Prio­ri­tä­ten der Anfor­de­run­gen bestimmt und vor­ge­ge­ben wer­den, aber das Ent­wick­lungs­team bestimmt, wel­che es sinn­vol­ler­wei­se über­neh­men kann.

In der sys­te­mi­schen Orga­ni­sa­ti­ons­ent­wick­lung fin­den wir hier­zu kei­ne ver­gleich­ba­re Prak­tik. Ganz im Gegen­teil, wer­den Ver­än­de­run­gen meis­tens als ziel­ge­rich­te­te Pro­jek­te orga­ni­siert, in denen Auf­trag­ge­ber und Pro­jekt­lei­tung bestim­men, wann wel­che Maß­nah­men und Inter­ven­tio­nen gestar­tet wer­den. Sie wer­den den betei­lig­ten Mit­ar­bei­tern vor­ge­ge­ben und nicht von die­sen gezogen.

Die Umstel­lung von Push zu Pull  in der agi­len Orga­ni­sa­ti­ons­ent­wick­lung hat gra­vie­ren­de Kon­se­quen­zen. Das Tem­po der Ver­än­de­rung und (nicht zwin­gend aber) mög­li­cher­wei­se auch Rei­hen­fol­ge der Inter­ven­tio­nen (bzw. Expe­ri­men­te) gehen von den Ver­än­de­rungs­be­trof­fe­nen aus, nicht von den Ver­än­de­rungs­be­ra­tern, ‑beglei­tern, ‑ver­ant­wort­li­chen oder deren Führungskräften.

Konstruktivismus und Multiperspektivität

Ein ele­men­ta­res sys­te­mi­sches Prin­zip ist der Kon­struk­ti­vis­mus, also die Annah­me, dass es nicht die eine uni­ver­sel­le wah­re Rea­li­tät gibt, son­dern jedes Indi­vi­du­um sich sei­ne eige­ne Rea­li­tät kon­stru­iert. Jeder Mensch hat sei­ne eige­ne Per­spek­ti­ve auf die Welt. Die­ser Idee fol­gend tre­ten die Unter­schei­dun­gen rich­tig und falsch oder wahr und unwahr in Bezug auf unse­re Beob­ach­tun­gen zurück hin­ter der Akzep­tanz, dass vie­le ver­schie­de­ne Wahr­hei­ten gleich­zei­tig existieren.

Inner­halb geschlos­se­ner Theo­rien sind Richtig-Falsch-Unterscheidungen rele­vant, bei­spiels­wei­se bei der Fra­ge, wie ob 3 * 3 = 9 ist. In der Beob­ach­tung von Ver­hal­ten, bei­spiels­wei­se wer in einem Streit Recht oder Schuld hat, hel­fen uns statt­des­sen ganz ande­re Fra­gen weiter.

Agi­le Metho­den sind in die­sem Sin­ne nicht kon­struk­ti­vis­tisch. Es fin­den Beur­tei­lun­gen bei­spiels­wei­se zum Fer­tig­stel­lungs­stand mit einer ein­heit­li­chen Defi­ni­ti­on von Fer­tig statt, was ist die­sem Kon­text auch sinn­voll ist. In den regel­mä­ßi­gen Retro­spek­ti­ven wird über die bis­he­ri­ge eige­ne Arbeit und Kom­mu­ni­ka­ti­on reflek­tiert und ein Scrum-Master oder Coach mit einer sys­te­mi­schen Hal­tung wür­de ver­mut­lich die Idee des Kon­struk­ti­vis­mus berück­sich­ti­gen – expli­zi­ter Bestand­teil von Scrum ist dies nicht. Im Gegen­teil, die übli­che Scrum-Master-Ausbildung ist im Ver­gleich zu einer sys­te­misch gepräg­ten Coaching-Ausbildung äußerst rudimentär.

Eine kon­struk­ti­vis­ti­sche Hal­tung ist jedoch für die Orga­ni­sa­ti­ons­ent­wick­lung rele­vant. Die Beschrän­kung auf eine gemein­sa­me Rea­li­täts­kon­struk­ti­on ist eine wenig hilf­rei­che Ver­ein­fa­chung im Kon­text eines kom­ple­xen Sys­tems. Es wer­den in spe­ku­la­ti­ver Wei­se Kau­sa­li­tä­ten unter­stellt. Wesent­lich sinn­vol­ler ist der sys­te­mi­sche Ansatz, bei dem ver­schie­de­nen mög­li­chen Rea­li­täts­kon­struk­tio­nen in Form von Hypo­the­sen auf­ge­nom­men wer­den. Deren Wahr­schein­lich­keit kann gemein­sam gewich­tet wer­den, so dass die wei­te­re Orga­ni­sa­ti­ons­ent­wick­lung auf der bewuss­ten Ent­schei­dung für eine oder zumin­dest eini­ge weni­ge mög­li­che Rea­li­täts­kon­struk­tio­nen basiert.

Auf Basis ver­schie­de­ner Hypo­the­sen wer­den nor­ma­ler­wei­se ganz unter­schied­li­che Inter­ven­tio­nen und Orga­ni­sa­ti­ons­ex­pe­ri­men­te erfun­den und aus­ge­wählt. Des­we­gen soll­ten die ver­wen­de­ten Hypo­the­sen bewusst aus­ge­wählt wer­den und nicht allei­ne dem Zufall grup­pen­dy­na­mi­scher Pro­zes­se über­las­sen werden.

Serendipität

Metho­den wie Design Thin­king und Lean Start­up pro­vo­zie­ren unge­woll­te Erfin­dun­gen. Der Fach­be­griff hier­für lau­tet Seren­di­pi­tät (eng­lisch seren­di­pi­ty) und bezeich­net eine zufäl­li­ge Beob­ach­tung von etwas ursprüng­lich nicht Gesuch­tem, das sich als neue und über­ra­schen­de Ent­de­ckung erweist. Bekann­te Bei­spie­le sind die Ent­de­ckung Ame­ri­kas 1492 oder das Post-it (selbst­haf­ten­de Zettel).

Obwohl die sys­te­mi­sche Orga­ni­sa­ti­ons­ent­wick­lung auf kau­sa­le Annah­men ver­zich­tet und damit für ver­schie­dens­te Beob­ach­tun­gen offen ist, ent­hält sie kei­ne unmit­tel­ba­re Prak­tik, die unge­woll­te Erfin­dun­gen pro­vo­ziert, wie bei­spiels­wei­se die Metho­den Design Thin­king und Lean Startup.

Für das empi­ri­sche und evo­lu­tio­nä­re Vor­ge­hen agi­ler Orga­ni­sa­ti­ons­ent­wick­lung hat Seren­di­pi­tät dabei einen beson­de­ren Wert. Ein (und wenn ggf. auch nur gra­du­el­ler) Unter­schied zwi­schen einer sys­te­mi­schen zu einer agi­len Orga­ni­sa­ti­ons­ent­wick­lung liegt in der Ziel­fo­kus­sie­rung. Durch das Seren­di­pi­täts­prin­zip wird die prin­zi­pi­el­le Ergeb­nis­of­fen­heit über beab­sich­tig­te Zie­le und vor­han­de­ne Her­aus­for­de­run­gen hin­aus erwei­tert auf uner­war­te­te aber nütz­li­che Entwicklungen.

Wie beim sys­te­mi­schen Coa­ching den Coa­chee, so kön­nen wir die Orga­ni­sa­ti­ons­mit­glie­der fra­gen, wel­che unbe­ab­sich­tig­ten oder zufäl­li­gen Ergeb­nis­se ent­stan­den sind, wel­che über­ra­schen­den Beob­ach­tun­gen sie gemacht haben und was sie damit Nütz­li­ches anstel­len könn­ten. Dazu muss ledig­lich, ähn­lich wie beim Design Thin­king, bewusst die Auf­merk­sam­keit auf die­se Fra­gen gerich­tet werden.

Bewuss­te Irri­ta­tio­nen durch sys­te­mi­sche Fra­gen pro­vo­zie­ren in ähn­li­cher Wei­se unge­woll­te Per­spek­ti­ven und neue Ideen.

Geschäftswertorientierte Priorisierung

Kern­prin­zi­pi­en von Scrum und agi­lem Pro­jekt­ma­nage­ment ist die regel­mä­ßi­ge Prio­ri­sie­rung der nächs­ten umzu­set­zen­den Anfor­de­run­gen oder Ent­wick­lun­gen. In Scrum ist die Prio­ri­sie­rung der Rol­le des Product-Owners zuge­schrie­ben und wird damit bewusst unter­schie­den von den Auf­ga­ben des Ent­wick­lungs­teams, das wie­der­um die Umset­zungs­auf­wän­de schät­zen kann.

Für eine Prio­ri­sie­rung nach Geschäfts­wert sind bei­de Aspek­te wichtig:

  •       Wel­cher Nut­zen wird erwartet?
  •       Wel­che Kos­ten und Auf­wän­de wer­den zur Her­stel­lung erwartet?

Das Kosten-Nutzen-Verhältnis kann dann die Basis der Prio­ri­sie­rung bil­den. Die Beson­der­heit von Scrum und agi­lem Pro­jekt­ma­nage­ment ist die Sys­te­ma­tik, mit der die­se Prio­ri­sie­rung erfolgt. Im Nor­mal­fall wird dies mit einem ite­ra­ti­ven Vor­ge­hen ver­bun­den, so dass die Prio­ri­sie­rung zu fes­ten und regel­mä­ßi­gen Zeit­punk­ten erfolgt. Dies ist in der sys­te­mi­schen Orga­ni­sa­ti­ons­ent­wick­lung in die­ser Form kein Standard.

Strenge Zeitfenster (Timeboxing)

Ite­ra­ti­ve Vor­ge­hens­wei­sen wie Scrum unter­schei­den bewusst zwi­schen Mei­len­stei­nen und Zeit­fens­tern (Time­bo­xen).

Bei einem Mei­len­stein wird gewar­tet, bis ein defi­nier­tes Ergeb­nis erreicht wur­de. Bei einer Time­box wird zu einem defi­nier­ten Zeit­punkt ermit­telt, wel­ches Ergeb­nis erreicht wur­de. Die Kon­zep­te sind kom­ple­men­tär zu sehen und ergän­zen sich gut.

Mei­len­stei­ne haben oft auf der Makro­ebe­ne ihren beson­de­ren Nut­zen, wo die Nutz­bar­ma­chung eines Geschäfts­wer­tes von bestimm­ten zu errei­chen­den Eigen­schaf­ten abhängt. Beim Bau eines Flug­zeu­ges wer­den bei­spiels­wei­se bei­de Flü­gel benö­tigt, damit es flie­gen kann.

Über Time­bo­xen kann der suk­zes­si­ve Aus­bau des Geschäfts­wer­tes ver­folgt wer­den. Im Bei­spiel des Flug­zeugsbaus könn­te ermit­telt wer­den, wie vie­le Kopf­hö­rer­buch­sen des Unter­hal­tungs­sys­tems bereits funk­tio­nie­ren oder ob die Kaf­fee­ma­schi­ne bereits betriebs­be­reit ist.

Klas­si­sche Pro­jekt­pla­nungs­an­sät­ze ver­fol­gen eine voll­stän­di­ge Ziel­er­rei­chung, wäh­rend agi­le Ansät­ze kon­se­quent auf (aus­bau­ba­ren Zwischen-) Ergeb­nis­se set­zen, die zunächst gut genug sind, um ein­ge­setzt oder aus­pro­biert zu wer­den. Die kon­ti­nu­ier­li­che Ver­bes­se­rung hat hier Vor­rang gegen­über dem Perfektionsstreben.

Ein sys­te­mi­sches Vor­ge­hen ist eben­falls res­sour­cen­ori­en­tiert, weil dort die Auf­merk­sam­keit auf wahr­nehm­ba­re Ver­än­de­run­gen gelenkt wird, um so Ver­än­de­run­gen zu iden­ti­fi­zie­ren. Der Ansatz, dies in Pro­zes­se zu ver­an­kern und regel­mä­ßig zu defi­nier­ten Zeit­punk­ten zu tun, bei­spiels­wei­se alle 14 Tage, erzeugt eine grö­ße­re Unab­hän­gig­keit vom Coach und von beglei­ten­den Beratern.

Irritationen und systemische Fragen

Bewuss­te Irri­ta­tio­nen gehö­ren zum sys­te­mi­schen Stan­dard­re­per­toire. Irri­ta­tio­nen brin­gen Sys­te­me und sei­ne Tei­le in Bewe­gung und pro­vo­zie­ren als kon­struk­ti­ve Ver­stö­rung neue Aspek­te und Sicht­wei­sen. Vie­le sys­te­mi­sche Fra­gen irri­tie­ren, weil sie unkon­ven­tio­nell sind und im Wider­spruch zum All­tags­ver­ständ­nis ste­hen. Dazu gehö­ren zir­ku­lä­re Fra­gen (Was meinst du wie dein Kol­le­ge dar­über denkt?), meta­pho­ri­sche Fra­gen (Wenn euer Team ein Tier wäre, …), hypo­the­ti­sche Fra­gen (Was wäre wenn, …), manch­mal auch Ska­lie­rungs­fra­gen (Wel­chen Wert auf einer Ska­la von 1 bis 10 wür­dest du …) und ganz all­ge­mein lösungs­ori­en­tier­te Fra­gen, die ohne tie­fe­res Pro­blem­ver­ständ­nis aus­kom­men. Beson­ders hohes Irri­ta­ti­ons­po­ten­ti­al ber­gen so genann­te para­do­xe Fra­gen, die dem All­tags­ver­ständ­nis völ­lig ent­ge­gen­ge­setzt sind, bei­spiels­wei­se die Fra­ge, wie man etwas völ­lig zum Schei­tern brin­gen könnte.

Agi­le Metho­den wie Scrum und Kan­ban arbei­ten typi­scher­wei­se und zumin­dest nicht expli­zit mit Irri­ta­tio­nen oder sys­te­mi­schen Fra­gen, wodurch ihnen alter­na­ti­ve Sicht­wei­sen und die damit pro­vo­zier­ten neu­en Ideen ent­ge­hen. Design Thin­king för­dert ver­gleich­ba­re Effek­te durch Seren­di­pi­tät oder bewuss­te Wech­sel von Problem- und Lösungs­raum sowie von diver­gen­tem und kon­ver­gen­tem Handeln.

Soziale Ebene

Als typi­sche Inge­nieurs­me­tho­den sind Scrum und Kan­ban, aber weit­ge­hend auch Design Thin­king und Lean Start­up Vor­ge­hens­wei­sen, die sich auf die Sach­ebe­ne kon­zen­trie­ren. Es geht um Pro­duk­te, Dienst­leis­tun­gen und die dafür not­wen­di­gen Struk­tu­ren und Pro­zes­se. Die sozia­le Ebe­ne wird berück­sich­tigt durch eini­ge, die Krea­ti­vi­tät und Kom­mu­ni­ka­ti­on anre­gen­den Tech­ni­ken bis hin zur Ko-Kreation und Inter­dis­zi­pli­na­ri­tät in Teams, Her­stel­lung räum­li­cher Nähe und star­ker Visua­li­sie­rung wich­ti­ger Arte­fak­te und Informationen.

Dar­über hin­aus ste­hen die Men­schen als sozia­le Wesen mit ihren Bedürf­nis­sen und Gefüh­len nicht beson­ders im Auf­merk­sam­keits­fo­kus. Ganz anders die sys­te­mi­schen Ansät­ze, die eben genau die­se sozia­le Ebe­ne expli­zit berück­sich­ti­gen. Wenn­gleich die Sys­tem­theo­rie hier­zu durch­aus gewöh­nungs­be­dürf­ti­ge Per­spek­ti­ven und Model­le anbie­tet, bei­spiels­wei­se dass sozia­le Sys­te­me nicht aus Men­schen (Objek­ten) son­dern Kom­mu­ni­ka­ti­ons­fä­den (Pro­zess­ele­men­ten) bestehen.

Sowohl sys­te­mi­sche als auch eini­ge agi­le Ansät­ze unter­schei­den die Arbeit im und am Sys­tem und steu­ern eher über eine pas­sen­de Rah­mung, die sys­te­mi­schen aber deut­lich bewuss­ter und kon­se­quen­ter. Bei­de arbei­ten mit Refle­xi­ons­schlei­fen, jedoch schwer­punkt­mä­ßig auf unter­schied­li­chen Ebenen.

Für die Pro­dukt­ent­wick­lung oder ‑her­stel­lung, für die agi­le Metho­den erfun­den wur­den, ist der Fokus auf die Sach­ebe­ne ange­mes­sen und zunächst aus­rei­chend. Sobald es aber um Orga­ni­sa­ti­ons­ent­wick­lung geht, also nicht um die Her­stel­lung tech­ni­scher Pro­duk­te, son­dern die Ent­wick­lung eines sozia­len Sys­tems, erwei­sen sich agi­le Metho­den in die­sem Punkt als unzureichend.

Sehr deut­lich wird dies am Bei­spiel des Orga­ni­sa­ti­ons­mo­dells Hol­acra­cy, wel­ches mecha­nis­tisch geprägt ist, mit der Meta­pher des „orga­ni­sa­to­ri­schen Betriebs­sys­tems“ arbei­tet und dabei igno­riert, dass das Sys­tem nicht aus kau­sal bere­chen­ba­ren Tei­len, son­dern aus kom­ple­xen sozia­len Wesen besteht. Mensch­li­che Bedürf­nis­se gera­ten dadurch schnell in den Man­gel, för­dern Kom­pen­sa­ti­ons­be­dürf­nis­se und pro­vo­zie­ren gar Konflikte.

Systemrationalität und Werte

Sys­te­mi­sche Ansät­ze basie­ren auf der Idee der System- statt Zweck­ra­tio­na­li­tät, was bedeu­tet, dass Orga­ni­sa­tio­nen nicht dadurch über­le­ben, dass sich ihre Orga­ni­sa­ti­ons­mit­glie­der gemein­sa­me Zie­le tei­len, son­dern dass sie fähig ist, den ganz unter­schied­li­chen Inter­es­sen als gemein­sa­mes Mit­tel zu die­nen. Jeder Mit­ar­bei­ter gibt dem Unter­neh­men einen eige­nen Sinn, ver­folgt eige­ne Zie­le und benutzt die Orga­ni­sa­ti­on für indi­vi­du­el­le Zwecke.

Orga­ni­sa­tio­nen haben dem­nach kei­ne ein­heit­li­che oder uni­ver­sel­le Sinn­vor­ga­be, son­dern sind eine Zweck­ge­mein­schaft von Unter­neh­mern und Mit­ar­bei­tern, die Kun­den­be­dürf­nis­se befrie­di­gen, um damit Geld zu ver­die­nen, Aner­ken­nung zu bekom­men, her­aus­ge­for­dert zu wer­den oder was auch immer. Aus die­ser Per­spek­ti­ve sind Unter­neh­mens­leit­bil­der und ‑visio­nen zu hinterfragen.

Inter­es­sant ist nun, dass die Sze­ne der agi­len Soft­ware­ent­wick­lung ganz bewusst auf eine Men­ge bestimm­ter “Wer­te” setzt: Selbst­ver­pflich­tung, Ein­fach­heit, Rück­mel­dun­gen, Fokus, Kom­mu­ni­ka­ti­on, Mut, Offen­heit und Respekt. Der gemei­ne Sys­temi­ker ist hier manch­mal rat­los, weil er sich an Unter­schei­dun­gen ori­en­tiert, also an der Fra­ge, wel­che Sei­ten von­ein­an­der abge­grenzt wer­den. Erst dadurch ent­ste­hen ope­ra­tio­na­li­sier­ba­re Bezü­ge zum Handeln.

Oft­mals wer­den die so for­mu­lier­ten Wer­te ledig­lich dazu benutzt, über die Eigen­schaf­ten eines Men­schen zu spe­ku­lie­ren oder zu urtei­len, bei­spiels­wei­se zu bewer­ten, wie offen jemand ist. Die Wer­te haben dann Appell-Charakter, for­dern bestimm­te (vor­der­grün­di­ge) Ver­hal­tens­wei­sen und pro­vo­zie­ren letzt­end­lich Unternehmenstheater.

Dage­gen sind die vier Unter­schei­dun­gen aus dem agi­len Mani­fest (Indi­vi­du­en und Inter­ak­tio­nen ste­hen über Pro­zes­sen und Werk­zeu­gen; Funk­tio­nie­ren­de Soft­ware steht über einer umfas­sen­den Doku­men­ta­ti­on; Zusam­men­ar­beit mit dem Kun­den steht über der Ver­trags­ver­hand­lung; Reagie­ren auf Ver­än­de­rung steht über dem Befol­gen eines Plans) kon­kre­ter. Aus die­sen las­sen sich Hand­lungs­al­ter­na­ti­ven ablei­ten, weil das eine wich­ti­ger als das jeweils ande­re ein­ge­stuft wird.

Epilog

Die zuvor beschrie­be­nen Unter­schei­dun­gen und Beson­der­hei­ten sind nicht voll­stän­dig und auch inhalt­lich nur Annä­he­run­gen. Ich habe sie nicht allei­ne ent­wi­ckelt, son­dern zusam­men mit Cars­ten Holt­mann im Rah­men eines Work­shops auf dem Sym­po­si­um 2017 der isb Initia­ti­ve Nord her­aus­ar­bei­ten las­sen. Vie­len Dank allen Beitragenden.

 

Dieser Beitrag hat 4 Kommentare

Schreibe einen Kommentar zu Warum ich es gewagt finde, Scrum zur Organisationsentwicklung einzusetzen | next U Kommentar Antwort löschen

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