Kitabı oku: «Scrumster», sayfa 2

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­rePrü­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­reDe­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­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“.

Platz 9 - Self-organizing Team
Von Helden und Sagen

Die sich selbst or­ga­ni­sie­ren­den Teams sol­len be­wir­ken, dass Hel­den, die das Pro­jekt am Ende ret­ten, nicht mehr be­nötigt wer­den. Schließ­lich iden­ti­fi­ziert sich das gan­ze Scrum Team mit der Auf­ga­be und hat die vol­le Ent­schei­dungs­be­fug­nis und vol­le Ver­ant­wor­tung für das Er­geb­nis. So­weit die Theo­rie.

Wer hat die Verantwortung?

Wenn man sich das oben ge­sag­te ge­nau­er über­legt, ist das eine rie­si­ge Ver­ant­wor­tung, die auf ei­nem Scrum Team las­tet. Dies muss man da­her ge­nau­er be­trach­ten. Das Ent­wick­lungs­team hat si­cher­lich die fach­li­che Ver­ant­wor­tung für das pro­du­zier­te Er­geb­nis. Die kom­mer­zi­el­le Ver­ant­wor­tung be­fin­det sich in der Rea­li­tät, aber meis­tens au­ßer­halb des Scrum Teams. Die­se wird vom Pro­dukt­ma­na­ger, der Busi­ness Unit oder dem Spon­sor wahr­ge­nom­men, die aber nicht wirk­lich Teil des Scrum Teams sind. Das sind wich­ti­ge Sta­ke­hol­der.

Tipps zu Self-Or­ga­ni­zing TeamKlären Sie, wie weit die Kom­pe­ten­zen des sich selbst or­ga­ni­sie­ren­den Teams rei­chen.

Wer soll das managen?

Ma­na­ge­ment ist viel zu wich­tig, als dass man es al­lei­ne den Ma­na­gern über­las­sen soll­te. Selbst­or­ga­ni­sa­ti­on be­deu­tet Selbst­ma­na­ge­ment. Das be­deu­tet dann kon­se­quen­ter Wei­se auch, dass ein Team nicht mehr auf „Ma­na­ge­men­tent­schei­dun­gen“ war­ten muss. Das al­ler­dings geht vie­len Ma­na­gern heu­te noch zu weit. Sie se­hen: oft klaf­fen hier An­spruch und Wirk­lich­keit aus­ein­an­der. Was bei Ih­nen gilt, müs­sen Sie mit Ih­rem Um­feld klären. Über­le­gen Sie auch, wann Sie Ihr Ma­na­ge­ment über wich­ti­ge Ent­schei­dun­gen in­for­mie­ren oder wann Sie den Rat des Ma­na­ge­ments ein­ho­len.

Über Motivation

Wor­aus be­zieht also ein agi­les Team die Mo­ti­va­ti­on, sich mit ei­ner Auf­ga­be zu iden­ti­fi­zie­ren? Die Prin­zi­pi­en des agi­len Ma­ni­fests ge­hen da­von aus, dass die Mit­ar­bei­ter ei­nes agi­len Teams grund­sätz­lich schon mo­ti­viert sind. Dort heißt es: „er­rich­te Pro­jek­te rund um mo­ti­vier­te In­di­vi­du­en“. So weit, so gut. Aber wo­her kommt die so als selbst­ver­ständ­lich vor­aus­ge­setzte Mo­ti­va­ti­on?

Ab­bil­dung 11 Mo­ti­va­ti­on

Eine wei­te­re Quel­le für Mo­ti­va­ti­on soll der Wett­streit nach tech­ni­scher Ex­zel­lenz, der bes­ten Ar­chi­tek­tur und dem bes­ten De­sign sein. Ohne mo­ti­vier­te Mit­ar­bei­ter funk­tio­niert also gar nichts.

Woher kommt Motivation?

