Ein bisschen agiler, bitte

Mehr als ein Jahr­zehnt nach dem agi­len Mani­fest ist agi­les Vor­ge­hen im Main­stream ange­kom­men. Bei den klei­nen Soft­ware­un­ter­neh­men sowie­so, aber zuneh­mend auch bei gro­ßen Kon­zer­nen. Wo bis­her strikt nach Was­ser­fall vor­ge­gan­gen wer­den muss­te, fin­den immer mehr agi­le Ansät­ze Ein­zug in die Pro­jek­te. Meist aber aus­schließ­lich für die Pha­se der Pro­gram­mie­rung der vor­ab im Detail spe­zi­fi­zier­ten Anfor­de­run­gen. Ein Anfang immer­hin, der aller­dings nur einen Bruch­teil des wah­ren Poten­ti­al agi­len Vor­ge­hens hebt.

Das klas­si­sche Was­ser­fall­vor­ge­hen pro­du­ziert anfangs gewal­ti­ge Men­gen Papier bevor am Ende Soft­ware ent­steht: ange­fan­gen bei einem Grob­kon­zept über ein Fach­kon­zept zu einem IT-Kon­zept. Stu­fe für Stu­fe wer­den die fach­li­chen Anfor­de­run­gen detail­liert und mit allen Betei­lig­ten abge­stimmt bis end­lich mit der Umset­zung der Anfor­de­run­gen begon­nen wer­den kann.

Was theo­re­tisch nach einem brauch­ba­ren Vor­ge­hen klingt, hat in der Pra­xis eini­ge Tücken. Zum einen ist der Pro­zess lang­wie­rig und schwer­fäl­lig: Vom Erken­nen einer Anfor­de­rung bis zu ihrer Umset­zung in der Soft­ware kön­nen durch­aus Jah­re ver­ge­hen. Zum ande­ren fehlt Fle­xi­bi­li­tät: Anfor­de­rungs­än­de­run­gen sind zwar mög­lich, wer­den aber als Aus­nah­men betrach­tet und meist recht schwer­ge­wich­tig ver­wal­tet. Im Ergeb­nis führt das zu lan­gen Pro­jekt­lauf­zei­ten für Soft­ware­sys­te­me, die dann teil­wei­se nicht mehr zur mitt­ler­wei­le ver­än­der­ten Rea­li­tät pas­sen, dafür aber vie­le Anfor­de­run­gen zwei­fel­haf­ten Nut­zens ent­hal­ten. Die­se Kluft zwi­schen ech­ten und Nut­zen stif­ten­den Anfor­de­run­gen einer­seits und im Sys­tem umge­setz­ten Anfor­de­run­gen ande­rer­seits tritt zudem meist erst ganz am Ende des Was­ser­falls zu Tage und kann dann schwie­rig oder nur mit erheb­li­chen Mehr­kos­ten wie­der geschlos­sen werden.

Working soft­ware over com­pre­hen­si­ve documentation.
Mani­festo for Agi­le Soft­ware Development

Mitt­ler­wei­le haben auch gro­ße Unter­neh­men eher klas­si­scher Bran­chen die­se Pro­ble­ma­tik durch­aus erkannt und wol­len agi­ler wer­den. Ohne sich aller­dings kom­plett vom Was­ser­fall zu ver­ab­schie­den. Was liegt also näher als ein­fach auf Basis des detail­lier­ten Fach­kon­zept die agi­le Umset­zung zu star­ten? Aus den Anfor­de­run­gen des Fach­kon­zepts wird schnell das Back­log erstellt und in klei­nen Häpp­chen voll­stän­dig abge­ar­bei­tet. So ent­steht nach jedem Sprint benutz­ba­re Soft­ware und es fühlt sich irgend­wie dyna­misch an. Ziel erreicht.

Ein Etap­pen­ziel jeden­falls. Jeder neue Soft­ware­stand erzeugt näm­lich neue Rück­mel­dun­gen und neue Erkennt­nis­se. Und zwar oft sol­che, die lei­der bis­her nicht oder nicht rich­tig im Fach­kon­zept berück­sich­tigt wur­den. Schnell wächst das Back­log und es muss nun wirk­lich prio­ri­siert wer­den in dem Sin­ne, dass die Anfor­de­run­gen im Back­log nicht voll­stän­dig umge­setzt wer­den, son­dern eben nur bis der erwar­te­te Nut­zen erreicht oder das Bud­get auf­ge­braucht ist. Nun wird nicht nur in kur­zen Ite­ra­tio­nen aus­ge­lie­fert, son­dern nut­zen­ori­en­tiert mit fle­xi­blem Umfang gear­bei­tet. Ein wei­te­res Etap­pen­ziel erreicht.

Nach eini­gen Sprints erkennt man aller­dings ein wie­der­keh­ren­des Mus­ter: Vie­le fach­li­che Anfor­de­run­gen klä­ren sich tat­säch­lich erst im Lau­fe der Umset­zung am kon­kre­ten Objekt und im Dia­log mit ech­ten Anwen­dern. Viel der müh­sa­men Detail­ar­beit eines Fach­kon­zepts, bei­spiels­wei­se die Erstel­lung von GUI-Pro­to­ty­pen, wird wäh­rend der Sprints im Prin­zip noch­mals durch­ge­führt aller­dings unter ande­ren Vor­aus­set­zun­gen und mit ande­rem Ergeb­nis. Ein deut­lich schlan­ke­res Fach­kon­zept oder ein etwas detail­lier­te­res Grob­kon­zept hät­te als Auf­satz­punkt für das agi­le Vor­ge­hen genau­so gute Diens­te geleis­tet und wäre schnel­ler und bil­li­ger zu haben gewesen.

Fazit

Es spricht abso­lut nichts dage­gen Ideen oder Kon­zep­te zu Papier zu brin­gen und gemäß Was­ser­fall abzu­neh­men. Es spricht aber auch viel dafür die­se Kon­zep­te mög­lichst schnell und mög­lichst kon­kret zu erpro­ben. Wenn am Ende ohne­hin eine agi­le Umset­zung ange­strebt wird, wür­de ich mir in vie­len Fäl­len mehr Mut wün­schen, früh­zei­tig und auf grö­be­rem Niveau in den agi­len Modus zu wech­seln. So lässt sich viel frucht­lo­se Dop­pel­ar­beit in der Fein­spe­zi­fi­ka­ti­on von Anfor­de­run­gen ver­mei­den. Es ent­steht frü­her pro­duk­tiv ein­setz­ba­re Soft­ware, die am Ende dann wirk­lich zu den Anfor­de­run­gen passt, die sich auf dem Weg dort­hin erge­ben und klären.

Arti­kel­bild: Vin­cent Lock bei flickr.com (CC BY 2.0)