www.projectwizards.net/

Projekt Praktikum: Zeigt her eure Karten!

Bärbel de Bouvier am 19. Mai 2009

Heute habe ich das folgende, sehr stimmungsvolle Video über den Einsatz von Scrum in der Praxis gefunden. Man sieht darin vor allem drei Dinge:

1. Offenbar macht die Arbeit mit Scrum Spaß.
2. Scrum ist alles andere als planlos und erfordert einiges an Papierkram.
3. Kartenspielen ist Arbeit.

Letzter Punkt ist besonders interessant, denn es geht hier um das so genannte Scrum Planning-Poker. Hierbei benutzt man ein Kartenspiel als Diskussionshilfe bei der Schätzung des Aufwands einzelner User-Stories. Anstatt dass die Team-Mitglieder wild spekulierend ihre Aufwandsschätzungen in den Raum schreien, zeigen sie statt dessen Spielkarten, die je nach ihrem Wert, einer bestimmten Zeitspanne entsprechen.

(weiterlesen …)

Tags: Agiles Projektmanagement, Methoden, Praktikum, Scrum

Projekt-Praktikum: Die Dauer eines Sprints

Bärbel de Bouvier am 6. April 2009

Nach 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.

Tags: Agiles Projektmanagement, Methoden, Praktikum, Scrum

Projekt-Praktikum: Der Product Backlog (Teil 2)

Bärbel de Bouvier am 20. Februar 2009

In der Theorie schaut ja alles ganz einfach aus: Der Product Owner bastelt den ersten Product Backlog, lässt sich vom Team eine Einschätzung des Aufwands geben, priorisiert die User Stories und schon ist das Produkt so gut wie fertig. Wie gesagt, so steht es im Lehrbuch. Aber wie sieht das ganze in der Praxis aus und wie wird es organisiert?

In der Regel fällt irgendwann einmal der Entschluss ein neues Projekt anzugehen und es wird ein Verantwortlicher dafür bestimmt. Das ist normalerweise der zukünftige Product Owner. Seine erste Aufgabe ist die Formulierung der Zieldefinition und die Erstellung der ersten Version des Product Backlogs.

1. Er wird im ersten Schritt nicht umhinkommen eine Grobversion zunächst selbst zu erstellen. Dazu kann er sich bei Bedarf mit Fachleuten, also Entwicklern etc. besprechen. Das Ergebnis ist die Grundlage für den nächsten Schritt.
2. Zeit für ein erstes Meeting. Dazu versammelt der Product Owner alle verfügbaren bzw. notwendigen Fachleute. Ziel ist es, eine erste realistische Aufwandseinschätzung für die User Stories zu erhalten. Je nach Umfang des Projektes kann dieses Meeting mehrere Stunden in Anspruch nehmen.
3. Sobald der erste, realistische Product Backlog steht, kann der Product Owner die Kosten des Projektes einschätzen. Kommt Anschließend das Go vom Management, kann es losgehen.
4. Spätestens jetzt kommt der Scrum Master ins Spiel. Der Product Owner muss in Zusammenspiel mit ihm dafür sorgen, dass der folgende Prozess korrekt, sprich also Scrum-konform aufgesetzt wird.
5. Jetzt gilt es das passende Team zusammenzustellen. Dessen erste Aufgabe: Noch ein Product Backlog Meeting, dieses mal aber mit den konkret Beteiligten, also den Machern des Projekts. Ziel ist es die Aufwandschätzung nochmals zu optimieren, gegebenenfalls die User Stories zu ergänzen und zu präzisieren.
6. Nun muss der Product Owner die User Stories priorisieren und damit die Grundlage für das erste Sprint Planning schaffen.

Im nächsten Beitrag schauen wir uns an, wie ein Product Backlog inhaltlich aussieht.

Tags: Agiles Projektmanagement, Methoden, Praktikum, Scrum

Projekt-Praktikum: So läuft Scrum

Bärbel de Bouvier am 12. Februar 2009

Nach dem wir in den letzten Beiträgen die wichtigsten Begriffe gelernt haben, geht es jetzt darum, wie ein Scrum-Projekt prinzipiell abläuft. Drei Punkte sind dabei wesentlich und decken sich weitestgehend mit den grundsätzlichen Prinzipien des agilen Projektmanagements:

1. Die Idee von Scrum beruht darauf, dass die Entwicklung von Software, aber auch generell von komplexen Produkten nicht in dem Maße planbar ist, wie andere typische Projekte, etwa der Bau eines Gebäudes oder die Einrichtung einer neuen Produktionslinie in einer Fabrik.
2. Ein Scrum-Projekt wird iterativ er- und abgearbeitet. Die Devise lautet, lieber in kleinen Schritten schnell voran kommen, als bei einem großen Schritt zu stolpern, sich dabei zu verletzen und deshalb nie ans Ziel zu kommen.
3. Es gilt die Erkenntnis, dass das Team besser weiß als eine zentrale Planungsstelle (Projektmanager), was es wann und wie tun kann und welche Schritte dazu notwendig sind. Scrum formalisiert diesen Prozess jedoch und macht ihn dadurch planbar.

Der Ablauf:

Aus dem Product-Backlog werden die am höchsten priorisierten Anforderungen in den Sprint-Backlog übernommen. Das ist die Arbeitsgrundlage bzw. der Projektplan für den folgenden Sprint. Ein Sprint dauert typischerweise zwei bis vier Wochen. Die Basis für die tägliche Arbeit bildet dabei das (in der Regel 15-Minuten kurze) Daily-Scrum-Meeting. Am Endes eines Sprints folgt das Sprint-Review.

Das Ziel von Scrum wird damit klar: In möglichst kurzer Zeit zu einem funktionierenden, wenn auch nicht mit allen Features versehenen Produkt zu kommen. Fehlende Features werden in nachfolgenden Sprints hinzugefügt.

Am Beginn eines Scrum-Projektes steht das Product Backlog. Den schauen wir uns in der nächsten Folge genauer an.

Tags: Agiles Projektmanagement, Methoden, Praktikum, Scrum