Archiv des Autors: htewis

Struktur eines agilen Transitionsteams

Die Durchführung einer größeren organisatorischen Veränderung kann von einem Transitionsteam begleitet werden, das die Transition vorantreibt und für eine Umgebung sorgt, die im Sinne der Transition erwünschte Muster verstärkt. Im Zuge der agilen Transition der Web Development Abteilung bei Goodgame Studios durchlief unser Transitionsteam verschiedene Organisations-Formen, über die ich hier berichten möchte.

Ende 2014 hat sich Goodgame Studios (im Folgenden GGS) entschieden die Software-Entwicklung im zentralen Bereich Web Development auf agile Vorgehensweise umzustellen (Scrum/Kanban). Mit dem Mandat des CTO haben wir dazu von Anfang an ein Team etabliert, das diesen Prozess begleiten und vorantreiben sollte.

Um gleichzeitig als Vorbild zu dienen, haben wir uns entschlossen dieses Transitionsteam auf agile Art zu organisieren und uns am Scrum-Framework orientiert. Als Produkt des Transitionsteams betrachteten wir die vollständig agilisierte Abteilung, auf die wir uns in wertschaffenden Sprintinkrementen zubewegen wollten. Zu besetzen waren nun die drei Rollen Scrum Master (bzw. Agile Coach), Product Owner und Team. Product Owner wurde der Abteilungsleiter, Scrum Master eine erfahrene externe Coachess und das „Dev“-Team setzte sich zusammen aus Führungskräften und Vertretern der einzelnen Positionen (Projekt Manager, Produkt Manager, Entwickler).

transition-team

Wir begannen mit einer Sprintlänge von zwei Wochen, wobei wir Sprintplanung, Review und Retro komplett am Mittwochnachmittag durchführten. Standups gab es zwei die Woche, am Dienstag und Donnerstag. Transitions-Backlog und Sprint-Backlog haben wir nicht als physisches Board aufgesetzt, sondern in Jira, vor allem um den auf dem GGS-Gelände weit verteilten Entwicklungsteams einfachen und transparenten Zugriff zu gewährleisten.

Nachdem wir dies circa ein halbes Jahr ausprobiert hatten, stießen wir auf eine Reihe von Problemen:

  • Das Transitionsteam konnte nicht alle Entwicklungsteams gleichzeitig adressieren, so dass sich manche Teams vernachlässigt fühlten, insbesondere da wir öffentlich versprochen hatten, dass das Transitionsteam für die ganze Abteilung da sein würde.
  • Parallel zum Transitionsteam trafen sich wöchentlich die Teamleads des Bereichs und verfolgten eine eigene Agenda, die zum Teil im Widerstreit mit den Zielen des Transitionsteams stand. Obwohl in beiden Teams der Abteilungsleiter als Product Owner fungierte, gab es immer wieder Alignment-Schwierigkeiten zwischen den beiden Führungsteams.

In Summe gab es Entwicklungsteams, die gar nicht adressiert wurden und dann wiederum solche, die von beiden Führungsteams mit z.T. widersprüchlichen Zielen angesprochen wurden.

Um dieses Problem zu lösen, schwenkten wir um auf das von uns sogenannte Flower-Modell:

flower

Dazu ordneten wir die ganze Abteilung in drei Cluster, aus denen Product Owner (PO), Teamlead (TL) und Agile Coaches (AC) der Entwicklungsteams ein für ihren Cluster verantwortliches Transitionsteam bildeten (POTLAC). Das alte Transitionsteam, verwandelte sich in eine Art Product Owner Team und entsandte Delegierte als Transitions-Product Owner in die drei POTLACS. Die Treffen der Teamleads wurden abgeschafft.

Die POTLACS führten 4-Wochen-Sprints durch, jeweils um eine Woche versetzt, so dass sich das Transitions-Product-Owner-Team in der 4. Woche mit Koordinationsthemen beschäftigen konnte.

sprints

Mit dem Flower-Modell schafften wir es tatsächlich, näher an die Teams heranzurücken. Nur die 4-wöchigen Sprints fühlten sich zu lang an. Dieses Problem lösten die Teams unterschiedlich: Einer der Cluster entschloss sich auf Kanban umzustellen. Statt längerer Scrum-Meetings alle 4 Wochen führte dieses Team tägliche Standups durch, zu denen der Product Owner bei Bedarf dazustieß und im Anschluss Stories priorisieren bzw. abnehmen konnte. Der freigewordene Meeting-Slot am Mittwoch ermöglichte den anderen beiden POTLACS auf 2-Wochen-Sprints zu wechseln.

