Der Anlass

Ich habe einen freigewordenen Vortragsplatz beim freiraum.camp 2016 (https://twitter.com/hashtag/frrm16; http://freiraum.camp/) genutzt, um das Spiel zu testen.

Bei “Everyday agile” geht es darum, mit dem Scrum Framework und Planning Poker in kurzer Zeit eine Lösung für ein Alltagsproblem zu erarbeiten.

Dafür wurde das Arbeitsmaterial als Aufgabe (“User Story”) soweit vorbereitet, dass ein Team-Building in maximal 30 Minuten persönlich erfahrbar wird.

Das freiraum.camp war der ideale Ort für einen ersten Praxistest. Ich wollte Teilnehmer, die das Spiel nicht kennen, die Regeln noch nicht verinnerlicht haben, sich nicht kennen und auch die Aufgaben nicht kennen, um zu zeigen, dass mit einfachen Rahmenbedingungen in 30 Minuten und weniger Zeit aus Unbekannten eine erfolgreiche Entwicklungsgruppe werden kann.

Soviel vorab: es war ein voller Erfolg. Weit jenseits dessen, was ich im Vorfeld gehofft hatte.

Wie lief es ab? Was ist passiert?

Setup & Staffing

Zunächst habe ich das Spiel erläutert. Ich habe dargelegt, dass die Essenz einer Vorgehensweise nach Scrum (das Ergebnis durch die Gruppe) in einer Demonstration sehr schwer dargestellt werden kann. Deshalb habe ich die Aufgaben und den Rahmen so weit verändert, dass die Entwicklung der Gruppe wie im Zeitraffer miterlebt werden kann.

Sowohl für die Gruppenmitglieder selbst als auch die Beobachter drumherum.

Ich habe daher Freiwillige aus dem Publikum gebeten, im Kreis vor dem Auditorium (7 Stühle) Platz zu nehmen. Sie wussten nur, dass sie innerhalb der folgenden Sequenz gemeinsam eine Aufgabe zu lösen haben. Es fand sich eine Gruppe von 7 Personen. Vier Männer, drei Frauen. Drei Personen hatten Vorerfahrung mit Scrum, vier nicht. Es waren sowohl interne Mitarbeiter als auch Berater dabei. Alles bunt gemischt. Keiner kannte die übrigen Mitglieder. Eine ideale Ausgangssituation.

Dann wurde der letzte Freiwillige gesucht, um die PO-Rolle zu übernehmen.

Dem PO wurde ein Bündel beispielhafter Geldscheine zur Verfügung gestellt. Das ist das Budget, das er zur Verfügung hat, um seine Entwicklung zu finanzieren.

Der PO hat dann das Backlog priorisiert. An dieser Stelle habe ich für das Publikum und ihn noch einmal die Bedeutung des Geschäftswerts erläutert. Der Preis als Bezahlung für das Sprintergebnis wurde festgesetzt.

Dauer: 10 Minuten.

“Planning”

Der PO hat die Aufgabe vorgestellt, die für ihn den höchsten Geschäftswert besitzt.

Eine Ablehnung aufgrund mangelnder “Readiness” ist in dem Spiel nicht möglich. Daher beginnt die Entwicklungsgruppe nach der Vorstellung der Aufgabe sofort mit der Erarbeitung der Lösung, indem es zunächst die mit der Aufgabe mitgelieferten Rahmenbedingungen verinnerlicht.

Die Erarbeitung und Schärfung der Contraints und Abnahmekriterien wäre eine Aufgabe zur Vorbereitung des Sprintplannings (“Backlog Grooming”, “Backlog Refinement”).
Dieser Teil wurde bewusst zuvor erarbeitet und fertig zugeliefert.

Dauer: 5 Minuten

Sprint

Nun begann das Team mit der Lösungsentwicklung. Die Teilnehmer machten sich gleichzeitig mit dem Regelwerk, den Rahmenbedingungen und den übrigen Gruppenmitgliedern vertraut. Das geschah durch Kommunikation im Kreis. Zunächst stellten einzelne Mitglieder die Lösung vor, die nach Ihrer Ansicht die bestmögliche sei. Spätestens bei der Gewichtung der Lösungsaspekte im Wege des Planning Poker trat dann zu Tage, dass die scheinbar perfekte Lösung einer Expertin (“für mich ist das die ideale Lösung”) keineswegs diejenige ist, die alle als die beste ansehen.

Und los geht die wilde Fahrt …

In der Diskussion wurden mehrere Lösungsansätze besprochen bis sich einer herauskristallisierte, der scheinbar ideal war. Dieser Ansatz wurde nach 20 Minuten (2/3 der Sprint-Timebox) soweit beschrieben und bewertet, dass er vorstellungsreif erschien.

Ich hatte die Entwicklung absichtlich bis zu dieser Stelle laufen lassen und schaltete mich nun ein, indem ich anregte, die zentrale Annahme, die das Team getroffen hatte zu validieren, indem sie den PO dazu fragen. Es stellte sich heraus, dass die Annahme auf invaliden Voraussetzungen getroffen wurde und diese Lösung somit ausschied. Ich wies darauf hin, dass bereits 2/3 der zur Verfügung stehenden Zeit vergangen waren.

Panik kam auf.

Frustration und erste Anflüge von Hektik und Unsicherheit stellten sich ein. Einzelne Team-Mitglieder machten den weit verbreiteten Fehler, die vergangene Zeit 1:1 als die benötigte Zeit für die Zukunft anzunehmen und wurden dadurch nervös.
Ich bat sie, ihre Bedenken zurückzustellen und sich auf das einzulassen, was vor ihnen liegt.

Erwartungsgemäß wurde eine sehr viel umfangreichere und viel flexiblere Lösung erarbeitet und in den letzten Sekunden des Sprints bewertet. Parkinsonsches Gesetz 😉

Dauer: 30 Minuten

Review

Nun galt es die Abnahme des PO zu erlangen, indem ihm durch die Gruppe die Lösung vorgestellt wird. Dazu musste die Gruppe einen Sprecher bestimmen.
Dadurch, dass sich die Beteiligten sich nicht näher kannten, gab es niemanden, der dafür “prädestiniert” war. Nach zögerlichem “Hin-und-Her” fand sich dann innerhalb einer Minute ein Freiwilliger.

Der Sprecher stellte dem PO die Lösung vor, die das Team als die beste für die gegebene Aufgabe erarbeitet hatte.

Dann geschah das “Unfassbare”.

Der PO lehnte die Lösung ab, weil sie nach seiner Meinung nicht alle Akzeptanzkriterien erfüllte. Das Team reagierte zunächst leicht schockiert und dann fing der Sprecher an, die Lösung zu verteidigen. Dabei argumentierte er, die vom PO bemängelte fehlende Funktion sei sehr wohl in der Lösung enthalten. Der PO zeigte sich weiterhin ablehnend. Weitere Gruppen-Mitglieder begannen den Sprecher durch Wortbeiträge beizustehen. Die Gruppe begann, für “Ihre” Lösung zu kämpfen.

Schließlich gelang es, den PO zu überzeugen und er war bereit, den zuvor ausgelobten Betrag auszuzahlen.

Es gab noch eine zweite Komponente in der Lösung von der der PO sagte, sie wäre überflüssig.

An diesem Beispiel konnte noch kurz ein Refactoring-Szenario besprochen werden. Der “Ausbau” dieser Funktion wäre als Refactoring ins Backlog gewandert und hätte im Geschäftswert mit den verbliebenen Aufgaben konkurriert. In der Realität dieser Demonstration würden noch weitere sechs Aufgaben gelöst werden müssen, bevor das Refactoring vorgenommen werden kann.

Dauer: angesetzt waren 5 Minuten, durch den “Kampf” um die Abnahme waren es dann nahezu 10 Minuten.

Retrospektive (Aufzeigen und Auswertung des Erlebten)

Der größte Wert für alle Beteiligten entstand dann durch die Retrospektive. Sie wurde im Plenum durchgeführt. Das bedeutet, dass sowohl Mitglieder aus der Entwicklungsgruppe als auch Zuschauer und der PO Beiträge beigesteuert haben.

Hier wurde dann erstmalig offenbar, wer bereits Vor-Erfahrung hatte und wer in der beruflichen Realität welche Funktionen ausfüllt. Hier zeigte sich bspw. das ein Gruppenmitglied im “wirklichen Leben” PO ist. Sie sagte dann auch, wie wertvoll es war, auch einmal “die andere Seite” zu erleben.

Der PO offenbarte, dass er in seiner beruflichen Funktion Scrum Master ist. Ein Teilnehmer aus der Entwicklungsgruppe begleitet die pilothafte agile Transition in einer Tochtergesellschaft eines bekannten Medien-Konzerns. Berater und “einfach Interessierte” waren ebenfalls unter den Freiwilligen in der Entwicklungsgruppe.

Der PO erläuterte auch, warum er für die Aufgabe 70 “Euro” ausgelobt hatte, anstatt der ebenfalls möglichen 140,- oder 210,-. Er hatte wegen der Unerfahrenheit des Teams mit Refactoring-Aufwänden gerechnet und wollte nicht leichtfertig handeln und sofort den größten Teil seines “Budgets” für den ersten Sprint einsetzen.

Es wurde erarbeitet wie wichtig sorgfältig ausgearbeitete und präzise beschriebene Aufgaben für ein zufriedenstellendes Ergebnis sind.

Ein wichtiges Lernerlebnis war auch, dass die guten Lösungen bereits mit dem Erfüllen der gegebenen Hinweise im Szenario möglich sind. Die Exzellenten Lösungen entstehen aber erst durch die Wahrnehmung der Freiräume im “Nicht-Vorgeschriebenen”.

Ferner wurde noch einmal das Missverständnis aufgebracht, die Lösung solle den PO persönlich zufriedenstellen. Der PO ist in diesem Zusammenhang der Repräsentant einer möglichst großen und möglichst einheitlichen Gruppe von Nutzern – nicht zwangsläufig Kunden. Nur so kann der angestrebte geschäftliche Erfolg in der Zukunft auch tatsächlich realisiert werden.

Interessant waren dann auch noch die Transfer-Gespräche in denen bspw. erörtert wurde, welche Rollenbezeichnung außerhalb des Scrum-Vorgehens der PO-Rolle am ehesten entspricht.

Die Diskussion ergab, dass es am ehesten der Produkt-Manager sei. Die Annahme, der PO sei der Projekt Manager stellte sich damit zumindest teilweise als Irrtum heraus.
Ich denke, diese Fehlannahme stammt aus einer Projekt-Wirklichkeit, in der ein Produkt-Verantwortlicher die Projektleiter-Rolle in Personalunion erfüllt.

Dauer: 30 Minuten.

Fazit

Für den allerersten “Proof-of-Concept” war das bereits ein großartiges Ergebnis. Das Vorgehen funktioniert.

Vor allem funktioniert der sehr ambitionierte Ansatz, vollkommen unbekannte Personen mit unbekannten Fähigkeiten und Erfahrungen innerhalb von 30 Minuten zu einer funktionsfähigen Gruppe (aka “Team”) zusammenzuschweißen.

Es muss natürlich berücksichtigt werden, dass auf einem freiraum.camp überwiegend offene und zugewandte Menschen zu finden sind.
Die nächste Bewährungsprobe wird dann eine Gruppe sein, in der auch kritische bis ablehnende Haltungen vorkommen.
Ich freue mich auf die nächste Gelegenheit, dieses Spiel zu prüfen und weiter reifen zu lassen.

Die Länge der Retrospektive und der Erarbeitungszeit wurde “bemängelt”.
Für die Zuschauer seien die beiden Blöcke zusammen genommen zu lang gewesen. Die Teilnehmer der Gruppe aber hatten “Blut geleckt” und hätten am liebsten noch eine weitere Aufgabe in dieser Konstellation bearbeitet.
Dafür hat aber die vorgegebene Timebox von 90 Minuten nicht mehr ausgereicht.

Ich musste dann als Betreuer in den großen Hörsaal wo Sven Franke bereits mit der Vorführung von AugenhöheWEGE (orange) begonnen hatte.

Eine sehr schöne Beobachtung war, dass mehrere Mitglieder des Entwicklungsteams in den darauffolgenden Pausen weiter miteinander sprachen und die Spiel-Erfahrung die Grundlage für einen vertiefenden Erfahrungsaustausch wurde.

Es waren allerdings “nur” die Mitglieder mit Scrum-Vorerfahrung.