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

Stein für Stein zur besseren Zeiterfassung

Stopwatch2

Für viele Softwareentwickler gehört die Zeiterfassung ihrer Arbeit zu den am wenigsten beliebten Tätigkeiten. Die Gründe hierfür sind vielfältig – schlecht bedienbare Tools gehören aber auf jeden Fall dazu.

In seinem Blog Post „Why Time Sheets are Lame! „ nennt Jeff Sutherland einige Gründe, warum die Zeiterfassung aus seiner Sicht keinen Sinn macht.

Viele Firmen müssen die Zeit, die ihre Mitarbeiter mit bestimmten Aufgaben verbringen,  aus rechtlichen bzw. buchhalterischen Gründen erfassen. Die Zeiterfassung erfolgt dabei in den meisten Fällen auf individueller Basis.

Bei Nutzung einer agilen Entwicklungsmethode ist die individuelle Erfassung der Arbeitszeiten ein Problem. Beispielsweise stellt Scrum das Team und nicht Individuen in den Fokus. So gibt das Entwicklungsteam am Sprint-Anfang ein Commitment (oder in neueren Versionen des Scrum Guides einen Forecast) auf ein Sprint-Ziel ab.  Konsequenterweise wird am Sprint-Ende  der Erfolg des Teams gemessen und nicht der Erfolg von Individuen.

Für ein Unternehmen ist es eigentlich auch nur wichtig zu wissen, wie viel Zeit insgesamt für welche Themen (z.B. Maintenance, Entwicklung von neuen Features, Management der Infrastruktur etc. ) verwendet wurde. Die Summe der Zeiten entspricht im Grunde der Investitionssumme, die für verschiedene Themen aufgebracht worden ist.

Mein Arbeitgeber, die CoreMedia AG, hat sich deshalb dazu entschlossen die Zeiterfassung versuchsweise nur noch auf Team-Level durchzuführen. Die Wahl des Werkzeugs zur Erfassung ist dabei den Teams überlassen worden (Strichlisten, Software, Excel-Sheet,…). Wichtig ist nur, dass die Summe der aufgewendeten Zeiten am Ende eines Sprints an das Controlling übermittelt wird.

Damit die Zeiterfassung wieder mehr Spaß macht und wegen der einfachen Handhabbarkeit, haben sich einige unserer Teams, inklusive dem, in dem ich zur Zeit als Scrum Master tätig bin, dazu entschlossen, die Zeit mit Lego-Steinen zu tracken. Unsere „Zeiterfassung“ sieht dann so aus:

lego-tracking

Jeder Entwickler enthält am Anfang des Sprints entsprechend der Sprintlänge dieselbe Anzahl von Legosteinen. In dem Team, von dem das Beispiel stammt, steht ein Legostein für einen halben Tag.
Direkt neben unserem Task-Board und dem Ausgang zum Raum hängt eine große Legoplatte an der Wand. Auf dieser Platte sind mit festgeklemmten Post-its unterschiedliche Kategorien von Aufgaben markiert. Mögliche Kategorien sind unter anderem „Arbeit an Funktion A“, „Arbeit an Funktion B“, „Wartung“, „Pflege der Infrastruktur“ oder „Support“. Die Post-its werden mit flachen Steinen sicher auf der Basisplatte festgeklemmt.
Die Entwickler platzieren ihre Legosteine entsprechend ihrer Tätigkeiten am Tagesende jeweils in die passende Kategorie. Am Sprint-Ende werden die Legosteine in den einzelnen Bereichen vom Product Owner gezählt und in Zeiten umgerechnet, die dann elektronisch erfasst werden.