Retrospektiv betrachtet lag die größte Herausforderung beim Aufsetzen der Struktur des Transitionsteams darin, ein für die Größe der zu agilisierenden Abteilung angemessenes Alignment zu finden. Das Spannungsfeld sah dabei ähnlich aus wie Henrik Knibergs Autonomy/Alignment Matrix:

agile-team-alignment

Das Management strebte Quadrant A an, also hohes Alignment bei hoher Autonomie der Teams. Im Laufe der Zeit wurde aber immer wieder darum gerungen, was das bedeutete.

Für einige Teams sah es so aus, als wäre man zu weit in Quadrant B gerutscht, da die Arbeit mit dem Transitionsteam zusätzlichen Aufwand erzeugte, der als Overhead oder gar Micro-Management wahrgenommen wurde. Neben den Transitions-Meetings waren dies vor allem vorgeschlagene Standards (z.B. ein einheitliches Format für Roadmaps), für die manche Teams keinen direkten Mehrwert zu bekommen glaubten.

Aus Perspektive des Managements sah es gerade am Anfang so aus, als rutschten die Teams zu stark in den Quadranten C, zum einen weil sie unterschiedliche Schwerpunkte bei der Agilisierung setzten, zum anderen weil manche Teams in der ursprünglichen Aufstellung des Transitionsteams unter dem Radar flogen.

Business Value Poker and more (PO-Tools Nr.3)

Hier der dritte und letzte Teil meines Beitrags zu Product Owner Tools.

Umsetzungsplanung

Nachdem der Kontext eines Produktes definiert ist und ein allgemeines Commitment von allen Beteiligten erreicht wurde, muss die Produktidee umgesetzt werden. Eine detaillierte Zeitplanung im Vorfeld zu erstellen ist in der Regel den Aufwand nicht wert. Man erlangt bessere Ergebnisse, wenn das Team immer wieder neu entscheidet, was der nächste Schritt ist um der Vision ein Stück näher zu kommen anstatt einem festgelegten Plan zu folgen. Dennoch möchte man verschiedene aufeinander aufbauende Ziele definieren und diese in eine zeitliche Abfolge bringen um kommunizieren zu können, was und bis wann möglich sein soll.

Zielorientierte Roadmap

Die Roadmap beschreibt Etappenziele um der Vision näher zu kommen.

Ich zerlege das Big Picture aus der Storymap in kleinstmögliche Pakete, die ein wertvolles Kundenziel abbilden, sogenannte Minimal Viable Products (MVP).

roadmap

Dazu gehören:

  • Die ‘Value proposition’, der Vorteil den man sich erhofft, wenn das Ziel erreicht ist.
  • 1-2 überprüfbare Messwerte (KPI), um die Erreichung zu objektivieren.
  • Eventuell eine grobe Liste von Tasks, wenn zum besseren Verständnis hilfreich

Für die Abschätzung der Lieferpunkte der MVPs verlasse ich mich nur bedingt auf die Hochrechnung mittels Storypunkten und  Velocity, sondern diskutiere mit den Entwicklern, wie viel Zeit wir uns geben wollen um das jeweilige Ziel zu erreichen.

Im Laufe der Sprints verändert sich die Roadmap durch neue Erkenntnisse und Refokussierung auf den nächst besten Schritt um der Vision näher zu kommen.

Outcome Metriken

Wir verwenden Outcome Metriken im wesentlichen für 2 unterschiedliche Anwendungsfälle.

  1. Wir messen, ob wir den erwarteten Wert aus einem Etappenziel auch tatsächlich abschöpfen konnten.
  2. Wir messen auf lang- bis mittelfristiger Sicht die Performance des Entwicklung Teams.

Die Art und Weise wie wir Etappenziele überprüfen können, hängt sehr stark von dem jeweiligen Kontext ab.

Hier ein paar Beispiele um das Prinzip zu verdeutlichen.

Ziel:
Wir möchten in der Lage sein, für unser neues Spiel eine “Comeback Mail” an Spieler zu verschicken, die X Tage nicht im Spiel aktiv waren.

Metrik:
Die Churn Rate (Anzahl Spieler, welche das Spiel nicht weiter nutzen, geteilt durch die Summe aller Spieler) sinkt um X %.

Ziel:
Unser Backend soll sich automatisch fehlerhafte Daten nach einem Ausfall aus dem Data Ware House ziehen.

Metrik:
Der Aufwand für manuelle Datenimporte reduziert sich auf X Stunden pro Sprint.

