Literatur

"User Stories Applied", ein Buch von Mike Cohn.

Er macht auf simple Art und durch sehr schöne Beispiel klar, worin genau der Unterschied zwischen Use Cases und User Stories liegt, was eine gute User Story ausmacht und wie man zu User Stories kommt.

http://www.mountaingoatsoftware.com/scrum

Ken Schwaber

Sprint 2 Retrospecitve

Sprint 2 war ein guter Sprint. Das Team "kämpft" mit der Methodik. Inhaltlich wird am Produkt nicht viel entwickelt - Scrum steht im Zielfeuer...

Der Product Master hat zu schlichten und das Team auszurichten.

Was war gut:

• Gute Auslastung und Zusammenarbeit im Team
• Planning und Estimation sehr gut dokumentiert
• Meetings werden pünktlich aufgesucht, immer vollzählig
• Team arbeitet selbständig
• "Should be in" Task wurden vom Team im Sprint zugewiesen und angenommen
• Gute Doku im Wiki
  

Was ist verbesserungswürdig:

• User Stories kommen zu spät vor der Estimation ins Team - Vorbereitung notwendig
• User Stories vom Product Owner ungenau
• Produckt Backlog inkonsistent (Excel)
• Kunden vom Test Director abbringen, da er dort User Stories erfasst
• After Scrum Sitzung oft endlos und ohne Ziel, keine Moderation
• Testing nicht instituionalisiert
  

Massnahmen:

• Sitzungsabläufe werden neu festgelegt
• Ziel und Zeit pro Sitzung im After Scrum, Moderator
• Team physisch zusammenlegen (bislang verteilt)
  

Scrum Master

Wenn der Daily Scrum so abläuft, ist irgend was falsch! Das ist eher eine schlechte Darstellung...

Sprint 1 Estimation

Esitmation, jetzt wirds lustig.

Das Entwickler Team trifft sich zum ersten Mal um Aufwand in Story Points zu schätzen.
Möglich sind Bewertungen 1,2,3,5,8 und out of scope > 8.

Story Points wiederspiegeln die Komplexität bzw. Grösse, nicht Zeit.

Beispiel:
User Story: "Ich fahre von Stuttgart nach Zürich."
Story Points: 2
Zeit: mit dem Flugzeug < 1h, mit dem Auto ca. 5h, mit der Bahn etc.

Die einzige Aussage die man aus den Story Points ableiten kann, ist das es offensichtlich doppelt so komplex/aufwendig ist, wie bespielsweise: "Ich laufe von meiner Haustür zum Bahnhof", was wahrscheinlich SP=1 ist. "Ich fahre von Stutgart nach New York, USA" ist wohl eher SP=3 und "Ich fahre von Ottendorf, GER nach New York, USA" ist wahrscheinlich SP=5, da man erst in die nächste Grosstadt muss, um einen Aschluss an einen Internationalen Flugplatz zu bekommen. Wenn man mit demSchiff fahren möchte, eben zu nächsten Hafen.

Den Weg, den das Team einschlägt um das Ziel zu erreichen, entscheidet das Team. Eine Abnahme basiert auf dem releasefähigen Ergebnis, nicht auf Basis des gewählten Lösungsansatzes.

Nach ca. 4 h und einigen guten Zusprüchen des Scrum Masters hatte das Team die Estimation hinter sich gebracht. Die Stimmung im Team war eher drückend, denn niemand wusste so recht, wie man mit der Schätzung am Ende des Sprints rauskommt.

Klassischerweise braucht man einen Anhaltspunkt wie Anzahl der Views, Menge der Daten, Anzahl der Schnittstellen, betroffene Umsysteme etc. um eine Schätzung abzugeben. Diese Schätzung ist basiert dann auf Aufwand, nicht Komplexität....

Da dies der erste Sprint ist, kann man nicht aufgrund von Erfahrung sagen, wieviel SP's das Team durchschnittlich pro Sprint realiseren kann. Man hat also die verfügbaren Resourcen errechnet und eine Geschwindigkeit (Velocity) von 21 angenommen.

