Wie führt man Scrum ein

Man hat sich mit agiler Vorgehensweise nach Scrum beschäftigt, befürwortet dieses Arbeitsweise, fragt sich, warum ma nicht schon immer so gearbeitet, hat ein paar Sympathisanten an seiner Seite und möchtes Scrum mal selbst "ausprobieren".

Die Frage lautet: Wie führt man Scrum ein?
Iterativ, alles auf einmal, mit oder ohne Kunden, etc? Viele Fragen, hier ein paar Antworten.

Aus meiner Erfahrung kann ich nur empfehlen, Scrum nur gesamthaft, d.h. mit allen Rollen und Ritualen einzuführen. Das bedeutet, Einführung von agiler Vorgehensweise von heute auf morgen, zur Stunde 0.

Wie kann man das vorbereiten? Schulen, Schulen, Schulen! Zunächst ist es wichtig, dass das zukünftige Scrum Team der Idee folgen kann/will. Dazu braucht es auch unmittelbar die Zustimmung der operativen Ebene in einem Unternehmen.
Ein paar "early adaptives" sind sehr wichtig. Es bietet sich an, dass man bestimmte Themen auf verschiedene Personen verteilt und ein paar Rollenspiele vor der Einführung organisiert. Es ist wichtig, dass das Team die Arbeitweise anerkennt und "lebt"....

Was macht man mit dem Kunden? ....coming soon.

Scrum Regeln

Scrum ist ein sehr restriktives Projektmanagement. Scrum definiert die Zusammenarbeit des Kunden mit dem Projektteam sowie die Entwicklung eines Produktes mittels agiler Methodik. Scrum ist die Projektmanagement Methode zum bekannten XP Entwicklngsprozess, bei dem sich die Begrifflichkeiten und Grundideen stark überschneiden. So gibt es bei XP Interationen, Pair Programming, Test Driven Develoment und viele andere Ansätze, die so oder so ähnlich bei Scrum wiedergefunden werden. Scrum legt ein strenge organisatorische Sicht über den agilen Entwicklungsprozess. Dazu zählen:

• Sprint Planning Meeting
  Das Planning Meeting ist in zwei Teile unterteilt: Planning und Estimation, je ca. 4 Stunden. Der Kunde, vertreten durch den Product Owner stellt im Teil 1 - Planning - seine Wünsche und Prioritäten vor. Das Team hat die Möglichkeit Fragen zu stellen. Anschliessend schätzt das Team den Aufwand für die Wünsche - Estimation. Der Product Onwer ist in dieser Phase nicht anwesend. Der Aufwand wird in Story Points oder Ideal Days geschätzt. Sowohl beim Planning und bei der Estimation ist das gesamte Team anwesend.
  
• Sprint
  Ein Sprint entspricht einer Interation nach XP. Ein Sprint dauert idealerweise zwischen 1 und 4 Wochen und representiert den Arbeitstakt des Teams. Nach jedem Sprint liefert das Team brauchbare Funktionalität und bekommt dafür alle Story Points. Ziel ist es, so viel Story Points wie möglich pro Sprint zu "verdienen".
  
• Sprint Demo
  Am Ende eines Sprints werden die Funktionen präsentiert. Dabei kann der Product Owner den Entwicklungsstand selbst prüfen und gegebenenfalls für den kommenden Sprint seine Prioriäten verschieben bzw. neue Wünsche äussern. Die Sprint Demo dauert ca. 4h. Das gesamte Team ist anwesend.
  
• Sprint Retrospecitve
  Im Anschluss an den vergangenen Sprint gibt es eine 4 stündige Retrospecive, wo das gesamte Team anwesend ist und man hinterfragt was besonders gut war, bzw. wo es Optimierungspotenzial gibt. Es werden Massnahmen zur Verbesserung vom Team definiert. Der Scrum Master moderiert.
  
• Daily Scrum
  Der Daily Scrum wird vom Scrum Master moderiert. Er findet täglich statt und dauert 15 min. Es werden folgende Fragen von jedem Teammitglied beantwortet: "Was hab ich gestern gemacht", "Was mache ich heute" und "Was sind meine Hindernisse". Idealerweise sollte pro Aktivität Ziele definiert werden, die an einem Tag erreicht werden. Der Daily Scrum soll die Kommunikation und Transparenz im Team steigern - jeder weiss, woran gerade im Team gearbeitet wird. Unentschuldigtes Fehlen ist nicht erlaubt. Man kann telefonisch oder vertreten durch ein Teammitglied teilnehmen. Physische Anwesenheit ist nicht Pflicht.
• 
  

Da es zu Beginn meistens ungewohnt ist, täglich zu einem Daily Scrum zu erscheinen, kommt es häuft vor, das von den 15min schnell 5min für Warten auf andere Teammitglieder verschwendet wird. Hierfür haben wir ein Team-Sparschwein angeschafft und es gelten folgende Regeln:

• Wer bei Meetings zu spät kommt, zahlt einen Beitrag X ans Sparschwein.
• Wer bei Meetings unentschuldigt fehlt, zahlt einen Betrag X ans Sparschwein.
• Überzieht der Scrum Master das 15 minütige Daily Scrum, zahlt er ebenfalls.
• Wird in Meetings das Handy abgenommen, zahlt man einen Betrag X ans Sparschein.

Das Team-Sparschwein wird regelmässig nach der Sprint Demo geschlachtet ;-)

Ken Schwaber

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.