Im Gegenzug dazu sollte man für die Performance Messung möglichst wenige bzw, wenn möglich sogar nur eine Businesskritische KPI definieren auf die man das gesamte Projekt optimiert.

Beispiel: Mittels Email Marketing möchten wir die Retention unsere Spiele langfristig erhöhen.

Die selbe KPI dient auch um Prioritätsentscheidungen zu treffen. Die Priorität wird auf Basis eines Forecast gemacht, die Performance sollte allerdings mit realen Daten gemessen werden. Die Prio KPI sollte deswegen einheitlich sein, damit man auch sehr unterschiedliche Features gegeneinander beurteilen kann.

http://www.startuplessonslearned.com/2013/03/lean-analytics.html

Business Value Poker

Oft ist es schwierig ein Produkt auf eine entscheidende Business KPI runter zu brechen, wie bei dem Beispiel Email Marketing oder bei Inhouse Reporting Tools. Außerdem sind Werte wie Zeitersparnis oder strategische Vorteile oft schwer zu messen bzw. vorherzusagen. In solchen Fällen versuchen ich den Wert von MVPs durch Business Value Poker zu objektivieren. Dabei bewerten wir ähnlich wie im Planning Poker in gemeinsamer Runde die MVPs relativ zueinander. Anstatt mit Entwicklern die Komplexität von Stories in Storypunkten zu schätzen, wird der Business Value von MVPs mit den Stakeholdern relativ zueinander geschätzt.

Da jeder Stakeholder natürlich sein eigenes Thema am wichtigsten und damit am wertvollsten findet, darf er bei der Vorstellung nur inhaltliche Fragen beantworten, aber noch keine Stellungnahme zum Wert abgeben. Dann wird in der Gruppe der übrigen Stakeholder gepokert und diskutiert, um das MVP in der Fibonacci-Skala einzuordnen. Da einigen Stakeholdern das Pokern zu “fancy” ist, orientieren wir uns z.T. auch am Team Estimation Game bzw. ordnen die MVPs einfach gemeinsam in der Skala ein.

bvpoker

Da die MVPs in der Regel noch wesentlich größer sind als die Userstories, verteilen wir die Value-Points anteilig auf die Storys. Die Stakeholder dürfen mitbestimmen, welche Stories den größten Anteil an der Zielerreichung haben.

Genau wie mit Storypunkten kann die Performance des Teams in jedem Sprint mit Value-Punkte gemessen und optimiert werden. Die Value Punkte sind aber in jeden Fall nur ein Workaround, besser ist es eine “harte” KPI für das Produkt zu ermitteln.

Fazit

Die Richtung der Produktentwicklung festzulegen ist eine komplexe Aufgabe für die der Product Owner auf eine große Zahl an Methoden zurückgreifen kann, von denen wir hier einige vorgestellt haben. Dabei ist klar geworden, dass das Einbeziehen von Entwicklungs-Team und Stakeholdern essentiell für den Produkterfolg und für den Verlauf des Projektes ist.

Ich denke, dass es hierbei  notwendig ist, das richtige Verhältnis zwischen klar definierten Zielen und kreativen Lösungsansätze zu finden. Generell sollte jedoch eine konkrete technische Umsetzung niemals Teil einer agilen Planung auf der hier beschrieben Ebene der Produktziele sein. Nur durch flexible taktische Entscheidungen und validiertes Lernen kann man mit jeder Iteration sicherstellen, dass das entstehende Produkt auch zu der initial definierten Produktidee passt.

Wärend der Produktentwicklung ist es notwendig, dass der Produkt Owner das Entwickler-Team immer wieder an der definierten Produktidee und dem erwarteten Outcome ausrichtet. Auch hierfür gibt es eine Vielzahl von Methoden und Praktiken.

gregor Gregor Meyenberg ist Product Owner bei Goodgame Studios

Domain Driven Design (PO-Tools Nr.2)

Hier die Fortsetzung meines Beitrags zu Product Owner Tools.

Domain Driven Design

Für die Modellierung des Produkts bedienen wir uns verschiedener Methoden aus dem Domain Driven Design (DDD), insbesondere Context Maps und Event Storming Workshops:

Context Map

Context Maps können helfen um Rahmenbedingungen zu definieren und/oder zu visualisieren.

In Zusammenarbeit mit dem Entwicklerteam und Domänen Experten modelliert man den Produktkontext und die Schnittstellen zu angrenzenden Bereichen, also welche Fachdomänen von dem Produkt berührt werden und welche nicht.

ddd1

Event Storming Workshop

