ScrumBut: Ein bisschen agil

Ganz sicher gibt es glü­hen­de­re Anhän­ger der rei­nen agi­len Leh­re als mich. Die Vor­ge­hens­wei­se im Pro­jekt muss pas­send sein und nicht stan­dar­di­siert. Was da aber unter dem Schlag­wort Scrum oder agi­les Vor­ge­hen in der Pra­xis ver­stan­den und vor allem miss­ver­stan­den wird, ist vor­sich­tig aus­ge­drückt aben­teu­er­lich. Ein Gut­teil der schlech­ten Erfah­run­gen mit Scrum liegt defi­ni­tiv in der mut­lo­sen Umset­zung und einer damit ein­her­ge­hen­den Ver­stüm­me­lung der Metho­dik bis zur Unbrauchbarkeit.

Mache die Din­ge so ein­fach wie mög­lich – aber nicht einfacher.
Albert Ein­stein

Zu Pro­jekt­be­ginn wer­den ger­ne nur die Vor­tei­le der agi­len Vor­ge­hens­wei­se gese­hen und im Ange­bot ange­prie­sen: Schnell den Kurs ändern zu kön­nen, in kur­zen Abstän­den Ergeb­nis­se sehen, eng ver­zahnt inter­dis­zi­pli­när im Team arbei­ten, nicht nur betrof­fen zu sein, son­dern betei­ligt. Die anfäng­li­che Eupho­rie ver­fliegt dann schnell, wenn das Pro­jekt mit der har­ten Rea­li­tät und der For­ma­li­tät der umge­ben­den Orga­ni­sa­ti­on kon­fron­tiert wird.

Das beginnt bei der ver­trag­li­chen Situa­ti­on, die meist ein Fest­preis für einen anfangs defi­nier­ten Umfang ist, bei­spiels­wei­se in Form eines fer­ti­gen Fach­kon­zepts, das umge­setzt wer­den soll. Auf Arbeits­ebe­ne kann man sich nun dar­auf eini­gen, die­sen Fest­preis als Kon­tin­gent zu betrach­ten und ent­spre­chend eines Back­logs umzu­set­zen bis das Kon­tin­gent aus­ge­schöpft ist. Bei eini­ger­ma­ßen akri­bi­scher Buch­füh­rung lässt sich das auch sau­ber auf die ursprüng­li­che Beauf­tra­gung abbil­den. Ande­rer­seits ist die Kun­den­sei­te oft eher klas­sisch im Sin­ne einer lang­fris­ti­gen Bud­get­pla­nung unter­wegs. Dort hat der ver­ant­wort­li­che Pro­jekt­lei­ter dann einen Pro­jekt­auf­trag in dem er bei­spiels­wei­se die Umset­zung eben die­ses Fach­kon­zepts ver­spricht und wor­an er gemes­sen wird. Das wird so aber nicht pas­sie­ren und soll so auch nicht pas­sie­ren, wenn man agil vor­geht. Also ist auch der Kun­de akri­bisch damit beschäf­tigt die Doku­men­ta­ti­on an die agil geschaf­fe­ne Rea­li­tät anzu­pas­sen. Klingt nicht nur müh­sam, ist es auch. Für alle Seiten.

Die nächs­te Hür­de sind dann for­ma­le Anfor­de­run­gen, die noch aus Zei­ten des Was­ser­fall­mo­dells stam­men. Natür­lich braucht man eine trag­fä­hi­ge Archi­tek­tur. Das heißt aber nicht, dass man zu Beginn alle Even­tua­li­tä­ten und Anfor­de­run­gen, die im Lau­fe der nächs­ten Jah­re auf­tre­ten könn­ten, in vol­ler Schön­heit ana­ly­sie­ren muss. Natür­lich haben die­sen Fra­gen ihre Berech­ti­gung, aber der Gedan­ke der mög­li­chen und sogar nöti­gen Absi­che­rung im Vor­feld ist fehl am Plat­ze. Die­se Fra­gen wer­den dann beant­wor­tet, wenn sie sich wirk­lich stel­len. Und die Ant­wort kann auch ein Refac­to­ring, also einen groß­flä­chi­gen Umbau der Anwen­dung, bedeu­ten. Das klingt zunächst nach mehr Auf­wand, ist es aber nicht, wenn man sich die über­flüs­si­gen Tro­cken­übun­gen zu Beginn in Form eines detail­lier­ten IT-Kon­zepts spart.

