Scrum und XP im harten Projektalltag

18 | SCRUM UND XP IM HARTEN PROJEKTALLTAG
Warum sind wir hier so restriktiv?
Meine Erfahrung zeigt mir, dass es eigentlich immer eine schlechte Idee
ist, die interne Qualität zu opfern. Die langfristigen Kosten heben die
anfängliche Zeitersparnis mehr als auf. Toleriert man erst einmal eine
schlechtere Codequalität, ist diese auch später nur schwer wieder
herstellbar.
Besser ist es, den Anforderungsumfang zu diskutieren und zu sagen
"Wenn es wichtig ist, das Feature schnell auszuliefern, wie wäre es dann
mit einer Reduzierung des Umfang, damit wir schneller fertig sind? Eine
Möglichkeit wäre z.B. eine vereinfachte Fehlerbehandlung. Die Story
"Erweitere Fehlerbehandlung" liefern wir später nach. Oder wir
priorisieren andere Stories herunter, um uns auf diese konzentrieren zu
können?"
Merkt der Product Owner erst einmal, dass die interne Qualität nicht
verhandelbar ist, lernt er oft, recht geschickt mit den anderen Größen zu
jonglieren.
Wenn das Meeting kein Ende findet…
Am schwierigsten sind Sprint-Planungsmeetings, bei denen zwar
1) alle glauben, das Meeting schnell abschließen zu können
2) ... und es dann doch nicht tun!
Alles bei Scrum hat feste Anfangs- und Endzeiten, so genannte Zeitboxen.
Wir versuchen diese – wie ich finde – wunderbare und einfache Regel
auch zu beherzigen.
Aber was tun Sie, wenn sich das Sprint-Planungsmeeting seinem Ende
zuneigt und man sich weder auf ein Sprint-Ziel noch auf ein Sprint
Backlog geeinigt hat? Hört man dann einfach auf? Verlängert man um
eine weitere Stunde oder macht am nächsten Tag ein Folgemeeting?
Gerade bei neuen Teams passiert das gar nicht so selten. Ich weiß nicht,
was Sie machen, aber wir brechen das Meeting abrupt ab. Schluss! Aus!
Dann leidet eben der Sprint! Meist sage ich dem Team: "Das Meeting ist
in zehn Minuten vorbei und wir haben nicht wirklich viel geplant. Lassen
wir es damit bewenden oder machen wir morgen früh zwischen acht und
zwölf noch mal ein Folgemeeting?" Die Antwort ist nicht schwer zu
erraten, oder?