Sprint 1 Planning Meeting

Das erste Planning Meeting nach Scrum

Der Product Owner trifft das Team. Er stellt seine Wünsche dar - Powerpoint Präsentation. Das Team ist konfrontiert mit Satzfragmenten, die teilweise mit Screen-Shots kombiniert sind.

Ratlosigkeit!
Das Team hatte im voraus vereinbart, das ein Teammitglied im WIKI die Planung dokumentiert. Somit wurde pro PPT Slide eine Wiki Page angelegt, denn das Team hatte zu den Satzfragmenten des Product Owners viel Fragen.

Die Fragen wurde auf Ebene "Business" erläutert, technische Details und konkrete Spezifikation wurden nicht besprochen. Das Team hat lediglich dokumentiert, was der Product Owner wirklich möchte.

Nach 4 h war die Planung vorbei und das Team war mehr oder weniger zufrieden mit dem Meeting. Man war es gewohnt, dass der Produkt Owner keine Spezifikation liefert, die ein Entwickler erwartet ... muss er auch nicht!

Nach Scrum sagt der Product Owner nur "Was". Das Team entscheidet über das "Wie".
Daran muss sich das Team erst gewöhnen.

Wiki

Das Team entscheidet für die Kommunikation zwischen Product Owner und Team ein Wiki in Betrieb zu nehmen.

Was soll ins Wiki?

Der Scrum Prozess soll für alle Projekt-Teilnehmer transparent sein. Aus diesem Grund gibt es pro Sprint eine Wiki Page mit:

• Sprint Planning
• Sprint Estimation
• Daily Scrum
• Sprint Review

OK, das Team ist bereit. Der erste Sprint kann beginnen....

Release-Management mit Scrum

Wir schreiben Software, die in einem ordentlichen Release Zyklus ausgeliefert werden muss. Um das zu gewährleisten, wurde die Entwicklung so aufgebaut, dass man trunk, branch und tag Stränge hat.

Wenn man mit Scrum iterativ arbeitet und ein ordentlichen Release Zyklus sicherstellen will, stellt sich die Frage, wo/wann werden Features entwickelt und wo/wann Bugs gefixt?

Das Team hat diese Fragen genau untersucht und folgende Alterantiven erarbeitet:

• Es gibt eine Feature Sprint, gefolgt von einem Bug Sprint - immer im Wechsel
• In jedem Sprint werden Features entwickelt und Bug's gefixt

Da der Product Owner nach jedem Sprint Funktionalität geliefert haben möchte, hat das Team die 2. Variante bevorzugt.

Da die Code Basis bereits mit dem Release 2.0 in Produktion ist, hat man beschlossen, dass Features im Trunk entwickelt werden. Bugs werden im Branch gefixed und auf Trunk gemerged.

Sprint Abbruch

Der Software-Entwickler ist von Haus aus pessimistisch....

Nach der Methodik kann man mal eben so einen Sprint abbrechen, wenn sich an der Aufgabenstellung, die das Team angenommen hat, während des Sprints etwas verändert.

Theorie! Wie sieht das in der Praxis aus? Macht das Team bei einem Sprint Abbruch in der 3. Woche einen Rollback vom Code auf dem Trunk und Release Branch?

Naja, der Scrum Master meint, dass muss das Team selbst entscheiden.
Das Team hat effektiv keine Lösung dafür. Unsere Entwicklungsumgebung untestützt das nicht. Man könnte zwar zum Begin eines Sprints die Code Basis Labeln, aber Bugs werden dann auch auf den Label zurückgerollt....

Hoffentlich trifft das nie ein....

When is a task done?

Ok, wir haben SCRUM, nehmen User Stories als Auftrag für Sprints an und verpflichten uns, diese zu realisieren.

