Agilität ist wie Fahrradfahren

Zu oft wird Agi­li­tät in einer aku­ten Not­la­ge ange­wen­det. Scrum zur Ret­tung des Groß­pro­jekts. Der Fokus liegt dabei in den aller­meis­ten Fäl­len auf der Beschleu­ni­gung der Abar­bei­tung durch das form­schö­ne Zele­brie­ren von Sprints und Dai­ly Mee­tings. Ohne vor­he­ri­ge Übung in einem geschütz­ten Rah­men und ohne Fokus auf Team­work und Owners­hip ist das etwa so Erfolg ver­spre­chend wie der Ver­such, Kin­dern das Fahr­rad­fah­ren auf einem Down­hill-Track im Gebir­ge bei auf­zie­hen­dem Gewit­ter beizubringen.

Agi­le Metho­den soll­ten zunächst in einem klei­nen und geschütz­ten Rah­men erprobt und dann nach und nach aus­ge­wei­tet und auf kom­ple­xe­re Pro­jek­te und Pro­duk­te ange­wen­det wer­den. Wer aller­dings zu klein star­tet, bleibt auch wenig wirk­sam. Dann wer­den ein­fach bestehen­de Abtei­lun­gen, Teams, Arbeits­grup­pen, Gre­mi­en, usw. „agi­li­siert“. Die Orga­ni­sa­ti­on als sol­che steht nicht zur Dis­po­si­ti­on und auch nicht die eta­blier­ten Arbeits­ab­läu­fe. Die­se „Silo-Agi­li­tät“ wirkt sich nur mar­gi­nal auf die Wert­schöp­fung oder die Geschwin­dig­keit aus. Das Sport­lenk­rad allein sieht zwar schick und dyna­misch aus, ist aber nur agi­les Blendwerk.

Ein guter Start­punkt ist ein klei­nes Pro­jekt oder Pro­dukt, wo ein oder maxi­mal zwei Teams Wir­kung ent­fal­ten kön­nen, d. h. in kur­zen Abstän­den ech­ten Wert lie­fern kön­nen. Also nicht nur irgend­ein Spe­zia­lis­ten­team für Kon­zep­ti­on oder Test und auch nicht nur das Ent­wick­lungs­team, son­dern ein ech­tes inter­dis­zi­pli­nä­res Team, das Sprint für Sprint sein Pro­dukt ein wenig bes­ser macht. Die­ser Aspekt von Team­work und Owners­hip ist viel wich­ti­ger als das kunst­voll zele­brier­te Abar­bei­ten von Arbeits­pa­ke­ten in Sprints.

Agi­li­tät ist wie Fahr­rad­fah­ren – geübt wird anfangs in mög­lichst ein­fa­cher Umge­bung, auf ebe­ner, wenig befah­re­ner Stra­ße ohne Schot­ter und ähn­li­chen Stör­fak­to­ren. Idea­ler­wei­se beginnt die Erpro­bung von Agi­li­tät also wäh­rend sich das Pro­jekt oder das Pro­dukt noch in ruhi­gem Gewäs­ser befindet. 

Die Rea­li­tät sieht lei­der anders aus. Ohne Druck ändert sich gar nichts und ohne gro­ße Not wird sel­ten wirk­lich ernst­haft etwas Neu­es aus­pro­biert. Never touch a run­ning sys­tem. Wie­so ein Risi­ko ein­ge­hen? Zur Agi­li­tät, zu Scrum, SAFe und LeSS und vie­lem ande­ren wird erst gegrif­fen, wenn das Pro­jekt auf hoher See schon bedroh­lich Schlag­sei­te hat. Und das ist ten­den­zi­ell der Fall bei den gro­ßen und kom­ple­xen Pro­jek­ten und Pro­duk­ten. Die Agi­li­tät soll dann im lau­fen­den Betrieb und ohne vor­he­ri­ges Trai­ning in einer geschütz­ten Umge­bung ret­ten, was ander­wei­tig nicht mehr zu ret­ten ist. Das ist in etwa so Erfolg ver­spre­chend wie der Ver­such, Kin­dern das Fahr­rad­fah­ren auf einem Down­hill-Track im Gebir­ge bei auf­zie­hen­dem Gewit­ter beizubringen.