Eine Methode zum Ermitteln und Validieren der Kontextgrenzen ist Event Storming: In einem gemeinsamen Brainstorming erschließen sich Entwickler und Fachexperten die Domäne und bringen sich gegenseitig auf ein gemeinsames Verständnis.

Dies sind die grundlegenden Schritte zu dem Vorgehen:

Die richtigen Leute einladen.

Idealerweise benutzt man einen großen Meetingraum mit sechs bis acht Leuten. Es sollten die Personen anwesend sein, die die richtigen Fragen stellen können, in der Regel sind das die Entwickler. Sowie die Personen, die die Antworten dazu haben, die Domänenexperten.

eventstorming

Keine Limitierung

Wenn man eine Domäne noch nicht kennt, kann man auch nicht wissen wieviel Platz man braucht um sie zu modellieren. Deswegen sollte man den Platz nicht begrenzen. Idealerweise bereitet man die Wände des gesamten Raums mit einer Papierrolle vor.

Entdecke die Domäne anhand von Events (Ereignissen).

Events werden immer in der Vergangenheitsform aufgeschrieben. Man verwendet orangene Stickies für die Events und ordnet diese in einer zeitlichen Abfolge. Der Workshop startet mit der Frage an die Domainexperten: “Was ist das für euch wichtigste Event”. Der erste orangene Sticky wird in die Mitte der Wand geklebt. Dann geht es weiter mit der Frage: “Was passiert davor” und “Was passiert danach” usw.

Entdecke die Auslöser von Events

Was muss passieren, damit ein Event eintritt. Manche Events werden durch eine Aktion ausgelöst (Commands). Für Commands werden blaue Stickies verwendet.

Events können durch externe Systeme oder andere Events ausgelöst werden. Für externe Systeme werden pinke Stickies verwendet. Die Auslöser von Events werden an das Event selber geklebt.

Entdecke Aggregate und ordne das Chaos

Hier geht es nicht um Aggregate im technischen Sinne. Es geht darum zusammengehörige Events in Clustern zusammenzufassen. Beispielsweise könnten alle Events die den Shop betreffen zum Aggregat Shop zusammengefasst werden. Aggregate selber können Commands entgegen nehmen und Ereignisse auslösen.

Entdecke Subdomains

Im letzten Schritt werden Aggregate zu Subdomains zusammengefasst. Hier wird ermittelt für welchen Bereich des Prozesses welche Fachexperten zuständig sind. Ausgehend von den Subdomains können dann die Kontextgrenzen und Kontextzusammenhänge definiert werden.

Fortsetzung HIER

gregor Gregor Meyenberg ist Product Owner bei Goodgame Studios

Product Owner Tools – Teil 1

von Gregor Meyenberg

Der Gedanke, dass ich als Produkt Owner meine eigenen Produktideen verwirklichen kann war für mich stets verlockend. Nach einigen Jahren weiß ich aber, dass die Realität der Arbeitswelt meist anders aussieht. In sehr vielen Fällen muss ich die Idee eines anderen übernehmen, mich selbst dafür begeistern, um dann wiederum andere von der Idee begeistern zu können und schließlich das Produkt effizient in die Umsetzung bringen.

Damit das gelingt, ist es wichtig die Intention des geplanten Produktes im Detail zu durchdringen. Wir stellen hier ein paar Tools vor, die sich für Product Owner bei Goodgame Studios (GGS) im Alltag bewährt haben.

Rahmenbedingungen

Bei GGS gibt es verschiedene zentrale Abteilungen, die für die Game-Studios und andere zentrale Bereiche Produkte liefert (Shop, Landing Pages etc.). Sich veränderndende Produktwünsche und -prioritäten sind eine ständige Herausforderung. Anstatt für jedes Produkt ein neues Team aufzusetzen geben wir neue Produkte an bestehende Teams. So verhindern wir einen ständigen Neustart des Tuckman Cycle (Forming – Storming – Norming – Performing).

Der Auftrag

Eine Fachabteilung tritt mit einer neuen Produktidee in der Regel an den Product Owner heran, den sie bereits kennt. Um ein Gefühl für die Priorität zu bekommen, versuchen wir initial den erwarteten Business Value abzuschätzen (Revenue Uplift, Steigerung der Registrierungen, Erhöhung der Retention etc.).

Geht es um ein größere Produktidee entscheiden die Product Owner des Bereichs gemeinsam, welche Teams für die Entwicklung in Frage kommen. Die Entscheidung basiert immer auf dem Wert des neuen Produktes in Relation zu dem Wert der Lieferung, die ein Product Owner bereits in seiner Roadmap geplant hat.

