Der Verein hatte mich zu einem Vortrag über commons eingeladen. Bei solchen Gelegenheiten frage ich mich immer, wie ich das Thema mit der jeweiligen Gegend und den Erfahrungen der Zuhörerschaft verbinde. Commons sind bekanntlich überall, eine alltagspraktische Sorge sozusagen. Spiele und Spielregeln sind commons.

Es gibt ein paar Sets von Grundregeln. Doch überall in der Welt, gar von Dorf zu Dorf, von Familie zu Familie wird ein bisschen anders gespielt. Heraus kommt bunte Vielfalt, von der entsprechenden community an die Gegebenheiten angepasst. Es ist schließlich nicht dasselbe, ob Mann im Mittelgebirge Mitteleuropas als Profi oder frau in den bolivianischen Anden, auf ca 3000 m nach getaner Arbeit bolzt. Fußballvielfalt existiert solange keine Verwertungsrechte an Spielen und keine Privateigentumsrechte an Spielregeln vergeben werden. Letzteres ist nicht der Fall, aber die Sache mit den Verwertungsrechten, dh. der Totalkommerzialisierung ums runde Leder treibt stattdessen unsägliche Blüten. Medien, Rechteverwerter und zahlungskräftige Vereine kontrollieren den Kauf und Verkauf von Spielern, den Zugang zu den Stadien und vieles mehr. Wie sagt der Fußballblogger: "Der Fußball muss akzeptieren, dass er nicht ein urheberrechtlich geschütztes Werk, vergleichbar mit einem Film, ist. Fußball ist Gesellschaft, Fußball ist von so hohem öffentlichem Interesse, dass er Einschnitte in seine Rechte akzeptieren muss." Gemeint ist wohl: die Rechteverwerter des Spiels müssen das akzeptieren. Hoffentlich noch lange.

Marko Härtl  

Folgende Überlegungen:

• Was ist das Einfachste, das noch funktionieren würde?
• Was verleiht uns die maximale Flexibilität in der Umsetzung?
• Was sorgt für die größte mögliche Synchronisation der Teams und für die schnelle Beseitigung von Show-Stoppern.

An einigen Stellen revidierte Idee:

• Es gibt nur genau einen Sprint. Der startet nach der Runde 2 und läuft rund um die Uhr, bis wir es beschließen oder aus organisatorischen Gründen Schluss gemacht werden muss.
• Vor dem Start des Sprints macht man einen zeitnahen Zeitpunkt für das erste Standup-Meeting der Product Owner (Delegierte der Teams) ab.
• Das Product Owner Meeting als offizielles Entscheidungsgremium kann so ablaufen wie beschrieben, aber man verabredet gemeinsam den Zeitpunkt für das nächste Treffen - so wie es die Situation erfordert. Die Etappen sind also flexibel und an den Bedürfnissen orientiert. In Toronto hatte man stündliche 7 Minuten Standup-Meeting, allerdings war auch die Gruppe kleiner.
• Kleinere Fragestellungen und Probleme werden zwischen den Teams direkt ausgeräumt. Echte Show-Stopper müssen in einem sofort einberufenen Standup Meeting geklärt werden.
• Der Rest kann so bleiben wie bereits beschrieben - bis wir gemeinsam anders entscheiden.

Noch meine persönlich Meinung zum Ziel des Sprints: Wir sollten mit dem gerinsten Aufwand den größten möglichen Nutzen erzeugen. Ein funktionierendes einfaches Konzept und geklärte Grundsatzfragen gehen vor perfekter Architektur und perfektem grafischen Layout. Ein laufender Prototyp an dem man etwas diskutieren kann, ist wichtiger als eine durchgestylte Bauruine. Dabei hilft die Frage: Muss es jetzt sein oder kann man es nach dem StartupWeekend noch tun? Um Kent Beck zu zitieren: Make it work, make it right, make it fast! (nicht alles auf einmal, sondern in der Reihenfolge!)

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

Grobplanung

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.

Was macht man also mit den Karten?

Man notiert darauf eine Anforderung oder eine zu erfüllende Aufgabe. Dabei sind für unsere Zwecke folgende Dinge zu beachten:

• Die Karte sollte einen prägnanten Titel haben, der die Aufgabe wiedergibt
• Sie enthält eine Beschreibung des zu erreichenden Ziels und lässt dem Umsetzenden weitestgehend den Weg selbst bestimmen
• Die Karte hat eine laufende Nummer (jedes Team darf seinen eigenen Nummernkreis verwenden), damit man sie schneller wiederfindet
• Damit man weiß, von wem sie kommt und wen man bei Unstimmigkeiten fragen kann, sollte sie den Namen des beauftragenden Teams enthalten
• Natürlich sollte auch nicht der Name des beauftragten Teams fehlen
• Und schließlich ist noch die Angabe der Piorität aus Sicht des Auftraggebers bzw. Product-Owner-Teams sinnvoll, etwas in der Form: Must have, should have, nice to have
• Jeder Auftrag muss in einem Sprint umsetzbar sein, sonst muss er in Teilaufträge zerlegt werden, die man parallel vergibt oder hintereinander in mehreren Sprints
• Wenn der Auftrag erledigt ist, kann man einen Haken dran machen
• Wichtige Ergebnisse kann man auf der Karte notieren, z.B. auf der Rückseite

Das Projekt-Dashboard

