Platz 10 - Working Software

Funk­tio­nie­ren­de Soft­wa­re ist schon im agi­len Ma­ni­fest pro­kla­miert und eine Grund­vor­aus­set­zung agi­ler Me­tho­den, um er­mit­teln zu kön­nen oder bes­ser ge­sagt, um mes­sen zu kön­nen, was man schon er­reicht hat.

Bewährtes in neuem Look

Ganz neu ist die­se Er­kennt­nis al­ler­dings nicht. Ins klas­si­sche Pro­jekt­ma­na­ge­ment über­tra­gen han­delt es sich hier­bei um „ear­ned va­lues“ oder auf Deutsch den „Fer­tigs­tel­lungs­grad“, ein Werk­zeug des Pro­jekt­con­trol­lings, um den Pro­jekt­fort­schritt zu ver­fol­gen. Eine Be­wer­tung des Pro­jekt­fort­schritts er­folgt in agi­len Me­tho­den wie Scrum am Ende je­des Sprints.

Die agi­le Grun­d­an­nah­me

Je­der Sprint stellt eine In­ve­s­ti­ti­on dar und ver­folgt das Ziel, dem er­hoff­ten Er­geb­nis einen Schritt näher zu kom­men.

Ab­bil­dung 5 Die agi­le Grun­d­an­nah­me

Nach je­dem Sprint soll in agi­len Vor­ge­hens­mo­del­len über­prüft wer­den, was tat­säch­lich er­reicht wur­de. Das so ent­stan­de­ne agi­le Ar­te­fakt ist „wor­king soft­wa­re“. Un­sicht­bar und nur in der un­be­wuss­ten Wahr­neh­mung der Be­tei­lig­ten be­fin­det sich die agi­le Grun­d­an­nah­me. Es wird grund­sätz­lich da­von aus­ge­gan­gen, dass In­ve­s­ti­tio­nen, die „funk­tio­nie­ren­de Soft­wa­re“ als Er­geb­nis ha­ben, dau­er­haft er­hal­ten blei­ben, weil Soft­wa­re, die ein­mal funk­tio­niert, kei­nem „Ver­schleiß“ un­ter­liegt. Ein­mal von der War­tung die­ser Soft­wa­re ab­ge­se­hen, ist das die agi­le Grun­d­an­nah­me.

Trifft das eigentlich zu?

Ob die­se Grun­d­an­nah­me tat­säch­lich zu­trifft, hängt nun im We­sent­li­chen von Ih­rem Um­feld ab, in dem Sie sich be­we­gen. Ein Sprint wird in al­ler Re­gel zu­nächst in ei­ner Ent­wick­lungs­um­ge­bung entste­hen. Ob in die­ser Um­ge­bung auch die Be­wer­tung hin­sicht­lich „wor­king soft­wa­re“ an­ge­s­tellt wird oder nicht, bes­timmt maß­geb­lich, ob schon alle nöti­gen In­ve­s­ti­tio­nen ge­tätigt sind oder nicht.

Tipps zu Wor­king Soft­wa­re
Prü­fen Sie, wel­che un­aus­ge­spro­che­nen An­nah­men in Ih­rem Um­feld exis­tie­ren und fin­den Sie einen trans­pa­ren­ten Um­gang da­mit.

Legen Sie es doch fest

Der Be­griff „wor­king soft­wa­re“ muss also für Ihre Ver­hält­nis­se de­fi­niert wer­den, da­mit je­dem klar ist, was er be­deu­tet und was eben nicht. Ein Bei­spiel hier­für könn­te sein:

Wor­king soft­wa­re be­deu­tet für uns, dass das Pro­dukt in der Ent­wick­lungs­um­ge­bung in­stal­liert und be­nutz­bar ist.

Will man das noch deut­li­cher for­mu­lie­ren, kann man auch be­schrei­ben, was nicht un­ter „wor­king soft­wa­re“ zu verste­hen ist:

Wor­king soft­wa­re hat bei uns die Ei­gen­schaf­ten, dass die­se noch nicht auf ei­ner „Sta­ging-Um­ge­bung“ (Test-, In­te­gra­ti­ons-, Re­fe­renz- oder Pro­duk­ti­vum­ge­bung) be­reit­ge­s­tellt wur­de, noch nicht an den späte­ren Be­trei­ber über­ge­ben wur­de und noch nicht mit ei­nem Bes­tell- und Ab­rech­nungs­pro­zess ver­se­hen ist und da­mit noch kei­nen kom­mer­zi­el­len Bei­trag zum Ge­schäft­s­er­geb­nis lie­fern kann.

Weitere „working“ Aspekte

Ab­hän­gig von Ih­rem Um­feld tref­fen hier wei­te­re oder an­de­re Aspek­te zu. So­fern kei­ne kla­re und von al­len Be­tei­lig­ten ver­stan­de­ne und ak­zep­tier­te De­fi­ni­ti­on von „wor­king soft­wa­re“ vor­han­den ist, be­we­gen Sie sich auf höchst ris­kan­tem Bo­den.

Tipps zu Wor­king Soft­wa­re
De­fi­nie­ren Sie „wor­king soft­wa­re“. Ho­len Sie in Ih­rem Um­feld die Ak­zep­tanz zur De­fi­ni­ti­on von „wor­king soft­wa­re“ ein und er­gän­zen Sie da­mit Ihre De­fi­ni­ti­on of Done. Stim­men Sie zu­sätz­li­che Back­log-Ein­trä­ge für „wor­king soft­wa­re“ 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­re
Sor­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...