Jeder Product Owner in dessen Team eine Umsetzung  des neuen Produktes Sinn ergibt, liefert drei mögliche Umsetzungsoptionen, legt die jeweiligen Auswirkungen anhand seiner Roadmap dar und listet Vor- und Nachteile für das Unternehmen in einer knappen Zusammenfassung.

Die Gruppe der Product Owner aggregiert die besten Optionen und stimmt sie (bei besonders großem Impact) mit dem Management ab. Dazu betrachten wir insbesondere den “Cost of Delay”. Nach der Entscheidung für eine Option geht der Arbeitsauftrag ins Backlog des gewählten Teams.

Story Mapping

Damit Entwickler, Product Owner und Stakeholder ein gemeinsames Verständnis der Produktidee entwickeln, hilft es gemeinsam die “Geschichte” zum Produkt zu erarbeiten. Gerade zu Beginn eines Projektes führen wir dazu gerne Story Mapping Workshops durch.

Das Big Picture und die Projektziele sollten für alle Beteiligten gut sichtbar gemacht werden, z.B. mit einer Product Wall.

storymap

Der “User” sollte immer im Vordergrund stehen. Letztendlich ergibt sich die Daseinsberechtigung der Software daraus, dass sie für jemanden von Nutzen ist.

Insofern kann man sich als Product Owner die zentrale Frage stellen, wessen Leben man zum Positiven verändern will und warum?

Daraus ergibt sich dann der Business Case.

Produktvision

Die Produkt-Vision ist ein Steuerungs-Werkzeug für die Produktentwicklung. Sie ermöglicht es allen Projektbeteiligten immer wieder zu validieren, ob die geplante Arbeit auf die Vision einzahlt.

emails

Produkt-Vision neben dem Team-Taskboard

Eine gute Vision wird oft in intensiven Gesprächen mit den Stakeholdern erarbeitet, z.B. im Zusammenhang mit oben genanntem Story Mapping Workshop. In seinem Management3.0-Buch listet Jurgen Appelo hilfreiche Qualitätskriterien für eine Vision auf:

criteria.jpg

Zudem orientieren wir uns an den zahlreichen Templates für Product Visionen, wie dem Business Model Canvas oder Roman Pichlers Product Vision Board.

Am Ende sollten sich alle Beteiligten auf die Vision committen, von der Geschäftsleitung bis zum Entwicklungsteam.

Fortsetzung HIER.

gregor Gregor Meyenberg ist Product Owner bei Goodgame Studios

 

Lean/Kanban Games – Teil 2

Neben dem Push & Pull Game hat die Limited WIP Society Hamburg einige weitere Lean/Kanban Games gespielt, darunter das Name Game, das die Nachteile von Multitasking und Context Switches sichtbar macht:

limited wip 6 small

Hier nur das Executive Summary:

  1. Schreibe 5 Namen auf, alle gleichzeitig, d.h. erst alle ersten Buchstaben, dann alle zweiten usw. Miss wie lange es pro Name dauert und die Gesamtzeit.
  2. Dann schreibe die 5 Namen nacheinander und miss wieder die Zeit.
  3. Vergleiche die Ergebnisse und diskutiere

Ein ausführliche Beschreibung gibt es z.B. hier: LINK

Das Sixes Game soll die Auswirkungen von übertriebenen Sicherheitspuffern in Schätzungen von Projekten sichtbar machen. Auch dieses Spiel skizziere ich hier nur grob. Es gibt ein ausführliches Paper dazu: LINK

würfel small

Jeder Teilnehmer übernimmt ein Teilprojekt, dessen Dauer davon abhängt, wann er mit einem 6-seitigen Würfel eine 6 würfelt. Für jeden Wurf dauert das Projekt einen Tag. In einem Testprojekt lässt der Moderator alle ein paar Mal würfeln, um ein Gefühl für die Wahrscheinlichkeiten zu kriegen.

Dann geht es los. Ein wichtiges Projekt für den besten Kunden steht an und die Spieler sollen sich auf eine Anzahl Tage einigen, die jedes Teilprojekt maximal dauert (MAX TAGE). Die dem Kunden kommunizierte Gesamtdauer beträgt dann:

PROJEKT GESAMTDAUER = ANZAHL TEILPROJEKTE * MAX TAGE

In dieser Runde dauert jedes Teilprojekt also mindestens MAX TAGE. Wenn nur ein Teilprojekt länger braucht, verlängert sich auch die Gesamtdauer.

