ScrumDay2009 in München

Bärbel de BouvierBoris Gloger hat auf seinem Blog eine kurze Zusammenfassung zum Scrum-Tag in München geschrieben. Ein Zitat aus seinem Beitrag macht Mut für alle, die noch mit Scrum und anderen agilen Techniken kämpfen. Man muss nicht sofort komplett umschalten:

Keiner hat gesagt, er macht Scrum vollkommen. Für die meisten war aber klar, dass sie sich auf den Weg begeben hatten und das sie diesen Weg nicht mehr verlassen wollen.

Sehenswert ist die Präsentation von Oliver Zeiler (ImmobilienScout24.de) und Boris Gloger, die sie auf dem ScrumDay gehalten haben:
Weiterlesen

Ein wenig Meditation über Scrum

Bärbel de BouvierWir hatten auf diesem Blog schon einmal eine schöne Präsentation von Jurgen Appelo vorgestellt. Jetzt ist mir beim Stöbern auf Slideshare eine weitere über den Weg gelaufen. Wer wissen will, was Scrum ist und wie es funktioniert, findet in der kurzweiligen Slidehow mit dem schönen Titel „The Zen of Scrum“ alles, was er wissen muss. Wer tiefer einsteigen will, findet hingegen bei uns jede Menge wissenswertes zu Scrum.

Ãœbrigens: Zen steht für einen „Zustand meditativer Versenkung“. Wenn’s hilft, dann bitte sehr…


        

Projekt-Praktikum: Die Dauer eines Sprints

Bärbel de BouvierNach dem Product-Backlog-Meeting steht das erste Sprint-Planning-Meeting auf der Agenda. Erster Punkt dort ist die Definition der Dauer eines Sprints. Auf den ersten Blick scheint die Sache ganz klar zu sein: Ein Sprint in Scrum dauert in der Regel 30 Tage. Doch das ist logischerweise nur eine Empfehlung. Abhängig vom Projekt und vom Team kann die Sprintlänge variieren. Es gibt Teams, die mit Sprints von ein oder zwei Wochen Länge arbeiten, andere wiederum bevorzugen bis zu sechs Wochen.

Wonach richtet sich also die Sprintlänge? Ganz einfach: Am Ende jedes Sprints muss ein „shipable Product“, also ein auslieferungsfähiges Produkt stehen. Das wiederum ist aber nicht zu verwechseln mit dem „fertigen“ Produkt. Es geht nur darum, dass ein bestimmtes, funktionierendes Featureset einsatzbereit ist. Egal, wie grundlegend seine Funktionalität ist.

Dementsprechend hängt die Sprintlänge also von der Größe und den Fähigkeiten des Teams ab, sowie von den User-Stories, sprich den zu verwirklichenden Features. Eine Website wird beispielsweise eher in kürzeren Sprints zu bewerkstelligen sein. Ein komplexes Produkt, bei dem komplizierte Entwicklungsprozesse und umfangreiche Vorarbeiten und Learnings nötig sind, wird eher in längeren Sprints angegangen werden.

Ein weiterer, nicht zu vernachlässigender Aspekt der Sprintlänge ist der damit verbundene Overhead. Je kürzer der Sprint, desto häufiger fallen beispielsweise die obligatorischen Sprint-Planning- und Sprint-Review-Meetings an. Gerade bei größeren Teams ist der damit zusätzlich verbundene Aufwand nicht zu unterschätzen.

Grundsätzlich aber gilt: Die Länge des Sprints wird weder vom Management, noch vom Product-Owner vorgegeben. Vielmehr bestimmt sie das Team selbst. Schließlich ist das ja einer der Scrum-Grundgedanken: Das Team weiß am besten, wie es die gestellten Aufgaben bewerkstelligen kann. Bei meinem kleinen und übersichtlichen Projekt hat sich das Team für einwöchige Sprints entschieden.

Projekt-Praktikum: Scrum-Fehler vermeiden

Bärbel de BouvierHeute bin ich über eine schöne Video-Präsentation von Henrik Kniberg gestolpert. Henrik ist Schwede und Coach für agile und schlanke Softwareentwicklung. Auf der Java-Konferenz Jfokus 2008  hat er einen sehens- und hörenswerten Vortrag mit dem viel sagenden Titel „10 ways to screw up with despite Scrum and XP“ gehalten. Ein unterhaltsames und lehrreiches Video für alle, die sich für agile Methoden interessieren.

 

10 ways to screw up with Scrum and XP

Update: Das Video ist leider nicht mehr erreichbar