Hier ist auch das Ma­na­ge­ment ge­for­dert, eine At­mo­sphä­re im Un­ter­neh­men zu schaf­fen, da­mit die Mit­ar­bei­ter eine aus­rei­chen­de Grund­mo­ti­va­ti­on mit­brin­gen. Dies kann z.B. durch einen Führungs­s­til er­reicht wer­den, der den Ma­na­ger zum Un­ter­stüt­zer und För­de­rer sei­ner Mit­ar­bei­ter macht. Das Zau­ber­wort heißt hier „lean ma­na­ge­ment“ oder „ser­vant lea­der“. Aber die größte Mo­ti­va­ti­ons­quel­le ist, wenn man stolz auf sei­ne Ar­beit sein kann und dies re­spek­tiert wird.

Motivation für Veränderung

In ei­ner Welt, die stän­di­gen Ver­än­de­run­gen aus­ge­setzt ist, wird die Gabe, sich auf die­se Ver­än­de­run­gen schnell ein­zus­tel­len, zum Wett­be­werbs­vor­teil. Der Grund­ge­dan­ke da­bei ist, dass in ei­ner nach agi­len Me­tho­den ar­bei­ten­den Welt be­son­ders schnell auf Ver­än­de­run­gen rea­giert wer­den kann, weil je­der Mit­ar­bei­ter selbst für die nöti­gen Ver­bes­se­run­gen sorgt. Das Ma­na­ge­ment kann nicht mehr jede ein­zel­ne Ver­bes­se­rung vor­ge­ben. Nur die­je­ni­gen, die die Ar­beit im De­tail ken­nen und aus­führen, ha­ben aus­rei­chend Ein­blick, um schnell ge­nug Ver­bes­se­run­gen zu iden­ti­fi­zie­ren und um­zu­set­zen.

Wer muss Veränderungen beherrschen?

Die Fähig­keit ei­ner Or­ga­ni­sa­ti­on zur stän­di­gen Ver­bes­se­rung ist heu­te ein wich­ti­ger Er­folgs­fak­tor für Un­ter­neh­men. Und Ver­bes­se­rung kann meist nur da­durch entste­hen, in­dem man sich oder sei­ne Ar­beits­wei­se selbst an­passt. Die­se ei­ge­ne An­pas­sung muss von in­nen her­aus entste­hen, ohne dass das Ma­na­ge­ment die­se vor­gibt, sonst wäre die Re­ak­ti­ons­zeit der Or­ga­ni­sa­ti­on zu trä­ge und der Wett­be­werb hät­te einen Vor­teil. Um die Wir­kung der ei­ge­nen An­pas­sung zu ma­xi­mie­ren, ist es wich­tig, dass alle dar­an teil­ha­ben und in die glei­che Rich­tung zie­hen, also die glei­che Aus­rich­tung ha­ben und ver­fol­gen. Die Lea­der­ship-Theo­rie hat da­für den Be­griff „Ali­gnment“ ge­prägt. Die Auf­ga­be der Führungs­kräf­te ver­än­dert sich da­durch. Im agi­len Ar­beit­sum­feld ist statt ei­nes „Zucker­brot- und Peit­sche-Ma­na­ge­ments“ eher ein Ma­na­ge­ment ge­fragt, das auf Ver­trau­en und Selbst­or­ga­ni­sa­ti­on setzt.

Tipps zu Self-Or­ga­ni­zing TeamOhne Grund­mo­ti­va­ti­on ist es schwie­rig, da­her bin­den Sie das Li­ni­en-Ma­na­ge­ment ein.

Dies ist ein ge­wal­ti­ger Ver­än­de­rungs­pro­zess, der vom Ma­na­ge­ment und in den Köp­fen der Ma­na­ger voll­zogen wer­den muss. Eine In­stal­la­ti­on von ein paar, nach ei­nem agi­len Fra­me­work ar­bei­ten­den Teams ist also we­nig er­folgs­ver­spre­chend, wenn par­al­lel dazu kei­ne Ver­än­de­rung in der Ma­na­ge­ment­kul­tur ein­her­geht.