Schnell mal agil

Sie ken­nen das. Der Pro­jekt­start ver­zö­gert sich Mal wie­der. Zuerst ließ die Beauf­tra­gung auf sich war­ten, jetzt ist der ein­zi­ge Fach­ex­per­te des Kun­den krank. Schon zum Start eine Ver­zö­ge­rung von fünf Wochen. Alle schau­en sich tief in die Augen und ver­si­chern sich: »Das holen wir wie­der auf: Wir gehen ein­fach agil vor!«

Der End­ter­min eines Pro­jekts ist unan­tast­bar. Das scheint ein unge­schrie­be­nes Gesetz zu sein. Egal wie spät ein Pro­jekt star­te­te, egal wir sehr sich der Umfang änder­te, egal wel­che Pro­ble­me auf­tauch­ten, der End­ter­min bleibt. Schließ­lich wür­de durch ein Ver­schie­ben eines klar: Da hat jemand sein Pro­jekt nicht im Griff. Egal wie wenig jemand über ein Pro­jekt und sei­ne Umstän­de weiß, einen ver­scho­be­nen Lie­fer­ter­min glaubt jeder als Ver­sa­gen inter­pre­tie­ren zu kön­nen. Dar­um ver­schiebt kei­ner gern.

So weit, so gut. Dann muss der Umfang ver­än­der­lich sein, um auf Ein­flüs­se über­haupt reagie­ren zu kön­nen. Bei­des, also fes­ter Ter­min und fes­ter Umfang, geht nicht. Die­sen Zusam­men­hang blen­den vie­le Pro­jekt­ma­na­ger und noch mehr Auf­trag­ge­ber ger­ne aus. Im klas­si­schen Pro­jekt­ma­nage­ment opti­miert der Pro­jekt­ma­na­ger die Ablauf­plä­ne indem er sequen­ti­el­le Tätig­kei­ten teil­wei­se über­lappt oder indem er die Dau­er von Vor­gän­gen durch mehr Mit­ar­bei­ter ver­kürzt. Mit der nöti­gen Vor­sicht ange­wen­det, sind die­se Maß­nah­men nicht falsch. Grob fahr­läs­sig wird es, wenn damit aber ein ohne­hin schon opti­mis­ti­scher Plan all­zu naiv opti­miert wird, nur um einen vor­ge­ge­be­nen End­ter­min zu halten.

A pro­ject mana­ger is a per­son who thinks nine women can deli­ver a baby in one month.

Mitt­ler­wei­le hat sich auch in gro­ßen Indus­trie­un­ter­neh­men her­um­ge­spro­chen, dass es neben der klas­si­schen Metho­dik noch eine ande­re, viel bes­se­re, viel schnel­le­re gibt. Statt also wie bis­her aus dem opti­mis­ti­schen Plan durch Opti­mie­rung einen unrea­lis­ti­schen zu machen, heißt es mitt­ler­wei­le immer öfter: »Wir gehen ein­fach agil vor!«. Mit der impli­zi­ten Erwar­tung dann schnel­ler zum Ziel zu kom­men. Ein gefähr­li­cher Trugschluss.

Agi­li­tät bedeu­tet in ers­ter Linie Wen­dig­keit, also die Fähig­keit schnell auf Unvor­her­ge­se­he­nes reagie­ren zu kön­nen. Agi­les Vor­ge­hen bedeu­tet per Defi­ni­ti­on, dass der Umfang fle­xi­bel ist und dass die­ser Umfang in klei­nen Häpp­chen prio­ri­siert, umge­setzt und in kur­zen Feed­back­schlei­fen erprobt wird. Mit­hin könn­te ein agi­les Vor­ge­hen tat­säch­lich eine pas­sen­de Reak­ti­on sein auf die ange­spann­te Ter­min­la­ge durch eine Ver­zö­ge­rung zum Pro­jekt­start. Jedoch nicht um schnel­ler den gesam­ten Umfang umzu­set­zen, son­dern um zum unver­rück­ba­ren End­ter­min einen brauch­ba­ren Umfang zu bekommen.