Adding man­power to a late soft­ware pro­ject makes it later.

Brook’s Law

Frü­her war das All­heil­mit­tel zur Ret­tung von Pro­jek­ten mehr Res­sour­cen, neu­er­dings scheint es der Schwenk zu Scrum und Co. zu sein. Genau­so wie zusätz­li­che Res­sour­cen ein ver­spä­te­tes Pro­jekt nur noch mehr ver­spä­ten (Brooks, F. P. (1975). The mythi­cal man-mon­th: Essays on soft­ware engi­nee­ring. Addi­son-Wes­ley Pub. Co.) ver­hält es sich oft auch mit der Ein­füh­rung der Agi­li­tät in einer sol­chen Not­la­ge. Die­ser Schwenk ist in einer aku­ten Kri­sen­si­tua­ti­on fast immer fehl­ge­lei­tet durch einen ein­sei­ti­gen Fokus auf die Beschleu­ni­gung der Abar­bei­tung. Scrum wird dann als Patent­re­zept ver­kauft und ein­ge­setzt, um in kür­ze­rer Zeit mit höhe­rem Druck mehr Arbeits­pa­ke­te durch das Rohr zu pum­pen. Schließ­lich hat Jeff Suther­land mit Scrum doch eine Ver­dopp­lung der Arbeits­leis­tung bei Hal­bie­rung der benö­tig­ten Zeit ver­spro­chen (Suther­land, J. (2019). Scrum: The art of doing twice the work in half the time. rh Ran­dom House Business.). 

Break down bar­ri­ers bet­ween depart­ments. Peop­le in rese­arch, design, sales, and pro­duc­tion must work as a team.

W. Edwards Deming

So mecha­nis­tisch betrach­tet, also ein­fach alles in Sprints abar­bei­ten und ein paar Dai­ly Mee­tings zele­brie­ren, endet der Ret­tungs­ver­such zwangs­läu­fig in einer form­schö­nen Car­go-Kult-Orgie. Das Ver­spre­chen von Jeff Suther­land kann erst ein­ge­löst wer­den nach einer Lern­pha­se in geschütz­tem Rah­men und mit einem kla­ren Fokus auf Team­work und Owners­hip. Der Dreh- und Angel­punkt ist die inter­dis­zi­pli­nä­re Zusam­men­ar­beit in einem Team das sich voll und ganz die­sem Pro­jekt oder Pro­dukt wid­men kann. Dadurch fal­len die Koor­di­na­ti­on von Schnitt­stel­len und Über­ga­ben weg und genau durch die­se Reduk­ti­on von Ver­schwen­dung im Ablauf ergibt sich die Geschwin­dig­keit. Wenn das Kon­zept­team, das Ent­wick­lungs­team und das Test­team, die jeweils eine Ansamm­lung von Split­ter­ka­pa­zi­tä­ten sind, ein­fach nach­ein­an­der in Sprints ihre Pake­te abar­bei­ten, ändert sich wenig und ver­brennt das Kon­zept der Agi­li­tät nur unnötig.

Titel­bild von Hen­ry & Co. auf Unsplash

Unterstützen

In mei­ne Arti­kel zu Lea­ders­hip, Agi­le und vie­lem mehr flie­ßen seit 2010 viel Arbeit und Lei­den­schaft. Mein Blog ist und bleibt frei von Wer­bung, aber Kos­ten ent­ste­hen dafür natür­lich trotz­dem. Wenn Dir mei­ne Arbeit mehr wert ist als ein Like, kannst du mich dabei unter­stüt­zen via Ko-fi.

Teile diesen Beitrag

Schreibe einen Kommentar