Scrumster. Achim Schneider

aus Ent­wick­lungs­sicht mit dem Pro­duct Ow­ner ab.

      Extreme Programming

      Der Be­griff „wor­king soft­wa­re“ wur­de durch die agi­le Me­tho­de des Ex­tre­me Pro­gram­ming ge­prägt. Dort be­deu­tet er, dass eine Soft­wa­re voll in­te­griert, ge­tes­tet, zum Kun­den aus­ge­lie­fert oder in der Pro­duk­ti­ons­um­ge­bung in­stal­liert wer­den kann.

      Ab­bil­dung 6 Ex­tre­me Pro­gram­ming

      Das be­deu­tet aber nicht, dass die­se Soft­wa­re feh­ler­frei läuft und frei von Ab­stür­zen ist. Es be­deu­tet nur, dass Unit Tests ge­macht und grund­le­gen­de Qua­li­täts­si­che­rung be­trie­ben wur­den und man sich da­von über­zeugt hat, dass sie grund­sätz­lich läuft. Ob die­se „ex­tre­me“ Fest­le­gung eine für Ihre Ver­hält­nis­se adäqua­te De­fi­ni­ti­on von „wor­king soft­wa­re“ ist, müs­sen Sie für sich prü­fen.

      Mogeln ist verlockend

      Vie­le Scrum Teams ma­chen zu­sätz­lich den Feh­ler, bei der Be­wer­tung ih­res Sprin­t­er­geb­nis­ses zu mo­geln. Bei­spiels­wei­se wird halb­fer­ti­ge Soft­wa­re, die z.B. mit tech­ni­schen Schul­den („tech­ni­cal debt“) be­las­tet ist, als „wor­king soft­wa­re“ de­kla­riert, ohne dass eine User Sto­ry zur Be­sei­ti­gung der tech­ni­schen Schuld mit dem Pro­duct Ow­ner ver­ein­bart und in den Pro­duct Back­log ein­ge­s­tellt wird. Das ist dann so, als hät­te das Team die tech­ni­sche Schuld un­ter den Tep­pich ge­kehrt.

      Ab­bil­dung 7 Tech­ni­cal debt

      Das führt dazu, dass das Ma­na­ge­ment an­nimmt, dass et­was ab­ge­schlos­sen ist und kei­ne späte­ren In­ve­s­ti­tio­nen mehr be­nötigt, was real be­trach­tet nicht stimmt.

      Transparenz gewinnt

      Die Grün­de da­für, dass die Soft­wa­re am Ende ei­nes Sprints nicht wirk­lich fer­tig ist, sind viel­schich­tig, aber letzt­lich doch un­er­heb­lich. Ent­schei­dend für alle Be­tei­lig­ten ist, dass das Scrum Team am Ende je­des Sprints scho­nungs­los trans­pa­rent macht, was funk­tio­niert und was nicht. Schön­re­den ist zwar ver­lockend, aber nicht die Lö­sung. Das holt einen später wie­der ein.

      Tipps zu Wor­king Soft­wa­reSor­gen Sie für Trans­pa­renz bei der Be­reits­tel­lung von wor­king soft­wa­re.

      Typisch „working“

      Auf dem Bild „Wor­king Soft­wa­re“ ist eine ty­pi­sche, als „wor­king“ de­kla­rier­te Soft­wa­re ab­ge­bil­det. Die­se wird von al­len Sei­ten ge­stützt, ist zu­sam­men­ge­flickt, weist Lücken oder Löcher wie ein Schwei­zer Käse auf und passt an den Schnitts­tel­len kaum zu­sam­men. Wird dies nicht trans­pa­rent ge­macht, so löst dies eine Ket­ten­re­ak­ti­on aus.

      Push oder Pull

      Wie kommt es ei­gent­lich in agil ar­bei­ten­den Teams dazu, dass et­was fer­tig wird? Der we­sent­li­che Un­ter­schied zur gän­gi­gen Ar­beits­wei­se ist, dass Ar­beit nicht „zu­ge­wie­sen“ wird (Push-Prin­zip). Es gibt nie­man­den, der den Team­mit­glie­dern eine Auf­ga­be zu­teilt. Viel­mehr ho­len sich die Team­mit­glie­der die Auf­ga­ben aus dem Back­log, so­bald sie da­für Ka­pa­zi­täten zur Ver­fü­gung ha­ben (Pull-Prin­zip). Wann eine Auf­ga­be zur Be­ar­bei­tung aus­ge­wählt wird, hängt da­mit vom in­di­vi­du­el­len Fort­schritt der Team­mit­glie­der und vom Fort­schritt des gan­zen Teams ab.

      Ab­bil­dung 8 Push- oder Pull-Prin­zip

      Unfertiges vermeiden

      Aus der tra­di­tio­nel­len Fer­ti­gungs­in­dus­trie wis­sen wir, dass un­fer­ti­ge Pro­duk­te ge­bun­de­nes Ka­pi­tal dars­tel­len. Da­her ist je­des Fer­ti­gungs­un­ter­neh­men be­strebt, den Be­stand an nicht fer­tig­ge­s­tell­ten Er­zeug­nis­sen mög­lichst ge­ring zu hal­ten. Ein an­de­res Bei­spiel wäre: Es soll eine Brücke über einen Fluss ge­baut wer­den. Un­ge­fähr zur Hälf­te der Bau­zeit be­schließt das Team, mit dem Bau ei­ner zwei­ten Brücke zu be­gin­nen. Das führt dazu, dass der Bau an der ers­ten Brücke lang­sa­mer vor­an­geht und an der zwei­ten Brücke nicht mit vol­ler Kraft ge­baut wer­den kann. Die in die Brücken in­ve­s­tier­te Ar­beit kann nicht dazu ge­nutzt wer­den, den Fluss zu über­que­ren. Sie kön­nen sich vors­tel­len, was pas­siert, wenn Sie den Bau ei­ner drit­ten Brücke par­al­lel be­gin­nen.

      Über­tra­gen auf die agi­le Soft­wa­re­ent­wick­lung be­deu­tet dies, dass eine an­ge­fan­ge­ne Auf­ga­be Ka­pi­tal bin­det. So­lan­ge die Auf­ga­be nicht fer­tig­ge­s­tellt wur­de, kann die in die Auf­ga­be in­ve­s­tier­te Ar­beit in kei­nen Nut­zen um­ge­wan­delt wer­den. Der Nut­zen hat hier na­tür­lich zwei Aspek­te. Zum einen ist der Nut­zen ge­meint, den po­ten­ti­el­le Kun­den aus dem fer­tig­ge­s­tell­ten Pro­dukt er­zie­len kön­nen, und zum an­de­ren ist na­tür­lich der po­ten­ti­el­le Ge­winn ge­meint, der mit der Ver­mark­tung des fer­tigs­tell­ten Pro­dukts er­zielt wer­den kann. Da­her sind un­fer­ti­ge Tasks so­zu­sa­gen eine „Ver­schwen­dung“. Je län­ger eine Auf­ga­be im Zu­stand „un­fer­tig“ ver­bleibt, umso größer wird die­se „Ver­schwen­dung“. Ge­nau das ist mit dem agi­len Be­griff „was­te“ ge­meint.

      Ab­bil­dung 9 Stän­dig neue Brücken bau­en

      Agi­le Teams sol­len da­her das Prin­zip ver­fol­gen, Auf­ga­ben eher fer­tig­zus­tel­len, statt im­mer neue Auf­ga­be an­zu­fan­gen. Das wird mit „start fi­nis­hing – stop star­ting“ ein­präg­sam auf den Punkt ge­bracht.

      Work in Progress

      Im vo­ri­gen Ab­schnitt wur­de dar­ge­s­tellt, dass un­fer­ti­ge Tasks ver­mie­den wer­den sol­len, da un­fer­ti­ge Auf­ga­ben Ka­pi­tal bin­den. Ein In­stru­ment agi­ler Me­tho­den zur Ver­mei­dung von „was­te“ ist da­her die Be­gren­zung der An­zahl gleich­zei­tig „in Be­ar­bei­tung“ be­find­li­cher Auf­ga­ben. Das be­zeich­nen die agi­len Me­tho­den mit „Li­mit Work in Pro­gress (WiP)“. Rein wirt­schaft­lich be­trach­tet stellt eine Be­gren­zung der gleich­zei­tig in Ar­beit be­find­li­chen Tasks eine wirk­sa­me Maß­nah­me zur Be­gren­zung des ge­bun­de­nen Ka­pi­tals dar. Für ein agi­les Team be­deu­tet dies aber die Mög­lich­keit, sich auf die we­sent­li­chen Din­ge zu kon­zen­trie­ren. Es ist nicht ein­fach, die we­sent­li­chen Din­ge zu iden­ti­fi­zie­ren, da­her soll­te das Team sich dar­über aus­tau­schen und zu­min­dest die we­sent­li­chen Aspek­te in „wor­king soft­wa­re“ ver­wan­deln.

      Tipps zu Wor­king Soft­wa­reSchaf­fen Sie ein Kli­ma, in dem man wie­der stolz auf