Scrumster

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 sei­ne Ar­beit sein kann.

Das Dilemma aus Don‘t Waste und Don’t Debt

Ein Ent­wick­lungs­team, das für pro­du­zier­te Ver­schwen­dung und für pro­du­zier­te tech­ni­sche Schuld ge­rügt wird, steckt in ei­nem fast aus­weg­lo­sen Di­lem­ma. Das ist gleich­be­deu­tend mit: Der Ei­mer, in dem nor­ma­ler­wei­se „was­te“ lan­det, wird mit ei­nem Schloss ver­se­hen und die tech­ni­sche Schuld muss vom Team da­her un­ter den Tep­pich ge­kehrt wer­den. Da aber bei­des in der Na­tur der Soft­wa­re­ent­wick­lung be­grün­det ist, muss ein of­fe­ner Um­gang mit die­sem Di­lem­ma ge­fun­den wer­den, an­statt es tot­zuschwei­gen.

Ab­bil­dung 10 Don’t Was­te und Don’t Dept

Sei stolz drauf

Ein wich­ti­ger Grad­mes­ser zur Be­wer­tung von „wor­king soft­wa­re“ darf an die­se Stel­le nicht un­ter­schla­gen wer­den. Das Ent­wick­lungs­team weiß am bes­ten, un­ter wel­chen Ent­beh­run­gen ein In­kre­ment ent­stan­den ist. Wenn das Team stolz auf sei­ne Ar­beit sein kann, dann ist das ein star­ker In­di­ka­tor für „wor­king soft­wa­re“.

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.