Fazit

Wun­der­waf­fen gibt es nicht. Eine Ver­zö­ge­rung ist und bleibt eine Ver­zö­ge­rung und ver­schwin­det nicht ein­fach. Wenn der End­ter­min unan­tast­bar ist, muss in der Regel der Umfang ange­passt wer­den. Die­sen Zusam­men­hang sich selbst und allen Betei­lig­ten immer wie­der in Erin­ne­rung zu rufen und dar­auf kon­se­quent zu bestehen, das ist eine der wich­tigs­ten Pflich­ten des umsich­ti­gen Pro­jekt­ma­na­gers. Erst wenn all­ge­mein akzep­tiert ist, dass der Umfang des Pro­jekts fle­xi­bel sein muss, darf ein agi­les Vor­ge­hen gewählt wer­den. Nicht um schnel­ler zu sein, son­dern auf dem Weg zum End­ter­min den Umfang im Dia­log zu erarbeiten.

Foto: Das Arti­kel­bild wur­de von Juan_Alvaro unter dem Titel „Racing car“ auf Flickr unter einer Crea­ti­ve Com­mons CC BY 2.0 Lizenz veröffentlicht.

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.

10 Kommentare

Der Post spie­gelt genau mei­ne Erfah­rung wie­der. Es wäre oft gut, wenn man Ver­nunft und Erfah­rung in Ein­klang brin­gen könnte.

Schö­ne Zusam­men­fas­sung! Erle­be immer wie­der wie „Agil = Schnel­ler“ an das höhe­re Manage­ment ver­kauft wird und spä­ter die Über­ra­schung groß ist, dass dem nicht so ist.

Dan­ke für Dei­ne Zustim­mung. Lei­der ist es oft aber auch so, dass das höhe­re Manage­ment genau das agil = schnel­ler hören will bzw. genau dar­auf anspringt.

Agil = Schnel­ler“ Mit die­sem Argu­ment wird lei­der der Coa­ching Markt befeu­ert. Mit Ver­nunft ver­kau­fen sich kei­ne Semi­na­re. Eine der Scrum-Bibeln wird mit „SCHNELLER, BESSER, EFFEKTIVER MIT SCRUM“ beworben.

Davon abge­se­hen stim­me ich Dir voll­stän­dig zu. Der Satz gefällt mir besonders:

Jedoch nicht um schnel­ler den gesam­ten Umfang umzu­set­zen, son­dern um zum unver­rück­ba­ren End­ter­min einen brauch­ba­ren Umfang zu bekommen.“

Gute Gedan­ken! „Erst wenn all­ge­mein akzep­tiert ist, dass der Umfang des Pro­jekts fle­xi­bel sein muss, darf ein agi­les Vor­ge­hen gewählt wer­den“. Und weil der Umfang eines Pro­jekts nicht immer fle­xi­bel ist, kann auch nicht immer agi­les Vor­ge­hen gewählt wer­den. Migra­tio­nen sind „alles oder nichts“. 

Natür­lich muss das neue Sys­tem nicht gleich nach der Migra­ti­on alle 100 Funk­tio­nen kom­plett ver­füg­bar haben. Da kann man getrost eine nach der ande­ren der weni­ger wich­ti­gen Funk­tio­nen auf­schal­ten. Aber die Migra­ti­on muss als Gan­zes so klap­pen, dass danach kei­ne betriebs­ver­hin­dern­den Issues auf­tau­chen. Ist das nicht gege­ben, kommt ein Roll­back­sze­na­rio zum Zug und man ist wie­der auf dem alten Sys­tem. Alles oder nichts, kei­ne Iterationen.