Wann genau ist denn eine User Story/Task fertig, im Sinne des Kunden? Diese Frage ist zentral, denn immerhin gibt es ein bestehendes Auftragsverhältnis, wo Leistung und Kosten gegeneinander abgerechnet werden.

Das Team hat eine Definition für ein Entwicklungsaufgabe definiert:

• getestet (UnitTest passed, Testfall passed)
• deployed auf Abnahmetestumgebung
• dokumentiert (JavaDoc)
• eingecheckt im Subversion
• erfolgreicher Build
• erfolgreicher CheckStyle
• durchgeführter CodeReview

-> DONE

Rollenverteilung im Scrum

„Was ist der Unterschied zwischen Spiegelei und Schinken?
Das Huhn ist involviert, das Schwein verpflichtet.“

Product Owner /„Schwein“

• Definiert die funktionelle Spezifikation („Product Backlog“)
  Stellt das Budget zur Verfügung
• Setzt die Prioritäten der einzelnen Spezifikations-Elemente
• Überwacht Erfolge, Ausgaben und „ROI“

Team /„Schweine“

• Schätzt den Aufwand der einzelnen Backlog-Elemente ab
• Implementiert die jeweiligen Elemente
• Arbeitet selbst-organisierend
• Entscheidet, wie viele Elemente des Backlogs bis Ende des jeweiligen Sprints erreicht werden und verpflichtet sich

Scrum-Leiter /„Schwein“

• Ist für den Erfolg des Projekts verantwortlich
• Stellt sicher, dass die Praxis und die Richtlinien der Projektmethodik eingehalten werden
• Unterstützt den Product Owner bei der Erstellung und Priorisierung der Spezifikationen, um den maximalen ROI zu produzieren.
• Gewährleistet Transparenz, greift ein bei Problemen und Optimierungspotential
• Leitet den „täglichen Scrum“

Leitungsausschuss / Steering Committee /„Hühner“

• Dazu gehören neben Product Owner und Scrum-Leiter ein Vertreter der Business-Units, der Account Manager von Profics/namics und evtl. Mitarbeiter anderer Partnerfirmen
• Überwacht den Gesamtfortschritt des Projektes

Wie funktioniert Scrum

„Scrum“ nach Ken Schwaber

Scrum vermeidet ein Mikro-Management der Arbeit und definiert wenige Instrumente (wie etwa Gantt-Berichte), schreibt aber den Arbeitsablauf und Spielregeln recht genau vor. Die Arbeit wird in so genannte „Sprints“ oder Arbeitseinheiten von 30 Tagen aufgeteilt. In jedem Arbeitstakt wird eine für die Business-Einheit nützliche Funktionalität produziert, welche produktiv eingesetzt werden könnte.

Die Arbeit läuft folgenderweise ab:

Vorbereitung bzw. Review: Mit Hilfe des Scrum-Leiters bestimmt der Product Owner (Auftraggeber) die funktionelle Spezifikation und setzt die Prioritäten für die Realisierung.

Die Sprint-Planungssitzung: Im ersten Teil kommuniziert der Produktverantwortliche seine Wünsche und Prioritäten und handelt mit dem Team aus, was während dem Sprint zu machen ist. In der zweiten Phase entscheidet das Team, wie diese Funktionalität während dem Sprint zu realisieren ist. Das Team verpflichtet sich zu diesen Zielen.

Der Sprint: 30 Tage lang wird gearbeitet. Am Ende des Sprints soll eine fertige („release“-fähige) Funktionalität bereit stehen. Während des Sprints werden keine Änderungen der Ziele bzw. Aufgabenteilung vorgenommen, es sei denn, der ganze Sprint wird vom Product Owner abgebrochen.

Das tägliche „Scrum“: Jeden Tag 15 Minuten. Jeder Mitarbeiter wird vom Scrum-Leiter gefragt, was er/sie gestern gemacht hat, was heute zu tun ist und ob etwas im Weg steht. Allfällige Hindernisse bzw. Abweichungen zwischen SOLL und IST werden aufgenommen und anschliessend untersucht bzw. behoben.