In der Diskussion danach sollte die Gruppe feststellen, dass viele Spieler wesentlich früher fertig sind und Zeit geblockt haben, die sie eigentlich nicht brauchen. Die Frage ist, wie man die Projekte organisiert, damit einerseits genügend Puffer da ist, aber andererseits zuviel Pufferzeit nicht die Gesamtdauer übertrieben aufbläst.

Eine Lösung des Problems, mit 25% kürzerer Projektdauer bei 95% Erfolgswahrscheinlichkeit, kommt aus der Theory of Constraints: Die geschätzten Sicherheitspuffer werden für jedes Teilprojekt halbiert und die Hälfte der gestrichenen Summe für länger laufende Teilprojekte am Ende des Gesamtprojekts hinzugefügt. Wenn also die Schätzung mit Sicherheitspuffer für 10 Teilprojekte bei 16 Tagen liegt, gibt man den Projekten nur 8 Tage und fügt dafür am Ende (10*8)/2=40 Tage als Puffer für Teilprojekte im Verzug hinzu.

Die statistischen Hintergründe dazu findet man in dem genannten Paper.

Bei der Durchführung mit der Limited WIP Society, haben wir natürlich auch dieses 95% sichere Projekt gerissen – Murphy lässt grüßen ;-).

Flattr this

Push & Pull Game – Lean/Kanban Games Teil 1

Hafenblick, kühle Getränke, schöne Menschen – die limited WIP Society traf sich diesmal bei IT-Agile.

elbe

Das Thema waren Lean/Kanban Games und die möglichen Spiele füllten schnell das Board. Da die Beschreibung etwas länger geworden ist, teile ich sie in zwei Beiträge auf (Teil 2 HIER).

limited wip 1 small

Papierboote falten als Push/Pull-Game 

Beim Push/Pull-Game geht es darum die Unterschiede von Push und Pull-Systemen sichtbar und fühlbar zu machen. Dabei übernimmt jeder Teilnehmer unterschiedliche Verarbeitungsschritte auf einer Art Fließband. Wir haben Papierboote gefaltet, aber beliebige Varianten sind denkbar (z.B. Cup Assembly).

limited wip 4 small

Als Material braucht man:

  • Einen großen Tisch
  • einen großen Stapel weiße DINA4-Zettel
  • ein paar gelbe DINA4-Zettel
  • zwei Stoppuhren bzw. Smartphones mit Stoppfunktion

Wir waren 5 Spieler mit folgenden Schritten (bei mehr oder weniger Spielern, einfach die Schritte weiter aufteilen bzw. zusammenfassen):

  1. Spieler: Papier vom Stapel nehmen, einmal in der Mitte falten und für den nächsten in der Mitte anfalzen
  2. Beide Ecken umknicken, als würde man einen Flieger bauen wollen.
  3. Unterkanten auf beiden Seiten nach oben klappen und die überstehende Ecke auf einer Seite nach innen umklappen, so dass ein Hut entsteht.
  4. In den Hut greifen und zum Quadrat umklappen. Dann die unteren Ecken hochklappen und zum Schiff auseinanderziehen.
  5. Der fünfte Spieler nummeriert die Boote und schreibt die Ankunftszeit auf. Achtung: Spieler 5 und der Moderator müssen zu Beginn synchron eine Stoppuhr starten.

Wem das zu wenig visuell ist, möge sich folgendes Video zu Gemüte führen:

Als erstes haben wir im Push-System gearbeitet, d.h. jeder Spieler hatte einen beliebig großen Puffer vor bzw. hinter sich. Nach wenigen Minuten hatten sich so zwischen einigen Spielern große Warteschlangen gebildet.

Nach 2:30 Minuten gibt der Moderator einen gelben Zettel in die Queue. Achtung: Wenn sich die Puffer sehr schnell füllen, lieber etwas früher den gelben Zettel hineingeben.

Ist der gelbe Zettel durch den Prozess durch, kann das Spiel gestoppt werden.

Am Ende sollte Spieler 5 eine Übersicht über die Ankunftszeiten erstellt haben:

limited wip 3 small

In unserer Gruppe entwickelte sich der Durchsatz in Richtung 4 Schiffe pro Minute. Ich selbst war an Position 4 und hatte eine recht komplexe Aufgabe, so dass sich mit der vor mir anwachsenden Queue auch der gefühlte Druck erhöhte. Gerne gesehene Kommentare von den Spielern links und rechts waren: „Ach bei dem staut es sich ja wieder mal“ oder „Den müssen wir auswechseln.“ Sowas kommt in realen Projekten natürlich niemals vor ;-).