Der Roll­back wäre ziem­lich schlimm, denn sol­che Sys­te­me stel­len meis­tens Netz­diens­te zur Ver­fü­gung, die von 10’000, 100’000 oder gar Mil­lio­nen Endu­sern genutzt wer­den. Ein­mal muss­te ich z.B. die Netz­soft­ware für bun­des­weit alle Ban­ko­mat­sys­te­me migrie­ren. Wenn danach auch nur ein Ban­ko­mat wegen der Migra­ti­on aus­ge­fal­len wäre, hät­te man mit Kla­gen rech­nen müs­sen. Die Unmen­gen an Endu­ser erhal­ten in der Regel ein paar Wochen vor dem geplan­ten Wech­sel eine Infor­ma­ti­on. Daher ist auch der End­ter­min von Migra­ti­ons­pro­jek­ten ziem­lich unverrückbar.

Guter Ein­wand das Bei­spiel der Migra­ti­on. Ist in letz­ter Kon­se­quenz tat­säch­lich 0 oder 1. Wobei man auch bei Migra­tio­nen vor­her durch­aus ite­ra­tiv vor­geht und ganz vie­le Tro­cken­läu­fe in mög­lichst rea­lis­ti­scher Umge­bung hat bevor man den Umstel­lungs­ter­min ankün­digt. Inso­fern ist man bis zu die­ser Ankün­di­gung beim Ter­min schon fle­xi­bel und das ist auch gut so.

Hi,

von der Ein­lei­tung her ein guter Arti­kel. Lei­der fehlt mir etwas der Inhalt. Agi­les Pro­jekt­ma­nag­ment bedeu­tet mehr als Pro­jek­te fle­xi­bel zu gestal­ten. Ich sehe da Plan­ning Mee­ting, das Dai­ly Plan­ning Mee­ting, Retro­spek­ti­ven, Schät­zen mit Sto­ry Points… mehr dazu: http://www.agile-is-limit.de/its-agile-woran-erkennst-du-ein-agiles-team-10-punkte/

und zur Über­schrift: Schnell mal agil – doch geht :) 

Ab sofort, ab heu­te – Go for it! :P

Hi,

vom Ansatz her ein guter Kom­men­tar. Lei­der fehlt mir etwas der Inhalt, wes­halb er auch mehr oder weni­ger zu Recht dem Spam­fil­ter zum Opfer fiel. Wie ich schon an ande­rer Stel­le hier im Blog mehr­fach aus­ge­führt habe und hier noch­mals ver­tieft habe, hat agi­les Vor­ge­hen für mich den gro­ßen Charme, fle­xi­bel auf Ver­än­de­run­gen reagie­ren zu kön­nen. Wie man die agi­len Grund­sät­ze dann in der Pra­xis umsetzt und ob das dann Scrum hei­ßen muss (und nur dar­auf zielt ihre Auf­zäh­lung) ist eine ganz ande­re Fra­ge, die nur im Kon­text der kon­kre­ten Pro­jekt­si­tua­ti­on ent­schie­den wer­den kann. 

Und nein: schnell mal agil in dem Sin­ne wie ich es in dem Arti­kel beschrei­be, geht nicht.

Ich darf zwei Scrum-Teams in einem gro­ßen Pro­jekt beglei­ten und kann bestä­ti­gen, dass im Manage­ment die Erwar­tung vor­herrscht, dass es agil schnel­ler geht. Natür­lich ist das Quatsch. Man bekommt nur schnel­ler einen ROI durch häu­fi­ge­re Releases, aber das ist ein nicht zu unter­schät­zen­der Vorteil.

Das Manage­ment glaubt auch ger­ne dar­an, dass es bei klas­sisch geplan­ten Pro­jek­ten am Ende das geplan­te bekommt. Das ist aber nie der Fall. Abstri­che und Ände­run­gen sind genau­so an der Tages­ord­nung wie Ter­min­ver­schie­bun­gen und man­gel­haf­te Anfor­de­run­gen. Bei agi­lem Vor­ge­hen akzep­tiert man das von vorn­her­ein und prio­ri­siert vor jedem Sprint neu.

Schreibe einen Kommentar