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!