Als das Spiel gestoppt wurde hatten wir etwa ein Dutzend unfertige Schiffe als Waste in den Puffern liegen.

Dann haben wir die Pull-Variante gespielt. Hier ist der einzige Unterschied, dass jeder Spieler ein Pufferlimit von 1 hat, d.h. er darf erst mit dem nächsten Papier anfangen, wenn der auf ihn folgende Spieler seinen Zettel angenommen hat.

Nach kurzer Zeit wartete die gesamte Prozesskette darauf, dass ich mit meinem Schritt fertig wurde, was gefühlt noch schlimmer war, als nur die Queue anwachsen zu sehen.

limited wip 2 small

Auch bei der Pull-Variante ging der Durchsatz auf ca. 4 Schiffe pro Minute zu.

Der Waste waren die 4 unfertigen Schiffe bei den vier Faltern.

Nun betrachteten wir die Durchlaufzeit anhand des gelben Schiffes in beiden Varianten. In der Push-Variante hatte das Schiff eine Durchlaufzeit von 1:53 Minuten, in der Pull-Variante nur 1:07, da es nicht in vollen Queues warten musste.

In der anschließenden Diskussion sprachen wir darüber, dass man im Pull-System die Slacktime natürlich statt für Nörgeleien dafür nutzen sollte den Teammitglieder zu helfen bzw. kreative Verbesserungsvorschläge zu erarbeiten, die den Engpass verringern.

Variante: einen zweiten gelben Zettel reingeben um zu zeigen, dass sich die Durchlaufzeit im Push-System mit der Zeit vergrößert.

Dank an Frank und Florian für Fotos und Ergänzungsvorschläge!

Kurzbeschreibungen für Name Game und Sixes Game in Teil 2.

Flattr this

Spielerischer Projekt-Kickoff

„Holger is gaming“ verlautbart mein Skype-Status seit einigen Wochen. Zugegeben arbeite ich in einer Hamburger Spielefirma, aber der eigentliche Grund für meinen Status ist, dass ich zurzeit einige von Lyssa Adkins und im Gamestorming-Buch (Gray/Brown/Macanufo) genannte spielerische Methoden für Projektmanagement und Teamarbeit ausprobiere. Folgende Ansätze habe ich beim Kickoff eines Projekts mit einem neuen Team ausprobiert. Zwei Ansätze dienen dem gegenseitigen Kennenlernen der Teammitglieder, der dritte hilft, die angestrebte Softwarearchitektur zu hinterfragen.

Markt der Fähigkeiten (Market of Skills)

Diese Methode beschleunigt das gegenseitige Kennenlernen, fördert das Bewusstsein für die Fähigkeiten der anderen Teammitglieder und zeigt auf, wo jemand Unterstützung braucht. Da sie sich auf konkrete Fähigkeiten bezieht, muss niemand einen Seelenstriptease befürchten.

Jeder Teilnehmer erstellt ein Poster, das einen Marktstand mit drei Bereichen repräsentiert:

  • Auf der Auslage des Marktstandes liegen die Skills, Kompetenzen und Fähigkeiten, von denen man glaubt, dass sie in direkter Beziehung zum Team oder anstehenden Projekt stehen und dem Team helfen könnten. (z.B. Datenbankprogrammierung)
  • Sozusagen „unterm Tresen“ werden weitere Kompetenzen angeboten, die für die anderen interessant sein könnten, auch wenn der Zusammenhang zum Team oder Projekt möglicherweise nicht offensichtlich ist (z.B. Brettspiele)
  • Der dritte Teil des Markstandes nennt Skills, die der Autor des Posters von jemand anderem lernen möchte. (z.B. Scrum)

Die Poster erstellen die Teilnehmer in 20 Minuten und präsentieren sie danach den anderen.

Nach jeder Präsentation haben die Zuhörer die Gelegenheit Feedback zu geben und das Poster des Vortragenden durch farbige Sticky Notes zu ergänzen:

  • Grüne Notes markieren Fähigkeiten, über die sich die Zuhörer freuen bzw. die Begeisterung hervorrufen.
  • Rote Notes nennen relevante Fähigkeiten des Präsentierenden, die dieser auf seinem Poster vergessen hat. Ist jemandem nicht bewusst, welche positiven Fähigkeiten er hat oder fällt es ihm gerade nicht ein, tauchen diese spätestens hier auf.
  • Gelbe Notes können die Zuhörer in den dritten Bereich des Marktstandes zu den Punkten hängen, bei dem sie dem Autoren des Plakats helfen können. Dazu bietet es sich an, den eigenen Namen auf die Note zu schreiben, damit man später leicht erkennen kann, wer hier Hilfe anbietet.