Bleibt noch die Pro­jekt­pla­nung. Recht ein­fach eigent­lich im agi­len Vor­ge­hen. Im wesent­li­chen besteht die Pla­nung aus einer Men­ge von Sprints plus ein paar for­ma­le Mei­len­stei­ne wie der gemein­sa­me Inte­gra­ti­ons­test in einer Sys­tem­land­schaft. In eher klas­sisch gepräg­ten Orga­ni­sa­tio­nen befrie­digt die­se Pla­nung das Kon­troll­be­dürf­nis aber nur unzu­rei­chend. Schnell kommt der Wunsch auf, die Sprints detail­liert mit Inhalt aus­zu­pla­nen, damit man genau weiß, wann wel­che Funk­tio­nen umge­setzt wer­den sol­len. Sonst weiß man doch gar nicht was genau man am Ende bekommt. Ja, genau das ist die Idee! Weil man näm­lich vor­her gar nicht genau genug spe­zi­fi­zie­ren kann, was man braucht.

Fazit

Das agi­le Vor­ge­hen im rea­len Leben, gera­de in eher klas­si­schen Orga­ni­sa­tio­nen, ist mit vie­len Her­aus­for­de­run­gen kon­fron­tiert und oft nur ein biss­chen agil oder eben Scrum­But. Von vie­len Sei­ten wird die rei­ne Leh­re ver­wäs­sert und teil­wei­se bis zur Unkennt­lich­keit ver­stüm­melt. Man­che Anpas­sun­gen oder Rah­men­be­din­gun­gen kön­nen eini­ger­ma­ßen pas­send gemacht wer­den, bei­spiels­wei­se die Fest­prei­se oder die For­de­rung nach einem mehr oder weni­ger detail­lier­ten IT-Kon­zept, ande­re sind hoch­gra­dig schäd­lich, bei­spiels­wei­se die detail­lier­te Planung.

Arti­kel­bild: Tre­vor Ley­en­horst bei flickr.com (CC BY 2.0)

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.

8 Kommentare

Die Vor­ge­hens­wei­se im Pro­jekt muss pas­send sein und nicht standardisiert.“
JA!!!
„Ein Gut­teil der schlech­ten Erfah­run­gen mit Serum liegt defi­ni­tiv in der mut­lo­sen Umset­zung und damit ein­her­ge­hen­den Ver­stüm­me­lung der Metho­dik bis zur Unbrauchbarkeit.“
NEIN. Genau HIER liegt der Denklfeh­ler, der als „agi­les Man­tra“ immer wie­der behaup­tet wird: Der Feh­ler liegt in der unre­flek­tier­ten Grund­an­nah­me, dass Scrum „out of the book“ am bes­ten funk­tio­niert und alle Abwei­chun­gen dafür zu Miss­erfol­gen führen.
Wenn eine an Scrum ange­lehn­te, die­ses aber weit­ge­hend ver­än­dern­de, Vor­ge­hens­wei­se, nicht funk­tio­niert, dann liegt in der Regel nicht an die­ser Vor­ge­hens­wei­se son­dern sehr oft dar­an, dass es an pro­fes­sio­nel­ler Arbeit (Craft­man­ship) etwa im sinn des Clean Code Deve­lo­p­ment fehlt, und an einer schlam­pi­gen bis feh­len­den Archi­tek­tur und an einem „RE auf Zuruf“ liegt. 

Dort hat der ver­ant­wort­li­che Pro­jekt­lei­ter dann einen Pro­jekt­auf­trag in dem er bei­spiels­wei­se die Umset­zung eben die­ses Fach­kon­zepts ver­spricht und wor­an er gemes­sen wird- Das wird so aber nicht pas­sie­ren und soll so auch nicht pas­sie­ren, wenn man agil vor­geht. Also ist auch der Kun­de akri­bisch damit beschäf­tigt die Doku­men­ta­ti­on an die agil geschaf­fe­ne Rea­li­tät anzu­pas­sen. Klingt nicht nur müh­sam, ist es auch- Für alle Seiten.“ 

GENAU: „Das wird so aber nicht pas­sie­ren und soll so auch nicht pas­sie­ren, wenn man agil vor­geht.“ Damit ist klar: Die Pro­b­ele­me ent­ste­hen durch das agi­le Vor­ge­hen. Mei­ne Erfah­rung ist, dass statt ein Clean Code Deve­lo­p­ment, eine trag­fä­hi­ge Archi­tek­tur und ein pro­fes­sio­nel­les RE anzu­stre­ben der ein­fa­che weg gege­gan­gen wird: All das wird kur­zer­hand als „zu kom­plex“ erklärt und inspi­riert vom Agi­len Mani­fest das intui­ti­ve Impro­vi­sie­ren zur offi­zi­el­len Metho­de als „Scrum“ glo­ri­fi­ziert. Das ist näm­lich viel einfacher. 