Wir machen diese Art der Zeiterfassung schon seit einigen Sprints. Bisher hat sich der Ansatz als ein pragmatischer Weg bewährt. Die Vorteile sind im Einzelnen:

  • Eine gesteigerte Akzeptanz der Zeiterfassung durch die Entwickler.
  • Die Zeiterfassung wird während des Sprints durchgeführt und nicht erst nach mehrmaligen Erinnerungen sehr viel später.
  • Die Entwickler haben das Gefühl, mit dieser leichtgewichtigen Lösung nicht zu viel Zeit in die Benutzung eigentlich unbenutzbarer Zeiterfassungssysteme stecken zu müssen.
  • Durch die Verwendung von Lego hat das Ganze zusätzlich eine spielerische Note bekommen, durch die alle Beteiligten deutlich motivierter sind.
  • Das prominent sichtbare Sammeln der Steine im Team-Büro ist Teil des Informative Workspace geworden und gibt so dem Team kontinuierliches Feedback über die Zeiten die in bestimmte Aufgaben geflossen sind. (Genauso gut erkennt man „Waste“ im System).
  • Die Informationen können auch gut in Retrospektiven genutzt werden.

Wir sind an Eurer Meinung zu diesem Ansatz der Zeiterfassung interessiert! Wollt Ihr das auch mal probieren? Was sind Eure Erfahrungen mit Zeiterfassungssystemen? Kennt Ihr andere, die einen ähnlichen Ansatz praktizieren? Bitte nutzt die Kommentarfunktion für Feedback!

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.

Wenn es Herbst wird auf dem Task Board

Dreh- und Angelpunkt bei der täglichen Arbeit eines Scrum Teams ist das Task Board. Teams gestalten dies mit der Zeit individuell aus und nutzen auch verschiedene Materialien dafür. Die Bandbreite reicht von elektronischen Systemen über Post-its auf Wänden, Glasflächen oder Pinnwänden, bis zu Klebezetteln auf mobilen oder stationären Whiteboards. Wahrscheinlich gibt es aber noch tausend andere Arten Task Boards einzurichten.
Die meisten Scrum Teams, mit denen ich zu tun habe, scheinen  gerade den Ansatz der Post-its auf mobilen Whiteboards zu favorisieren. Dies hat den Vorteil, dass die Boards bei Bedarf mit im Scrum Meetings genommen werden können, die nicht in dem Team Raum stattfinden. Leider hat dieser Ansatz aber einen gravierenden Nachteil. Die Post-its halten nicht wirklich gut auf den Whiteboards und fallen gerne mal wie Blätter im Herbst über Nacht ab. Das passiert besonders dann, wenn die Zettel bereits mehrfach um gehangen worden sind. Die erste Lösung dafür ist, die Post-Its mit Magneten zu sichern. Aber das nervt nicht nur beim Umhängen der Karte, man braucht auch noch einen großen Vorrat an Magneten.

Mein Kollege Jesco hatte eine andere Idee das Problem zu lösen. Er nutzt zur Sicherung Magnetband, das auf den Klebestreifen der Post-its befestigt wird. Ich konnte ihn dazu überreden, seinen Ansatz, der mittlerweile von drei unserer Teams genutzt wird, in einem Youtube Video der Welt zu erklären (Danke Dir Jesco!). Aber seht selbst:

Wake-Up Call für das Daily-Scrum

Die meisten Menschen, die ich kenne, werden morgens lieber mit Musik als mit den nervigen elektronischen Tönen von einfachen Weckern geweckt.

Besonders eindrucksvoll ist das zu beobachten, wenn ich morgens versuche meine Tochter aus dem Bett zu bekommen damit sie noch pünktlich zur Schule kommt. Wenn sie langsam mit Musik geweckt wird, gestaltet sich nicht nur der gesamte Prozess bis sie aus der Tür ist deutlich einfacher – sie scheint auch mit mehr Schwung und Energie aus dem Haus zu gehen.

Was hat das jetzt mit Scrum zu tun? Nun, in einigen unserer Teams gibt es manchmal einen ähnlichen Effekt, und zwar wenn es um das Daily-Scrum geht. Die haben ihr Stand-up Meeting morgens. Da wir aber flexible Arbeitszeiten haben, ist es so, dass einige der Kollegen bereits deutlich früher zur Arbeit kommen, während andere erst kurz vor dem Stand-up erscheinen.