Lyssa Adkins weist darauf hin, dass man beim Feedback konstruktiv bleiben soll und sich mit unverlangter Kritik oder Ratschlägen zurückhalten sollte.

Eine Schwierigkeit kann darin liegen, dass sich die Teilnehmer unterschiedlich stark gegenüber den Team-Kollegen öffnen oder z.B. bei juniorigen Kollegen nur wenige Fähigkeiten genannt werden können.

Um Vorbehalte zu mindern sollte man klarstellen, dass die Ergebnisse im Team bleiben.

Values Activity

Jeder Teilnehmer bekommt 50 Karten mit unterschiedlichen Werten wie Produktivität, Geduld, Spaß etc. Eine umfangreiche englische Liste bietet z.B. Jurgen Apello auf seinem Blog http://www.noop.nl/2009/10/the-do-it-yourself-team-values-kit.html

Durch mehrfaches halbieren des Stapels reduziert jeder den Stapel Stück für Stück auf die 5 für ihn wichtigsten Werte.

Dann hängt jeder Teilnehmer seine Werte gut sichtbar auf und schreibt seinen Namen darüber. Der Moderator regt nun eine Diskussion an. Folgende Fragen können helfen:

  •  Wo liegen wir auseinander? Hat z.B. einer der Teilnehmer Disziplin, Respekt, Zuverlässigkeit, Teamwork und Commitment genannt, während alle anderen Spaß und Humor betonen?
  • Wo gibt es Gemeinsamkeiten? Wurde z.B. Perfektion mehrfach genannt? Was verstehen die Teilnehmer unter Perfektion?
  • Was überrascht euch? Hat z.B. nur einer der Teilnehmer Ehrlichkeit aufgeschrieben? Legen die anderen keinen Wert darauf?
  • Warum sind gerade diese Werte für euch wichtig?

Auch diese Übung dient dazu Neugier anzufachen und sich gegenseitig besser zu verstehen. Es geht nicht darum Kritik zu üben oder irgendwelche Werte als besser oder schlechter herauszuheben.

Challenge Cards

Dieses Spiel dient dazu die Annahmen zur Architektur des entstehenden Produkts/Projekts abzuklopfen.

Dazu muss die Vorstellung der zu entwickelnden Lösung natürlich einigermaßen konkret sein.

Für das Spiel braucht man zwei Gruppen: Das „Lösungs-Team“ und das herausfordernde „Challenge-Team“.

Das Gamestorming-Buch empfiehlt 5-10 Teilnehmer. Um genügend Leute zu haben kann man z.B. kompetente Kollegen aus anderen Teams einladen, die sich dann hervorragend für das „Challenge-Team“ eignen.

Zur Einführung haben wir den Kollegen zuerst die geplante Architektur vorgestellt.

Dann wurden die Teams zusammengestellt.

In der ersten Phase beraten die Teams unter sich.

Das Challenge-Team überlegt, wo die Architektur angreifbar ist: Es notiert Angriffspunkte, Fehler in den Annahmen, potentielle Risiken usw. auf roten Karten.

Das Lösungs-Team muss diese Angriffspunkte antizipieren. Es schreibt grüne Karten mit Lösungen gegen potentielle Fehler und Risiken.

Dann geht das Spiel los. Das Challenge-Team spielt eine rote Karte aus und startet damit den ersten Angriff. Das Lösungs-Team muss nun eine grüne Karte zur Verteidigung ausspielen.
Hat es eine passende Antwort, bekommt es einen Punkt, ansonsten die Herausforderer.

Im Prinzip hat am Ende das Team mit den meisten Punkten gewonnen.

Viel wichtiger aber ist, dass man am Ende gemeinsam überlegt, ob man für ungelöste Probleme nachträglich doch eine gute Lösung finden kann.

Andernfalls hat man eine Architekturschwäche aufgedeckt, die es zu bewerten gilt. Wie immer ist ein früh erkannt Schwäche leichter zu beheben, als wenn man später ganz viel Code wegschmeißen muss.

Die englische Variante dieses Blog-Eintrags findet man unter http://blog.bigpoint.net/pm/playful-project-kickoff/

Referenzen

Die Methoden „Markt der Fähigkeiten“ und die „Values Activity“ werden u.a. im Buch „Coaching Agile Teams“ von Lyssa Adkins vorgestellt.

„Challenge Cards“ wird im Buch „Gamestorming“ von Dave Gray, Sunni Brown und James Macanufo beschrieben.