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 Relea­ses 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 Tea­mebe­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

Teile diesen Beitrag

Schreibe einen Kommentar