Mit Scrum Trans­pa­renz schaffen

Wenn der inter­es­sier­te Anwen­der ein Scrum-Buch in die Hand nimmt und sich über das The­ma infor­miert, so wird er doch in den meis­ten Fäl­len zu der Erkennt­nis kom­men, dass es ja eine total ein­fa­che und sinn­vol­le Metho­dik ist. Dem Ent­wick­ler bie­tet sie vie­le Frei­hei­ten, dem Auf­trag­ge­ber eine Lösung, die ganz sei­nen Wün­schen ent­spricht. War­um funk­tio­niert es dann doch nicht immer mit Scrum?

Der Pro­duct Owner beschreibt in Umgangs­spra­che, wel­che Fea­tures er haben möch­te, die Ent­wick­ler kön­nen – ganz im Sin­ne ihrer Tätig­keits­be­schrei­bung – abso­lut selbst­or­ga­ni­siert die Umset­zung kon­zi­pie­ren und letzt­end­lich erstel­len. Den­noch kom­men schein­bar nicht alle mit die­ser Arbeits­wei­se gut klar. War­um ist das so, und war­um ist es dann doch so schwer, das an sich ein­fa­che Regel­werk von Scrum prak­tisch umzu­set­zen und erfolg­reich in einem Team zu implementieren?

Zwei Fak­to­ren sind es, die der Imple­men­tie­rung der Metho­dik im Wege ste­hen und mei­ner Mei­nung nach stark zusam­men­hän­gen. Der eine Fak­tor ist die Bequem­lich­keit, der ande­re die Intrans­pa­renz der Arbeit. Was aber kann an Scrum unbe­quem sein, sodass die Ein­füh­rung pas­siv oder aktiv boy­kot­tiert wird?

Stel­len wir uns eine „klas­si­sche“ Ent­wick­lungs­um­ge­bung vor. Der Pro­dukt­ma­na­ger möch­te ein Leis­tungs­merk­mal haben, ohne genau zu beschrei­ben, was wirk­lich gewünscht ist. Er hat nur eine unge­fäh­re Idee in sei­nem Kopf und teilt die­se mehr oder weni­ger genau mit. Der Ent­wick­ler nimmt die­sen Wunsch dank­bar an und beginnt nun mit der Imple­men­tie­rung. Er kann sei­ner Fan­ta­sie frei­en Lauf las­sen und mal hier, mal dort etwas pro­gram­mie­ren, da ja nichts wirk­lich vor­ge­ge­ben ist außer einer vagen Umschrei­bung. Aus sei­ner Bequem­lich­keits­zo­ne her­aus kann er sich die inter­es­san­ten Auf­ga­ben­be­rei­che her­aus­pi­cken und dar­an fast belie­big lan­ge arbei­ten. Denn, was nicht spe­zi­fi­ziert ist, kann auch nie wirk­lich fer­tig sein. Dem Pro­dukt­ma­na­ger wird irgend­wann eine Lösung prä­sen­tiert. Die­ser, froh dar­über, dass sich jemand (und nicht er selbst) Gedan­ken über sein Fea­ture gemacht hat, nickt das Werk im schlimms­ten Fall ein­fach nur ab und bei­de sind glücklich.

Das Gan­ze kann dann ewig so wei­ter gehen. Bei­de haben es bequem und arbei­ten stark undurch­sich­tig: Der Ent­wick­ler, weil er stän­dig beschäf­tigt ist und irgend­et­was macht; Der Pro­dukt­ma­na­ger, weil man nicht genau weiß, wie das Gesamt­kon­zept ist. Kommt die Dead­line näher, wer­den ein­fach eini­ge Über­stun­den ein­ge­legt und etwas produziert.

Mit Scrum bekom­men bei­de oben beschrie­be­nen Rol­len eini­ge Pro­ble­me: Der Pro­dukt­ma­na­ger muss sich nun stär­ker mit dem zu pro­du­zie­ren­den Paket befas­sen und ein Fea­ture-Back­log erstel­len. Mehr noch, er muss die gro­ben Wün­sche und Gedan­ken in fein­gra­nu­la­re Sto­ries zer­le­gen und sich auch Abnah­me­kri­te­ri­en über­le­gen. Er muss, basie­rend auf den Back­log-Ele­men­ten, einen Release­plan erstel­len und in jeder Ite­ra­ti­on Anpas­sun­gen vor­neh­men und umprio­ri­sie­ren, um die­sen auch ein­hal­ten zu können.

Der Ent­wick­ler wie­der­um bekommt nun meh­re Back­log-Ele­men­te in Form von meh­re­ren User-Sto­ries vor die Nase gesetzt. Die­se Anzahl die­ser Ele­men­te in der Ite­ra­ti­on hängt jetzt von sei­ner Kom­ple­xi­täts­schät­zung ab und er hat einen fes­ten Ter­min für ihre Fer­tig­stel­lung – näm­lich das Sprin­ten­de. Zwar hat er alle Frei­hei­ten bei der Kon­zep­ti­on und Umset­zung. Aber nur solan­ge, wie damit die fest vor­ge­ge­be­nen Abnah­me­kri­te­ri­en erfüllt wer­den – und das Sprin­ten­de ist stets greif­bar nahe.

Bei­de Per­so­nen müs­sen jetzt also ihre undurch­sich­ti­ge Zone der Bequem­lich­keit ver­las­sen und ordent­li­che Ergeb­nis­se vor­wei­sen. Beim Pro­dukt­ma­na­ger (Pro­duct Owner) ist das ein ent­spre­chend gefüll­tes und aus­ge­ar­bei­te­tes Back­log. Er kann nicht mehr die letz­ten Fein­hei­ten der Sto­ry dem Ent­wick­ler über­las­sen, weil die­ser eine so vage defi­nier­te User­sto­ry nicht schät­zen kann und somit ablehnt. Der Ent­wick­ler schul­det wie­der­um ein Leis­tungs­merk­mal, das genau den Akzep­tanz­kri­te­ri­en ent­spricht und vom Pro­duct Owner auch peni­bel abge­nom­men wird. Wegen der begrenz­ten Sprint­län­ge kann er nun nicht mehr noch hier und da etwas „schrau­ben“ son­dern muss den Zeit­plan ein­hal­ten. Denn davon hängt der Release­plan des Pro­dukt Owners ab.

Die bei­den aus die­ser Zone zu bewe­gen, ist die undank­ba­re Auf­ga­be des Scrum­Mas­ters, die lang und mühe­voll sein kann und viel Über­zeu­gungs­ar­beit not­wen­dig macht. Freun­de macht sich der Scrum­Mas­ter damit erst ein­mal nicht. Oft möch­ten die Leu­te ihre beque­men Zonen nicht oder nur sehr ungern ver­las­sen und stel­len sich daher bei der Imple­men­tie­rung von Scrum quer.

Zumin­dest kann man aber schon früh fest­stel­len, dass auch hier Scrum erfolg­reich ist, weil es die­sen Miss­stand scho­nungs­los auf­zu­de­cken ver­mag. Und genau das ist es, was die Arbeit des Scrum­Mas­ters so span­nend macht. Die­se Her­aus­for­de­rung neh­men wir nur zu ger­ne an!

Wie man die bei­den Scrum-Team-Mitg­lei­der wie­der auf Kurs brin­gen kann, ist eine ande­re Geschichte.