Mit den Karten kann man auf wunderbar einfache Weise die Planung und den Fortschritt visualisieren. An einem zentralen Ort (Treffpunkt des Product-Owner-Teams) werden sie an Stellwänden (da werden wir einige brauchen) aufgehängt. Pro Team gibt es eine Spalte und pro Sprint eine Zeile. Zusätzlich noch ein sogenanntes Backlog. Im Backlog werden alle Karten abgelegt die noch nicht abgearbeitet oder in einem Sprint eingeplant sind. Hier landen auch neue Aufträge, z.B. von den Delegierten eines anderen Teams. Fertige Aufträge werden farblich markiert. Die Delegierten der Teams aktualisieren regelmäßig den Status auf dem Dashboard. Das dürfte auch für Zuschauer spannend werden.

Das Team-Log

Damit jedes Team den Überblick über seine Aufträge behält, braucht es Kopien der Karten. Etwas effizienter wäre es, die Informationen der Karten in eine Excel-Tabelle einzutragen. Pro Zeile eine Karte mit ihren Daten. Zusätzlich braucht man Spalten für den Sprint, in welchen der Auftrag eingeplant wurde (1,2,3, ungeplant=Backlog), Erledigt (Ja/Nein), Wer arbeitet dann?, fertig (ja/nein). Sinnvoll ist auch eine grobe Aufwandsschätzung, damit man sehen kann, was alles in einem Sprint gemacht werden kann. Jetzt kommt der große Vorteil einer Tabellenkalkulation zu tragen: Man kann die Liste sortieren, filtern und Summen über die Aufwände bilden.

Soviel zum Thema Werkzeuge und Rollen, als nächstes werde ich versuchen einen Vorschlag zum Ablauf zu machen, dann wäre das Spiel komplett. Übrigens: Ich schreibe hier nur zum Thema, weil es sonst keiner tut. Niemand sollte sich in seiner Kreativität eingeschränkt fühlen, Eure Ideen sind willkommen.

Allgemeines zu Teams 

• Ein Team arbeitet jeweils gemeinsam an einem fachlichen Thema
• Wenn Sachgebiete durch mehrere Teams besetzt werden (Development?) erfolgt vorher eine Spezialisierung, um eine klare Abgrenzung zu haben
• Das Team besteht aus maximal 12 Personen, sonst wird der Kommunikationsoverhead überproportional groß

Der Master

• Ein Team wird nach innen vertreten durch einen "Master". Dieser wird vom Team bestimmt, soweit er nicht bereits im Vorfeld (hier) zu dieser Aufgabe gekommen ist.
• Der Master hat im Zweifelsfall den fachlichen und organisatorischen Lead im Team und sollte jeweils ein akzeptierter und gestandener "Senior" sein.

Der Delegierte

• Ein Team wird nach außen durch einen "Delegierten" vertreten.
• Der Delegierte hat die Aufgabe, die Interessen des Teams gegenüber den anderen Teams zu vertreten. 
• Er klärt unklare Aufgabenstellung, offene Fragen, übermittelt Fragen und Aufgaben an andere Teams, synchronisiert Tasks, klärt Prioritäten und präsentiert Zwischenergebnisse.
• Der Delegierte sollte also gute kommunikative und diplomatische Fähigkeiten besitzen.
• Er wird von seinem Team in das Product-Owner-Team entsendet.

Das Product-Owner Team

Da wir als Teilnehmer am SW auch alle Mitbesitzer und Mitbestimmer sind, sollten Entscheidungen auch eher basisdemokratisch gefällt werden. Dazu passt ein hauptamtliches Entscheider-Team eher nicht. Aber aus Gründen der Effizienz können jedoch auch nicht alle Details mit 120 Teilnehmern diskutiert werden. Der Kompromiss könnte ein virtuelles Product-Owner-Team sein, in welchem jedes Team durch seinen Delegierten vertreten wird.

Aufgaben des Product-Owner-Teams:

• Entscheidungstreffen zwischen den Sprints durchführen 
• Neue und geänderte Anforderungen abstimmen
• Richtungsentscheidungen treffen und Prioritäten setzen
• Zwischenergebnisse abnehmen
• Informationen durch Delegierte wieder zurück in die Teams tragen lassen

• Rollen: Wer macht was im Team?
• Teambuilding: Wie finden sich auf dem SW schnell die Teams?
• Project-Dashboard: Dokumentation von Anforderungen und Fortschritt, wie und womit?
• Synchronisation: Koordination zwischen den Teams
• Timetable: Zeitplanung für die Abläufe

Da jede Minute, die wir auf dem SW mit Diskussion um Methoden und Ablauf verbringen, für die eigentliche Arbeit fehlt, wäre es gut, wenn wir wenig weiße Flecken haben. Fehlt ein wichtige Thema? Dann her damit!

Einen Vorschlag zum Thema Rollen werde ich gleich hinterher posten.

Ich habe heute morgen eine Übersicht und Zusammenfassung hier im Blog auf der Seite "Regeln" veröffentlicht. Die Seite lebt allerdings noch...

Während des StartupWeekend werden Horst-Peter und Till (und vielleicht der eine oder andere noch) die Teams coachen und unterstützen. Keine Angst, alles ist viel einfacher als sich das anhört.

Horst-Peter wird in den nächsten Tagen zum Autorenteam des Blog hinzustossen.