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 Owner­ship ist das etwa so Erfolg ver­spre­chend wie der Ver­such, Kin­dern das Fahr­rad­fah­ren auf einem Downhill-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 Owner­ship 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 Downhill-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-month: 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 Sut­her­land mit Scrum doch eine Ver­dopp­lung der Arbeits­leis­tung bei Hal­bie­rung der benö­tig­ten Zeit ver­spro­chen (Sut­her­land, J. (2019). Scrum: The art of doing twice the work in half the time. rh Ran­dom House Business.). 

Break down bar­riers bet­ween depart­ments. Peo­p­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 Sut­her­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 Owner­ship. 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 Uns­plash

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