Die nächs­te Hür­de sind dann for­ma­le Anfor­de­run­gen, die noch aus Zei­ten des Was­ser­fall­mo­dells stammen“
WIE BITTE??? „For­ma­le Anfor­de­run­gen“ als „böser Was­ser­fall“??? Also: Besteht die „agi­le“ Lösung dar­in, Anfor­de­run­gen umfas­sen­der Sys­te­me nur auf Basis von Stich­wor­ten („Als … will ich … damit …“) zu beschrei­ben, die dann erst „on fly“ (also beim Pro­gram­mie­ren) mit dem dane­ben­sit­zen­den Benut­zer prä­zi­siert wer­den? Da waren wir ja bei XP mit dem CRC schon präziser…

Natür­lich haben die­sen Fra­gen ihre Berech­ti­gung, aber der Gedan­ke der mög­li­chen und sogar nöti­gen Absi­che­rung im Vor­feld ist fehl am Plat­ze. Die­se Fra­gen wer­den dann beant­wor­tet, wenn sie sich wirk­lich stellen.“
WIE BITTE??
Für das Rea­li­si­s­ie­ren von Web­shops für Weih­nachts­ker­zen mag das ja genü­gen, nicht aber für Sys­te­me mit hohen Risi­ko­po­ten­ti­al, die VORHGERIGER behörd­li­cher Prü­fun­gen bedürfen.
Ken Schwa­bers Scrum-Beschrei­bung von 1995 (agilix.nl/resources/scrum OOPSLA 95.pdf) ist da viel rea­lis­ti­scher, sie­he dort 4.1 und in 4.2.1 „Assess­ment of risk and appro­pria­te risk con­trols“ und in 4.2.2 „Per­form domain ana­ly­sis to the ext­ent requi­red to build, enhan­ce, or update the
domain models to reflect the new sys­tem con­text and requi­re­ments / Refi­ne the sys­tem archi­tec­tu­re to sup­port the new con­text and requirements“
Erst auf DIESER Basis kann inner­halb der Sprints das sinn­voll geleis­tet wer­den: „Risk is asses­sed con­ti­nuous­ly and ade­qua­te risk con­trols and respon­ses put in place.“

Das klingt zunächst nach mehr Auf­wand, ist es aber nicht, wenn man sich die über­flüs­si­gen Tro­cken­übun­gen zu Beginn in Form eines detail­lier­ten IT-Kon­zepts spart.“
Ein detail­lier­tes IT-Kon­zept habe ich in mei­nen rund 30 Jah­ren in der IT noch nie erlebt. Alle waren nur so weit aus­for­mu­liert als es mög­lich und nötig war. Die Details erga­ben sich auch frü­her immer schon im Rah­men der Rea­li­sie­rung. Lei­der wur­de deren Rück­wir­kun­gen auf das Kon­zept i.a. nicht doku­men­tiert – sodass die anschlies­sen­de War­tung kei­ne trag­fä­hi­ge Infor­ma­tio­nen mehr hat­te. Das ist aber kein Grund, nun auf sol­che Kon­zep­te zu ver­zich­ten! Die­ser Ver­zicht näm­lich führt zur schlech­te­ren Wart­bar­keit und Erwei­ter­bar­keit agil erstell­ter SW, sie­he vor­letz­te Zei­le in der Tabel­le auf Sei­te 120 in http://www.korn.ch/archiv/publikationen/Neuer-Wein-in-alte-Schlaeuche-oder-Deja-vu.pdf

Schnell kommt der Wunsch auf, die Sprints detail­liert mit Inhalt aus­zu­pla­nen, damit man genau weiß, wann wel­che Funk­tio­nen umge­setzt wer­den sollen.“
Bei klei­nen Vor­ha­ben mit Durch­lauf­zei­ten von bis zu 6 Mona­ten ist der wunsch nach­voll­zieh­bar und auch ver­nüf­tig – und zwar im sinn einer PLANUNG, nicht im Sinn einer Garan­tie (die nach mei­ner Erfah­rung auch kaum jemand fordert).
Bei gros­sen Vor­ha­ben wird dan auf mei­ner Erfah­rung nie gefor­dert – weil jeder weiss, dass das nicht funk­tio­niert. Erwar­tet aber wird – zu Recht etwas im Sinn der Punk­te 1 bis 5 in http://scaledagileframework.com/roadmap/

