Tritium-Design

Bei der letzten Retrospektive eines Projektes bin ich über den Begriff Sashimi gestolpert. Hierbei handelt es sich im Scrum-Kontext um den Vergleich des Softwareproduktes mit der Darreichungsform der japanischen Küche, bei dem das Endprodukt aus vielen einzelnen Teilen (dünn geschnittene Fischfiletstreifen) zusammengesetzt ist.

Nach dem Scrum-Prinzip sollen also alle Teile des Endproduktes gleichmäßig den Entwicklungszyklus durchlaufen, bis sie zu dem gewünschten Endergebnis führen. Hiermit soll sichergestellt werden, dass mit Ende jedes Sprints eine stabile Version der Software ausgeliefert werden kann.
Das klingt soweit eigentlich sehr vernünftig.

Jetzt kommt jedoch der Haken: Wenn man einen stabilen Stand am Ende jedes Sprints erreicht haben will (es existieren also keine die Auslieferung behindernden Bugs mehr), so muss bereits im Vorfeld eine ausreichende Menge an Zeit für die Behebung eventuell auftretender Fehler berücksichtigt werden. Ein hehres Ziel, denn Fehler kann niemand vorhersehen und Fehler die auf Seiteneffekten beruhen schon gar nicht.
Eskalation ist das beliebte Zauberwort – also die Kommunikation des Problems und die Aufstockung des Entwicklerpersonals um im Zeitplan zu bleiben. Doch ist da dann die Frage, wenn eine Frau 9 Monate schwanger ist – wie lange sind dann 10 Frauen schwanger? Oder ob zu viele Köche nicht doch den Brei verderben. Nicht immer ist eine Personalaufstockung also die Lösung des Problems.

Was also tun?
Eine mögliche Antwort wäre sich als Entwicklerteam nicht bei zu vielen Tasks zu committen. Um ein gutes Maß dafür zu finden, sollte man versuchen bei der Aufwandsschätzung einen gewissen Prozentsatz (30%-50%) draufzuschlagen, um so im Mittel ein genügend großes Polster für Unvorhergesehens zu behalten. Wenn man dann in einer abstrakten Größe wie Featurepoints und nicht in Arbeitstagen misst, so sollte man versuchen eine Entsprechung der Größen zu finden, um daraus den Gesamtzeitaufwand des Sprints abschätzen zu können. Liegt dieser über dem vereinbarten Sprintzeitraum, so muss entschieden werden, ob eine Personalaufstockung hilfreich sein kann oder ob die Tasks descoped werden sollten.

Das ist zumindest mein Eindruck als relativer Scrum-Neuling. Ich werde versuchen dieses beim nächsten Planning vorzuschlagen und bin gespannt, ob wir dann die angestrebten japanischen Häppchen an jedem Sprintende erreichen.