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 Unbrauch­bar­keit.

Mache die Din­ge so ein­fach wie mög­lich – aber nicht ein­fa­cher.
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 Sei­ten.

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 Pla­nung.

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

Auf dem Laufenden bleiben

Du willst kei­nen Arti­kel mehr ver­pas­sen? Mit mei­nem News­let­ter bekommst du in der Regel ein­mal wöchent­lich die neu­es­ten Arti­kel direkt in dei­nen Ein­gangs­korb.

8 Kommentare

Die Vor­ge­hens­wei­se im Pro­jekt muss pas­send sein und nicht stan­dar­di­siert.“
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 Unbrauch­bar­keit.“
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üh­ren.
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­manship) 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 Sei­ten.“

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­bele­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 ein­fa­cher.

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“
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ä­zi­ser…

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.“
WIE BITTE??
Für das Rea­li­si­sie­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ür­fen.
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 extent 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 requi­re­ments“
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 sol­len.“
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 for­dert).
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 WILL / KANN?
Wenn ein IT-Sup­plier 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 inkom­pe­tent.
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ät­te.

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­manship“ wider­spre­chen­den Prak­ti­ken.

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 gros­se.

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

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

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 zitie­ren…

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 gedeu­tet.

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 Feed­back.

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 Manage­ment­me­tho­den.

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 jahrz­en­te­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 umge­setzt.
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 Unter­neh­mens­spit­ze
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 bes­ser“
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 Sta­ke­hol­der ent­steht, nicht durch von oben ver­kün­de­te Visio­nen oder ver­ord­ne­te Struk­tu­ren.

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

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 Vor­ge­hen.

Schreibe einen Kommentar