Sonst weiß man doch gar nicht was genau man am Ende bekommt. Ja, genau das ist die Idee! Weil man näm­lich vor­her gar nicht genau genug spe­zi­fi­zie­ren kann, was man braucht.“
WIE BITTE? DIE IT DARF DAS LIEFERN WAS SIE WILLKANN?
Wenn ein IT-Sup­pli­er nicht in der Lage ist, im Sinn der oe.e Punk­te 1 bis 5 Aus­sa­gen zum End­ergeb­nis zu machen, dann ist er schlicht­weg inkompetent.
Der zuneh­mend schlech­te Ruf von „agil“ beruht auf genau sochen als Aus­re­den gese­he­nen Aus­sa­gen: „man kann vor­her gar nicht genau genug spe­zi­fi­zie­ren was man braucht“.

Kein Bau­herr wür­de einen Bau­un­ter­neh­mer beauf­tra­gen, der so etwas sagt.… und schluss­end­lich für 1 Mio € eine Schre­ber­gar­ten­hüt­te erhält …

Dan­ke für die­sen aus­führ­li­chen Kom­men­tar, wenn­gleich ich ihn mir in einem etwas wert­schät­zen­de­ren Ton gewünscht hätte.

Ohne nun auf die ein­zel­nen Punk­te ein­zu­ge­hen, was den Rah­men hier spren­gen wür­de, ein paar Anmer­kun­gen zum Ver­ständ­nis. Ich bin der letz­te der sich für eine dog­ma­ti­sche und sche­ma­ti­sche Anwen­dung von Scrum nach Lehr­buch stark macht. Dar­um ging es mir nicht. Wir sind uns einig, dass das Vor­ge­hen zum Pro­jekt pas­send zuge­schnit­ten wer­den muss.

Dabei kann man es aber auch über­trei­ben und Scrum unzu­läs­sig ver­stüm­meln. Ins­be­son­de­re dort wo die umge­ben­de Orga­ni­sa­ti­on noch sehr klas­sisch tickt. Das mein­te ich mit for­ma­len Anfor­de­run­gen, also Arte­fak­te, die for­mal gefor­dert sind oder zur Absi­che­rung der betei­lig­ten Par­tei­en not­wen­dig erschei­nen. Das soll nun nicht hei­ßen, dass kri­ti­sche Tei­le (z.B. die genann­ten behörd­li­chen Anfor­de­run­gen) nicht früh­zei­tig abge­si­chert wer­den soll­ten, aber eben nicht alles und nur um der Form wil­len. Anfor­de­rungs­ma­nage­ment ist ein ganz ande­res The­ma, das im Scrum mei­ner Mei­nung nach sogar recht strin­gent und kon­se­quent erfolgt.

Ich woll­te nicht sagen, dass die IT lie­fern kann und darf, was sie will. Aber ich habe oft genug gese­hen, dass sich vie­le wich­ti­ge Anfor­de­run­gen erst auf dem Weg erge­ben und man tat­säch­lich nicht vor­her nicht voll­stän­dig sagen kann, was man am Ende brau­chen wird. Am Bau ist das übri­gens auch so: im Detail ergibt sich vie­les erst auf dem Weg.

Eine „unzu­läs­si­ge Ver­stüm­me­lung von Scrum“ gibt es nicht.
Jeg­li­che Ver­än­de­rung von Scrum führt – gemäss dem Wunsch von Ken und Jeff – zu etwas, das nicht „Scrum“ genannt wer­den darf.
Und ein – nicht Scrum genann­tes – Vor­ge­hen mit nur eini­gen Ele­men­ten von Scrum ist nur dann kon­tra­pro­duk­tiv, wenn die Ent­wick­lungs­er­geb­nis­se unge­nü­gend sind. Das liegt aber i.a. nicht m Vor­ge­hen als sol­chem son­dern an vie­len der „Craft­man­ship“ wider­spre­chen­den Praktiken. 

Ja – Detail­an­for­de­run­gen erga­ben sich immer schon „on fly“. Auch in Bau­pro­jek­ten etwa von EFHs. Und die­se wer­den nach wie vor „klas­sisch“ abge­wi­ckelt. Und den­noch funk­tio­niert das. Dass sie „in time & bud­get“ rea­li­siert wer­den ist die dabei auch die Regel, nicht die Aus­nah­me. Weil es eben eher klei­ne Pro­jek­te sind. Und die sind – auch in der IT – gemäss CHA­OS-Report signi­fi­kant erfolg­rei­cher als grosse. 

Bei Bau­pro­jek­ten ist der Anspruch an „Craft­manshhoip“ zusätz­lich auch sehr ausgeprägt.

Genau dort sehe ich das Kern­pro­blem der IT.
Und im Drang nach Grossprojekten.

