Grobplanung

Heute folgt der noch ausstehende Baustein, um Rollen und Werkzeuge zum Leben zu erwecken: Der Prozess. Er ist adaptiv angelgt und kann sich an den Erfahrungen orientiert anpassen. In dieser Form ausprobiert habe ich es nie, aber mit etwas weniger Teilnehmern in 70 Minuten im Rahmen einer Xtreme Hour. Es wird uns viel Disziplin abverlangen - wie schon beim Pitch.
Was jetzt noch zu tun bleibt: Eine möglichst genaue Timetable erstellen und jeder muss am Morgen seine mitzubringende Uhr synchronisieren :-).

Nachdem der letzte Beitrag zu einer angeregt heiteren Diskussion führte, bin ich jetzt besonders auf Eure Reaktionen gespannt!

Unter Regeln hat Cem bereits einen Ablauf unseres StartupWeekends skizziert. Die Runde 3 wird in 3 Sprints unterteilt, die - am Namen erkennbar - einen unterschiedlichen Fokus haben. Ich denke, das wird nach Aufgabengebiet auch variieren, Developer sind da vermutlich anders gestrickt, als z.B. die Gruppe unserer Juristen. Wichtig bleibt: Wir haben an eingeplanten Zeitpunkten die Chance, die Teams zu synchronisieren, Entscheidungen zu treffen oder den Prozess zu ändern.

Im Bild unten habe ich einen freiwilligen “Nightly Sprint” eingezeichnet. Falls jemanden einen Flow hat, soll er durch die Planung nicht ausgebremst werden. An anderer Stelle im Blog glaube ich gelesen zu haben, die Developer haben eine Nachtschicht vor - das deckt sich mit meinen Erfahrungen ;-).

Momentan gehe ich davon aus, dass der erste Sprint mit 2,5 Stunden etwas länger dauert als die anderen, da die Teams sich zusammenfinden, beschnuppern und das gemeinsame Vorgehen einüben müssen. Sprint 2 und 3 werden dann am Sonntag stattfinden und könnten bis zum Mittagessen durch sein (wenn man früh aufsteht).

Feinplanung 

Bei der Durchführung der Sprints hat eines die oberste Priorität: Die Timebox. Überziehen gilt nicht. Was nicht fertig wird, muss mit einem neuen Auftrag  in den Folgesprint verschoben werden.

Ausgangspunkt der Sprints ist der Schritt 2D, in welchem wir grob die wichtigsten Aufgaben der Teams gesammelt und priorisiert haben. Nun gehts los:

(0) Erstes Sprint Planning Meeting

• Teams finden sich zusammen und lernen sich kennen, kurzer Austausch
• Rollen im Team werden bestimmt: Master, Delegierter, Fachspezialisten
• Die Aufgaben aus dem Schritt 2D werden gemeinsam in Form von Auftragskarten aufgeschrieben und detailliert. Jeder kann mitmachen, dann gehts schneller. Wichtig: Jeder Auftrag muss so zerteilt sein, dass er in einem Sprint umgesetzt werden kann und möglichst klar formuliert sein, ohne den Umsetzenden in der Wahl seines Weges einzuschränken.
• Die Karten werden nach Priorität und Abhängigkeiten in eine sinnvolle Reihenfolge gebracht.
• Nun kann man abschätzen, wie viele Karten man als Team in einem Sprint etwa schaffen kann. Das ist der Sprint-Log. Man kann das grob machen, aber es kann sinnvoll sein, dass Teammitglieder die Aufträge übernehmen und mit Zeitschätzungen versehen. Dann hat man eine genauere Kapazitätsabschätzung und klare Zuständigkeiten.
• Oft ist es sinnvoll, dass zwei Teammitglieder gemeinsam an einer Aufgabe arbeiten (Pair-Programming). Das hat sich auch bei aufgaben bewährt, die nichts mit Programmierung zu tun haben.
• Zusammen solle man auch eine Liste von Problemen und unklaren Punkten erstellen, in der Spache von Scrum die  ”Impediment List“.

(1) And Action!

• Jeder erledigt seine Aufgaben.
• Bisher haben wir nur Karten. Der Delegierte sollte eine (Excel-)Liste aus den Aufträgen (Team-Log) anfertigen (hier beschrieben) oder Kopien der Karten machen.
• Die Karten werden vom Delegierten am Projekt-Dashboard “veröffentlicht”.
• Master und Delegierter kümmern sich um die Punkte auf der Impediment List. Müssen dringende Fragen mit anderen Team geklärt werden, übernimmt das der Delegierte.
• Ist ein Aufrag erledigt, wird der Status im Team-Log geändert.
• Sind alle eingeplanten Aufträge erledigt, sucht man sich eine neue aus der Liste.
• Der Delegierte kann die Statusänderungen periodisch am Projekt-Dashboard aktualisieren.
• Jeder kann jederzeit neue Auftragskarten schreiben - für das eigene oder für andere Teams.

(2) Sprint Review Meeting (15 min)

• Kurzer Status über die Fortschritte und Begutachtung der Ergebnisse.
• Neu entstandene Aufträge werden kurz vorgestellt.
• Review des Prozesses: Was war gut, was sollte man ändern.
• Beauftragung des Delegierten: Auftragskarten für andere Teams mitgeben, Liste eigener Aufträge, Vorschläge, Fragen …

(3) Product Owner Meeting - POM (30 min)

• Die Delegierten treffen sich am Projekt-Dashboard.
• Man tauscht kurz die Auftragkarten für andere Teams aus und schaut sie sich an.
• Jeder hat 90 Sekunden für einen Statusbericht und sagt, wenn er Gesprächsbedarf zu einem Thema mit einer anderen Gruppe oder allen Product-Ownern hat.
• “Einzelgespräche” werden auf das Ende des Meetings oder den Verlauf des nächsten Sprints vertagt.
• Gruppenthemen werden nach den Statusberichten besprochen und entschieden, z.B. Richtungsentscheidungen oder Änderungen am Sprint-Prozess.
• “Einzelgespräche” werden geführt, z.B. bei Unklarheiten über neue Aufträge.
• Die anderen Teammitglieder dürfen in der Zwischenzeit pausieren, weiter arbeiten, neue Karten schreiben, das Team-Log aktualisieren oder Mäuschen beim POM spielen.

(4) Do it again: Sprint Planing Meeting (15 min)

• Der Delegierte gibt die wichtigsten Informationen aus dem POM weiter.
• Das Ziel des Sprints wird vom Team beschlossen.
• Alte und neu hinzugekommene Karten werden wie unter (0) eingeplant und das Team-Log aktualisiert.

Ihre Antwort: