Agil im großen Stil: Entkopplung vor Skalierung

In immer vola­ti­le­ren, unsi­che­re­ren, kom­ple­xen und viel­deu­ti­ge­ren Märk­ten und Umfel­dern, wird gera­de für gro­ße und ent­spre­chend star­re Orga­ni­sa­tio­nen in Zukunft die Anpas­sungs­fä­hig­keit immer wich­ti­ger. Oder mit den etwas dras­ti­sche­ren Wor­ten von Jack Welch: „If the rate of chan­ge on the out­side exceeds the rate of chan­ge on the insi­de, the end is near.“ Nun wol­len also alle agil wer­den, ihre Super­tan­ker agi­li­sie­ren und ihre Orga­ni­sa­tio­nen trans­for­mie­ren. Auf Ebe­ne des ein­zel­nen Teams scheint auch schnell alles klar: klein, schlag­kräf­tig und cross-funk­tio­nal soll es sein, end-to-end ver­ant­wort­lich und selbst­or­ga­ni­siert ent­schei­den mit einem Pro­duct-Owner als Visio­när und Rich­tungs­ge­ber. Was aber wenn die Pro­duk­te viel grö­ßer sind und gefühlt sowie­so alles mit allem irgend­wie zusam­men­hängt und also vie­le Teams koor­di­niert wer­den müs­sen? Dann schlägt die Stun­de von Ska­lie­rungs­frame­works wie dem Sca­led Agi­le Frame­work (SAFe), Lar­ge Sca­le Scrum (LeSS) oder Nexus. Zu früh meis­tens, weil die tech­ni­schen Schul­den der Ver­gan­gen­heit, die hohe Kopp­lung und die mono­li­thi­schen Archi­tek­tu­ren, dadurch akzep­tiert und ten­den­zi­ell nur ver­wal­tet anstatt redu­ziert wer­den. Kurz gesagt: Ent­kopp­lung vor Skalierung.

Jahr für Jahr zeigt der Cha­os-Report der Stan­dish-Group ein ähn­li­ches Bild: Je grö­ßer ein Pro­jekt, des­to gerin­ger die Erfolgs­wahr­schein­lich­keit. Auch wenn agi­le Pro­jek­te gegen­über Was­ser­fall-Pro­jek­ten eine deut­lich höhe­re Erfolgs­wahr­schein­lich­keit haben, die­se Ten­denz bleibt auch hier erhal­ten: Je grö­ßer, des­to ris­kan­ter. Zusam­men­ge­fasst sieht das dann bei­spiels­wei­se im Cha­os-Report 2015 so aus (ver­glei­che auch den zuge­hö­ri­gen Arti­kel bei InfoQ):

Quel­le: Stan­dish Group 2015 Cha­os Report – Q&A with Jen­ni­fer Lynch

Da für vie­le Orga­ni­sa­tio­nen lan­ge Jah­re Anpas­sungs­fä­hig­keit kei­ne ent­schei­den­de Rol­le spiel­te, son­dern eher die Effi­zi­enz im Vor­der­grund stand, ten­die­ren IT-Land­schaf­ten auf­grund ver­mu­te­ter Ska­len­ef­fek­te eher zu gro­ßen mono­li­thi­schen Archi­tek­tu­ren. Selbst wenn die­ses Mono­li­then in ver­schie­de­ne Schich­ten und Kom­po­nen­ten logisch unter­teilt sind, ihre hohe Kopp­lung erfor­dert den­noch ein koor­di­nier­tes Vor­ge­hen zur Wei­ter­ent­wick­lung, also gemein­sa­me Pla­nung, vie­le Abstim­mun­gen, gemein­sa­mer Test und gemein­sa­me Aus­lie­fe­rung in eine Pro­duk­ti­ons­um­ge­bung. Da die­se Mono­li­then ihrer­seits mit ande­ren Mono­li­then und Sys­te­men über Schnitt­stel­len ver­bun­den sind, sind dann für sol­che Clus­ter oft nur zwei bis drei gro­ße Releases pro Jahr mög­lich. Und gemäß den Ergeb­nis­sen des Cha­os-Reports ent­spre­chend riskant.

Quel­le: You­Tube

Dar­an ändert auch Agi­li­tät auf Team­ebe­ne mit ent­spre­chen­den Ska­lie­rungs­frame­works nichts. Die his­to­risch gewach­se­nen Abhän­gig­kei­ten wer­den ein­fach mehr oder weni­ger unhin­ter­fragt über­nom­men und anders koor­di­niert. Auch Ama­zon hat­te inter­es­san­ter­wei­se genau die­ses Pro­blem, wie Rob Brig­ham, AWS seni­or mana­ger for pro­duct manage­ment, in sei­nem Vor­trag bei re:invent 2015 selbst zugibt: „If you go back to 2001 the Amazon.com retail web­site was a lar­ge archi­tec­tu­ral mono­lith. Now, don’t get me wrong. It was archi­tec­ted in mul­ti­ple tiers, and tho­se tiers had many com­pon­ents in them, but they’re all very tight­ly cou­pled tog­e­ther, whe­re they beha­ved like one big mono­lith.“ Durch kon­se­quen­tes Refac­to­ring ihres Mono­li­then in klei­ne Ser­vices mit defi­nier­ten (und ver­sio­nier­ten) Schnitt­stel­len zur Ent­kopp­lung, auto­ma­ti­sier­ten Tests gegen die­se APIs und einer hoch-auto­ma­ti­sier­ten Deploy­ment-Engi­ne (Apol­lo) kön­nen die Two-Piz­za-Teams seit­her wei­test­ge­hend unab­hän­gig Anpas­sun­gen schnell aus­lie­fern (und taten das in den ers­ten zwölf Mona­ten nach Ein­füh­rung von Apol­lo auch 50 Mil­lio­nen mal, also mehr als ein­mal pro Sekun­de, wie Wer­ner Vogels, CTO Ama­zon, stolz berich­tet). Ein schö­nes Bei­spiel für das Prin­zip Ent­kopp­lung vor Skalierung.

Quel­le: You­Tube

Share This Post

Von Marcus Raitner

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

Schreibe einen Kommentar