Herr Korn lässt sei­nen Frust mal wie­der in ande­rer Leu­ten Blogs her­aus; wird das eige­ne nicht genü­gend beach­tet? Und wer sich auf den intrans­pa­ren­ten CHA­OS-Report beruft, kann auch gleich BILD zitieren…

Wenn ein Blog die Mög­lich­keit zur Dis­kus­si­on bie­tet, dann ist deren Nut­zung wohl kein „Ablas­sen von Frust“…
Und, ja: Der CHA­OS-Report ist recht umstrit­ten … wird aber den­noch ger­ne als Beweis des Nut­zens agi­ler Pro­jek­te gedeutet.

Agi­le Struk­tu­ren spie­geln vor allem eine Part­ner­schaft zwi­schen Auf­trag­ge­ber und Auf­trag­neh­mer zum gemein­sa­men Pro­jekt­er­folg wider. Der Auf­trag­ge­ber über­nimmt als Pro­duct owner Ver­ant­wor­tung für die fach­li­che Aus­ge­stal­tung der gewünsch­ten Funk­tio­nen, der Auf­trag­neh­mer ermög­licht das durch pas­sen­de, prag­ma­ti­sche Struk­tu­ren und schnel­les, ver­ständ­li­ches Feedback.

Hier liegt IMO auch das Pro­blem, denn in man­chen (gera­de gro­ßen) Pro­jek­ten ist von Part­ner­schaft nicht viel zu spü­ren. Wer als Auf­trag­ge­ber ängst­lich bemüht ist, mög­lichst alle eige­ne Ver­ant­wor­tung über Pflich­ten­hef­te, frem­de Kal­ku­la­tio­nen und Ver­trä­ge weg­zu­de­le­gie­ren, der kann nicht plötz­lich „agil“ arbei­ten. Wenn ein Kli­ma von Recht­fer­ti­gungs­druck und Miss­gunst den Auf­trag­ge­ber beein­flusst, dann wird sich das in Pro­jekt­struk­tu­ren nie­der­schla­gen, die zulas­sen, jeder­zeit mit dem Fin­ger auf ande­re zu zei­gen. Fes­te Bud­gets, defi­nier­te Beauf­tra­gun­gen und unver­rück­ba­re Zeit­plä­ne hel­fen da, davon pro­fi­tie­ren klas­si­sche Managementmethoden.

Es wird etwas leich­ter, wenn sich Auf­trag­ge­ber und ‑neh­mer in der glei­chen Orga­ni­sa­ti­on befin­den. „Agil“ funk­tio­niert somit bei inter­nen Pro­dukt­ent­wick­lun­gen bes­ser, weil die Metho­de hier leich­ter anzu­wen­den ist.

JA!

Die­se heu­te unter „agil“ sub­su­mier­ten Prin­zi­pi­en sind in der Orga­ni­sa­ti­ons­ent­wick­lung schon jahr­zente­lang bekann­te und dis­ku­tier­te Ideen. Eini­ge davon wur­den – aller­dings in ver­gleichs­wei­se weni­gen Fäl­len – erfolg­reich umgesetzt.
In nur weni­gen Fäl­len des­halb, weil der Ver­such, die­se Prin­zi­pi­en im Rah­men der mehr-heit­lich eta­blier­ten Füh­rungs­struk­tu­ren und Pro­jekt­kon­tex­ten (AGAN – Bezie­hung) ein im grund­sätz­lich ver­än­der­tes Den­ken und Han­deln erfor­dert. Die­ses ver­än­der­te Den­ken und Han­deln setzt vor­aus, dass begin­nend bei der Unternehmensspitze
o das „alles im Griff haben“ ersetzt ist durch ein „ver­trau­ens­vol­les Los­las­sen“. Also: „Kon­trol­le ist gut – Ver­trau­en ist besser“
o die Über­zeu­gung vor­herrscht, dass ein Unter­neh­men erst durch die fort­lau­fen­de Kon­ver­sa­ti­on aller das Unter­neh­men umfas­sen­den Mit­ar­bei­ten­den und Stake­hol­der ent­steht, nicht durch von oben ver­kün­de­te Visio­nen oder ver­ord­ne­te Strukturen. 

Die­se Vor­aus­set­zun­gen zu erfül­len ist jedoch sehr anspruchsvoll.

Dan­ke für den Kom­men­tar, der sich mit mei­ner Erfah­rung deckt. Letzt­lich ist es immer eine Fra­ge der Part­ner­schaft zwi­schen Auf­trag­ge­ber und Auf­trag­neh­mer. Wenn in die­ser Part­ner­schaft zu wenig Ver­trau­en vor­han­den ist, wird es ganz ganz schwie­rig mit dem gemein­sa­men agi­len Vorgehen.

Schreibe einen Kommentar