Die Vorführung: Am letzten Tag des Sprints wird die fertige Funktionalität dem Product Owner und anderen Stakeholdern vorgeführt.

Review/weitere Planung: Auf allen Ebenen werden die Ergebnisse des Sprints evaluiert und die Ergebnisse fliessen in die Planung für den nächsten Sprint ein. Allfällige Änderungen der Spezifikation bzw. Prioritäten können vom Product Owner vorgenommen werden.

Anschliessend folgen weiteren Sprints nach dem gleichen Muster, bis das Projekt abgeschlossen ist.

Die Hauptvorteile dieser Methodik liegen darin, dass:

• Man nach einer ersten Aufbauphase nie mehr als 30 Tage von einer potentiell einsetzbaren Version entfernt ist – ein Gesamtversagen ist fast ausgeschlossen.
  
  
• Jeder Arbeitsschritt ein wirtschaftlich nutzbares Ergebnis bringt: Funktionalität, welche eingesetzt werden könnte.

Team und Auftraggeber sind bestens positioniert, um auf neue Information sowie ändernde Prioritäten und funktionale Änderungen zu reagieren. Probleme werden rasch erkannt und aus dem Weg geräumt.

Neuer Mann, neues Spiel!

Der ehemalige Projektleiter ist mit sofortiger Wirkung aus dem Projekt - ein neuer schon parat.

Mit dem "Neuen" gibts auch gleich ne neue Projektmethodik. Das Team wird zu einem Meeting zitiert und erfährt, dass wir ab sofort agile arbeiten! Die Methodik, die fortan angewandt wird, heisst SCRUM.

Nach einer 2 stündigen Einführung mit windigen Bespielen aus dem Transport-Business ist das Team ziemlich verwirrt:

"Wir fahren von Venedig nach Amsterdam. ..."
Schnell wird klar, wohin die Reise geht - Iteratives arbeiten.

Da man mit der bisherigen, eigentlich klassischen Methodik, mehr oder weniger auch iterativ gearbeitet hat, eigentlich nichts Neues, bis auf ein paar Details:

• Wer ist der Projektleiter, wenn es überhaupt einen gibt?
• Wer schreibt Spezifikationen?
• etc.

Alles ganz einfach. Treu dem Motto " Wir lösen ein Problem erst, wenn es ein Problem ist." hat man folgendes nach SCRUM definiert:

Es gibt einen Produkt Owner, einen Scrum Master und das Team. Jeder handelt selbstverantwortlich und ist zur Mitarbeit verpflichtet. Alle "anderen", nicht genannten Stake Holders sind nur "Beobachter", oder anders:

Produkt Owner, Scrum Master und Team sind "Schweine", alle anderen "Hühner". Warum?

Das Schein ist verpflichtet, das Huhn involviert!

Ken Schwaber

Agile Project Management with Scrum (Microsoft Professional) von Ken Schwaber.

• ISBN-10: 073561993X
• ISBN-13: 978-0735619937

So ziemlich eines der ersten Publikationen zum Thema agile Projektmethodik mit Scrum.

Von klassisch zu agile

Vorgeschichte: Ein Team von Software Entwickler, GUI Designern, Testern, Consultants und ein Projektleiter arbeiten seit längerem an einer Software, die von einem Kunden beauftragt wurde.

Man relaisiert das Projekt bis anhin nach klassischer Projektmethodik. Bis Release 2.0 gestaltet sich die Realisierung und die Zusammenarbeit mit dem Kunden zunehmend mühsamer.

Letzter Ausweg: personelle Umstrukturierung beim Anbieter! Man tauscht den Projektleiter aus, wie man beim einem Fussball-Verein eben den Trainer feuert, wenn die Spieler oder der Verein nicht zu frieden sind...

Beim Fussball mag das so einfach sein, das Team in diesem Fall hatte plötzlich keinen Boden mehr unter den Füssen!