Dies führt dazu, dass einige Teammitglieder vor dem Daily-Scrum bereits mit ihrer Arbeit begonnen haben und in ihre Aufgaben, gerne auch mit anderen im Pair-Programming, vertieft sind. Dabei verliert man schnell die Uhr aus dem Auge, so dass sie vom Scrum Master oder anderen Teammitgliedern zum Stand-up „geweckt“ werden müssen. Das kann auch mal das gesamte Team betreffen.
Im Idealfall  sollte ein Scrum Team zwar von selbst und ohne Aufforderung durch den Scrum Master zum Stand-up erscheinen. In der Realität kommt es meiner Erfahrung nach immer wieder vor, dass ein Team dabei ist, den Termin aus den Augen zu verlieren, etwa weil „Prozess-Treiber“ nicht da sind oder alle schon zu sehr in ihre Arbeit vertieft sind.

Um das „STAND-UP!“-Gerufe am morgen zu vermeiden, bin ich irgendwann mal auf die Idee gekommen, ein bis zwei Minuten vor dem Daily-Scrum einfach mal die Aktivlautsprecher an meinem Arbeitsplatz-PC einzuschalten, den Lautstärkeregler ordentlich aufzudrehen und dann „Get up Stand Up“ vom Altmeister Bob Marley zu spielen, auch wenn der Song eigentlich nur vom Titel zum Stand-up passt (aber das ist eine andere Diskussion). Der Effekt war ähnlich wie bei meiner Tochter. Zunächst blickten alle erst mal verw​undert auf und einige Momente später hatten sie die Verbindung zwischen der Musik und dem Daily-Scrum hergestellt und kamen zum Stand-up. Irgendwann habe ich damit angefangen das von Zeit zu Zeit zu wiederholen, auch wenn die Teammitglieder schon alle das Stand-up auf dem Zettel hatten. Die  Kollegen versammeln sich mit Musik deutlich beschwingter zum Daily-Scrum, ähnlich wie meine Tochter nach dem Wecken mit Musik beschwingter und besser gelaunt beim Frühstück erscheint.

Die Idee, Teams mit Hilfe der Musik zusammenzutrommeln, hatten auch schon andere. Jason Yip beschreibt auf martinfowler.com wie ein gutes Stand-up Meeting aussehen könnte. Musik als Opener spielt in dem beschriebenen Szenario eine wichtige Rolle.

Nach Yip soll ein gutes Stand-up Meeting und damit ein Daily-Scrum den GIFTS-Kriterien entsprechen. GIFTS steht dabei für Good Start, Improvement, Focus, Team und Status. Sind die Kriterien erfüllt, so sind im Stand-up, oder in unserem Fall  im Daily-Scrum, tatsächlich viele schöne Gaben (engl. gifts) für das Team enthalten. Wir werden in einem späteren Blog- Beitrag noch mal zu den GIFTS-Kriterien zurückkehren. Für diesen Beitrag ist zunächst nur „good start“ interessant. Gerade die Musik und das lockere Zusammentrommeln für das Stand-Up sollen helfen, den Start in den (Entwicklungs-) Tag angenehm, gut und energiereich zu gestalten . Genau dabei hilft den Scrum Teams und meiner Tochter die Musik.

Natürlich wird es irgendwann langweilig immer nur die gleiche Musik zu spielen. Man kann entweder andere für das Team angenehme Stücke oder auch Cover-Versionen des  Bob Marley Songs heraussuchen. Bei einer einfachen Suche auf YouTube hatte ich die folgenden Version gefunden:

    • Eric Clapton, Roger Waters & Nick Mason – Get Up Stand Up
    • Fonta – Get Up Stand Up
    • John Butler – Get Up Stand Up Toy Session
    • POD – Get up, stand up
    • Red Hot Chili Peppers – Get Up, Stand Up
    • Ben Harper, Oppression – Get Up Stand Up Live
    • Get up stand up Exodus – Tribute to Santana
    • Bruce Springsteen, Peter Gabriel, Sting, Tracy Chapman, Youssou N’Dour – Get Up Stand Up
    • The Rolling Stones – Get Up Stand Up (live Bob MarleyPeter Tosh cover)

Ich kann nur empfehlen, den Stand-up-Call mal mit Musik zu versuchen (wenn es die Gegebenheiten zulassen). Ich bin gespannt von den Erfahrungen anderer zu hören und/oder weitere Song-Vorschläge zu bekommen.