Drei fatale Begründungen für agiles Vorgehen

Es gibt vie­le sehr gute Grün­de, sich für ein agi­les Vor­ge­hen im Pro­jekt zu ent­schei­den. Zum Bei­spiel weil man an die Krea­ti­vi­tät, Moti­va­ti­on und Eigen­ver­ant­wor­tung der Mit­ar­bei­ter glaubt. Und weil man der fes­ten Über­zeu­gung ist, dass eine Orga­ni­sa­ti­ons­form und ein Vor­ge­hen, das auf die­se Prin­zi­pi­en setzt, für das Fin­den inno­va­ti­ver Lösun­gen in kom­ple­xen Situa­tio­nen über­le­gen ist. Oder weil man nicht exakt das Ziel und den Umfang des Pro­jekts kennt, weil man Neu­land betritt. Neben die­sen und vie­len wei­te­ren guten Grün­den für ein agi­les Vor­ge­hen, gibt es aber auch eini­ge sehr fata­le Begrün­dun­gen, die auf grund­sätz­li­che Miss­ver­ständ­nis­se zurück­ge­hen und das Vor­ha­ben von Anfang an in Fra­ge stellen.

Andere machen es doch auch!

Agi­le is like teen sex: Ever­yo­ne wants to do it, many say they’­re doing it, only some actual­ly are, and very few are doing it right.

Alle ken­nen die Geschich­ten erfolg­rei­cher agi­ler Pro­jek­te. Nicht alle haben sich genau so zuge­tra­gen. Man­ches ver­klärt sich in der Rück­schau und man­ches wird bewusst zu Wer­be­zwe­cken über­höht. In vie­len Fäl­len engt sich der Blick des nei­disch auf sol­che Erfolgs­ge­schich­ten bli­cken­den Ent­schei­ders auf die agi­len Metho­den als sol­che. Aus­ge­blen­det wird dabei ger­ne das Umfeld der Pro­jekts und ins­be­son­de­re die Kul­tur und die Wer­te der Unter­neh­men, die die­se Pro­jek­te erfolg­reich agil durch­ge­führt haben. Über­trägt man nun ein­fach ein erfolg­rei­che Metho­de wie Scrum, die ja auch noch so ver­füh­re­risch ein­fach daher­kommt, in ein Umfeld das nicht die not­wen­di­gen Vor­aus­set­zung dafür auf­weist, muss die­ser Ver­such zwangs­läu­fig scheitern.

Bei­spiels­wei­se setzt agi­les Vor­ge­hen unbe­dingt eine ver­trau­ens­vol­le Zusam­men­ar­beit aller Betei­lig­ten auf Augen­hö­he vor­aus. Nicht umsonst heißt es im Agi­len Mani­fest „Cus­to­mer col­la­bo­ra­ti­on over con­tract nego­tia­ti­on.“ Wenn aber schon Fach­ab­tei­lung und IT-Abtei­lung im glei­chen Unter­neh­men sich nicht ganz grün sind und Lie­fe­ran­ten grund­sätz­lich nur für Gewer­ke zum Fest­preis even­tu­ell mit ent­spre­chen­den Ver­trags­stra­fen ver­se­hen ein­ge­kauft wer­den, wird es mit Ver­trau­en und Augen­hö­he eher schwierig.

Wir fangen einfach schon Mal an!

„Wir gehen agil vor!“ ist das neue „Fangt ein­fach schon Mal an!“
via @marcusraitner auf Twit­ter

Ein weit ver­brei­te­ter Irr­glau­be besagt, dass man agil vor­ge­hend weni­ger genau über Anfor­de­run­gen und Pro­zes­se nach­den­ken muss. Das Gegen­teil ist tat­säch­lich der Fall: Es wird sehr viel mehr über Anfor­de­run­gen und Pro­zes­se gespro­chen. Näm­lich so lan­ge bis das Team es ver­stan­den hat und rich­tig umset­zen kann. Und das ist auch gut so. Wer also glaubt, ohne die nöti­gen Kapa­zi­tä­ten für die­se Klä­run­gen ein­fach Mal los­le­gen zu kön­nen, wird schnell ste­cken blei­ben, weil das Team ohne fach­li­che Klä­run­gen durch einen star­ken Pro­duct Owner nicht arbei­ten kann.

Wer nicht genau weiß, wohin er will, der darf sich nicht wun­dern, wenn er ganz woan­ders ankommt.
Mark Twa­in

Tat­säch­lich geschieht die Dis­kus­si­on der Anfor­de­run­gen spä­ter als im gewohn­ten Was­ser­fall­mo­dell und daher rührt dann auch der fal­sche Ein­druck, dass man mit weni­ger oder weni­ger genau­er Spe­zi­fi­ka­ti­on aus­kom­men kön­ne. Ver­stärkt wird der Ein­druck noch dadurch, dass tat­säch­lich in der Regel weni­ger nie­der­ge­schrie­be­ne Spe­zi­fi­ka­ti­on vor der eigent­li­chen Soft­ware­er­stel­lung exis­tiert. Schließ­lich geht es nicht dar­um, Papier zu bedru­cken, son­dern Soft­ware zu pro­du­zie­ren, wel­che die Pro­zes­se opti­mal unter­stützt: „Working Soft­ware over com­pre­hen­si­ve docu­men­ta­ti­on.“ heißt es dazu im Agi­len Manifest.

Wir müssen verlorene Zeit aufholen!

Man ver­liert die meis­te Zeit damit, dass man Zeit gewin­nen will.
John Stein­beck

Das weit­aus am meis­ten ver­be­rei­te­te Miss­ver­ständ­nis ist es aber, mit agi­ler Vor­ge­hens­wei­se Zeit auf­ho­len zu wol­len. Agil heißt nicht schnell, son­dern meint wen­dig. Es geht dar­um, die Rich­tung mög­lichst leicht und effi­zi­ent ändern zu kön­nen. „Respon­ding to chan­ge over fol­lo­wing a plan.“ heißt es dazu im Agi­len Mani­fest.

Natür­lich lie­fert eine agi­le Vor­ge­hens­wei­se schnel­ler ers­te Zwi­schen­er­geb­nis­se, um schnell Rück­mel­dung zu erhal­ten und die Rich­tung ent­spre­chend kor­ri­gie­ren zu kön­nen. Wenn es aber dar­um geht, ein fest vor­ge­ge­be­nes Ziel, einen kla­ren Umfang, mög­lichst schnell zu errei­chen, kann man das auch agil tun, wird auf die gesam­te Lauf­zeit betrach­tet aber eher nicht schnel­ler sein.

Fazit

Ich bin der letz­te der nicht ger­ne agil vor­geht, aber eben nur wenn es zum Pro­jekt und zum Umfeld passt. Daher fra­ge ich immer nach, war­um eine agi­le Vor­ge­hens­wei­se gewählt wur­de oder wer­den soll. Will man Zeit auf­ho­len, ohne Ver­zö­ge­rung ein­fach los­le­gen oder es ande­ren gleich tun, ist höchs­te Vor­sicht gebo­ten. Kei­nes­falls soll­te man sich als Pro­jekt­lei­ter ein agi­les Vor­ge­hen unter sol­chen Bedin­gun­gen dik­tie­ren las­sen, son­dern viel­mehr Auf­klä­rungs­ar­beit leis­ten und gemein­sam mit Auf­trag­ge­ber und Ent­schei­dern ein pas­sen­des Vor­ge­hen fin­den und ein güns­ti­ge­res Umfeld schaffen.