Posts mit dem Label Gamification werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Gamification werden angezeigt. Alle Posts anzeigen

Donnerstag, 24. August 2023

The Agile Bookshelf: Actionable Gamification

Gamification gehört zu den Techniken, denen man im Umfeld agiler Teams immer wieder begegnet. Ob in der Wissensvermittlung, für Aufwandsschätzungen oder in Retrospektiven, an vielen Stellen werden spielerische Elemente eingesetzt. In den meisten Fällen sind diese Elemente von irgendwo übernommen worden ohne sie gross zu hinterfragen - warum auch, schliesslich funktionieren sie ja. Das heisst aber natürlich nicht, dass es keine dahinterliegenden Theorien gibt - sie sind nur eher unbekannt.


Ein Buch mit dem man sich den zugrundeliegenden Mechanismen nähern kann ist Actionable Gamification - beyond Points, Badges, and Leaderboards von Yu-Kai Chou. Er hat nicht nur über zwei Jahrzehnte das Thema Gamification erforscht, sondern auch ein darauf basierendes Modell entwickelt (das Octalys-Framework), das es möglich macht Ursachen, Zusammenhänge und Erfolgsfaktoren für eigene Erfindungen und Anwendungen von Gamification zu erkennen.


Actionable Gamification beginnt mit einer Definition dessen was Gamification ist: die Integration von Spass machenden, unterhaltenden und Engagement fördernden Elementen in Arbeits- und Freizeit-Aktivitäten. Da sie die Interaktion des Menschen mit seiner Tätigkeit in den Mittelpunkt stellt, und nicht nur deren Zweck, ist sie eher primär Human-zentriert als primär Funktions-zentriert (selbst wenn es in den meisten Fällen eine zugrundeliegende Funktion gibt).


Aufbauend auf dieser Grunderkenntnis ist das Octalys-Framework um acht verschiedene Motivatoren aufgebaut, durch deren Addressierung bewirkt werden kann, dass sich die Empfindung von Spass und unterhalten Sein und der Wunsch nach Engagement einstellen. Hinter ihnen stehen nochmals weiterführende Erkenntnisse und Überlegungen (z.B. die Aktivierung bestimmter Gehirnregionen und Emotionen), die im Buch weiter erläutert werden. Die Motivatoren sind die Folgenden:


Epic Meaning & Calling

Übersetzbar als das Gefühl an etwas Grossem zu arbeiten oder zu Grossem berufen zu sein. Was dieser übergreifende Zweck ist kann je nach Kontext (Benutzungs-Erfahrung, Change Management, Produkt-Entwicklung, etc.) unterschiedlich sein, gmeinsam ist das Framing als grosse (Gemeinschafts-)Aufgabe.


Development & Accomplishment

Hier geht es um die Wahrnehmung Fortschritte zu erzielen und ggf. Hindernisse zu überwinden, wodurch (bestenfalls kontinuierliche) Erfolgserlebnisse erzeugt werden. Wird häufig durch "Challenges" oder Wettbewerbe erzeugt.


Empowerment of Creativity & Feedback

Eine Verknüpfung von zwei Faktoren. Zum einen wird der eigenen Phantasie Freiraum gegeben, zum Anderen erfolgt dafür eine Belohnung indem die so erzeugten Ergebnisse gelobt oder weiterverwendet werden. Ein klassischer Anwendungsfall ist Design Thinking.


Ownership & Possession

In diesem Zusammenhang vermutlich am besten zu übersetzen mit Kontrolle und Aneignung. Es wird das Gefühl erzeugt, über etwas (was auch immer) frei entscheiden zu können und Ergebnisse (Auszeichnungen, Rekorde, o.ä.) werden mit der eigenen Person verbunden.


Social Influence & Relatedness

Diese beiden Konzepte drehen sich um Beziehungen. Zum einen um die zu anderen Menschen, mit denen man gemeinsam an einer Aufgabe arbeiten kann, zum anderen zu Objekten oder Handlungen mit denen man gute Erinnerungen verbindet. Ein Beispiel wäre eine Gruppenarbeit in Lego Serious Play.


Scarcity & Impatience

Auch eher negative Motivatoren gehören zur Gamification. Kanappheit erzeugt den Wunsch, etwas (ggf. als einziger) zu besitzen, langwierige Erwerb-Prozesse den ungeduldigen Wunsch, es endlich zu haben (und den Prozess zu beschleunigen). Sehr kraftvolle Effekte, aber mit Vorsicht einzusetzen.


Unpredictability & Curiosity

Hinter diesem Motivatoren-Paar steckt ein banaler, aber selten berücksichtigter Zusammenhang: wenn man Neugier erzeugen will, braucht man auch (als solche wahrgenommene) Ungewissheit, nur dann ist die Zukunft so offen, dass man auf neue Entwicklungen wirklich neugierig sein kann.


Loss & Avoidance

Noch einmal eher negative Motivatore. Auch die Sorge (im Rahmen von Gamification errungene) Dinge zu verlieren und der Wunsch anstrengende oder enttäuschende Situationen zu vermeiden können starke, aber mit Vorsicht einzusetzende Faktoren sein.


***


Wer Gamification-Ansätze für die eigene Arbeit entwickeln will (eine Idee die vielen Scrum Mastern, Agile Coaches und Trainern früher oder später kommt) kann mit sich Actionable Gamification, bzw. dem in ihm enthaltenen Octalysis-Framework eine Checkliste erstellen, anhand derer überprüfbar ist, wie viele Motivatoren im eigenen Ansatz adressiert werden. Das müssen natürlich nicht alle sein, aber je mehr desto besser.

Freitag, 14. April 2023

Small rule tweaks can have unintended consequences

Nigel Bakers Vortrag "Playing Games with Scrum" ist ein interessanter Ansatz zur Erklärung agiler Frameworks, und vor allem einer den nahezu jeder sofort nachvollziehen können wird. Selbst wenn man nicht alle Spiele kennt die er hier als Analogie verwendet, einige dürfte jeder bereits gespielt haben, und die anderen werden nachvollziehbar erklärt.



Was darüber hinaus noch erwähnenswert ist, ist der lebhafte Vortragsstil, der alleine für sich genommen ein ausreichender Grund ist, sich das Video anzusehen.

Montag, 13. August 2018

Planning Poker

Bild: Wikimedia Commons / Rachmaninoff - CC BY-SA 4.0
Wer bereits Zeit in einem Scrum-Projekt verbracht hat wird das Bild kennen. Irgendwo stellt ein Product Owner eine Idee vor und bittet sein Entwicklungsteam um eine Aufwandsschätzung. Kurz darauf halten die Teammitglieder Karten oder Mobile Apps mit Zahlen darauf hoch und nehmen so die Schätzung vor. Da immer wieder nach dieser zunächst merkwürdig aussehenden Methode gefragt wird kommt hier eine Erläuterung dazu, zum so genannten Planning Poker.

Zunächst einige Kontextinformationen: mit Planning Poker werden normalerweise Story Points geschätzt. Story Points sind personenunabhängige Aufwandseinheiten und nicht mit Stunden und Tagen gleichzusetzen, mehr zu ihnen steht hier und hier. Und Planning Poker ist kein offizieller Teil von Scrum, man könnte es also auch weglassen. Es wird allerdings trotzdem von fast jedem Scrum Team genutzt, da es sich sich als good Practice durchgesetzt hat (mehr dazu hier).

Zur Anwendung: normalerweise werden alle Teammitglieder aufgefordert ihre Schätzung (Karte) in Ruhe auszuwählen, sie noch nicht zu nennen und zu warten bis auch die anderen damit fertig sind. Dann werden die Karten gemeinsam aufgedeckt. Dadurch wird vermieden, dass ein Meinungsführer die anderen bewusst oder unbewusst beeinflusst, die Schätzung ist dadurch repräsentativer.

Da die von den Teammitgliedern geschätzten Werte normalerweise nicht identisch sind kann im nächsten Schritt versucht werden ein einheitliches Verständnis zu erzielen. Immer wieder anzutreffen sind an dieser Stelle Mehrheitsentscheidungen oder Durchschnittswerte, wodurch aber Potential verschenkt wird. Besser ist es, wenn die oberen und unteren Grenzwerte erläutert werden, die Teammitglieder kommen dadurch oft zu Einsichten die sie selbst nicht gehabt hätten.

Neben diesen beiden sehr häufigen Vorgehensweisen gibt es auch weitere, die immer wieder anzutreffen sind. Manche Teams führen für die selbe Anforderung mehrere Schätzrunden nacheinander durch, bis alle die selbe Zahl hochhalten, andere nehmen alle Schätzungen ab einer bestimmten Punktezahl zum Anlass die jeweiligen Anforderungen kleinzuschneiden, wieder andere haben Joker-Karten, mit denen sie einen Experten konsultieren können, etc., etc.

Was all diesen Techniken geimeinsam ist: neben dem Ermitteln des (abstrahierten) Aufwandes steht beim Planning Poker auch ein zweites Ziel im Mittelpunkt - das bessere Verstehen der Anforderung. Die verschiedenen Anwendungsfälle der Karten können dafür sorgen, dass die Ideen des Product Owners gründlicher diskutiert und hinterfragt werden als es normalerweise der Fall wäre. Alleine das ist schon ein Mehrwert.

Montag, 9. Juli 2018

Jenga-getriebene Retrospektiven

Bild: Flickr / RJP - CC BY 2.0
Wenn Teams sich entscheiden nach Kanban1 zu arbeiten statt nach Scrum fällt vieles weg, was von manchen Menschen als einengend empfunden werden kann, unter anderem die Fixierung auf Sprints von ein bis vier Wochen. Was damit allerdings auch verloren geht ist der automatisch stattfindende Feedback- und Verbesserungszyklus, der durch die am Ende jedes Sprints stattfindende Retrospektive angetrieben und am Laufen gehalten wird.

Nun ist es nicht so, dass es in Kanban keine Retrospektiven gäbe. Sie heissen zum Teil anders (z.B. Kaizen Session, Schulterblick oder KVP-Meeting), aber sie sind da, ohne sie wäre das "manage the flow" nicht möglich. Anders als in Scrum bleibt aber die Frage wann sie stattfinden sollen. "Immer wenn es nötig ist" ist zwar grundsätzlich ein guter Ansatz, bei ihm drohen sie aber vom Alltagsbetrieb verdrängt zu werden. Und feste Intervalle gehen wieder in Richtung Scrum, was oft nicht (mehr) gewünscht ist.

Ein interessanter Ansatz kommt von einem kölner Gamification-Guru und basiert auf einem Jenga-Spiel. Die Grundidee: wie beim normalen Jenga werden nach und nach die Steine aus dem Turm herausgezogen, und sobald er umfällt ist eine Retrospektive fällig. Das Team muss jetzt nur noch vereinbaren wann jeweils ein Stein gezogen wird. Mögliche Anlässe sind:
  • Ein Stein für jeden Tag seit der letzten Retrospektive
  • Ein Stein für jede Aufgabe die in die Expedite-Lane geschoben wird
  • Ein Stein für jede Überschreitung der WIP-Limits
  • Ein Stein sobald ein vereinbartes WIP-Age überschritten wird
  • etc.
Bei diesem Vorgehen würde es spätestens ca alle sechs Wochen zu einer Retro kommen, alleine wegen der Regel, dass ein Stein pro Tag gezogen wird. Je nach vereinbarten weiteren Regeln kann es aber auch deutlich schneller so weit sein, das Vorgehen ist also stark anlassgetrieben. Und zuletzt können Retrospektiven auch spontan angesetzt werden - man muss dafür nur den Turm umwerfen.


1Steht in diesem Fall stellvertretend für nicht-iteratives, durchflussorientiertes Arbeiten, zu weiteren Varianten siehe hier.

Donnerstag, 21. Dezember 2017

Merit-Kalender

Bild: Pixabay / Hans Braxmeier - Lizenz
Zu den faszinierendsten Ideen aus dem Management 3.0-Bereich gehört das so genannte Merit Money. Statt finanzielle Boni auf "traditionelle" Art und Weise an von Managern definierte Ziele zu binden entstehen sie durch die Beziehungen zwischen den Teammitgliedern. Jedes Teammitglied kann in definierten Intervallen bestimmte Mengen einer virtuellen Einheit (Punkte, Kudos, etc.) öffentlich an andere Teammitglieder vergeben (nicht an sich selbst), woraus sich in Summe die ausgezahlten Boni ergeben. Statt Egoismen wird so Teamwork gefördert.

Trotzdem tun sich viele Teams mit diesem Ansatz schwer. Es wird befürchtet, dass Beliebtheitswettbewerbe oder Klüngelrunden entstehen, dass manche Kollegen gar nicht belohnt werden oder dass sonstige Probleme auftreten. Um diese Sorgen zu zerstreuen kann es hilfreich sein zunächst einen Probelauf einzulegen, in dem ein Team noch ohne die finanziellen Folgen ein Merit-System ausprobieren kann. Ein Beispiel für einen solchen Lauf habe ich vor einiger Zeit mit einem von mir gecoachten Team durchgeführt - mit einem Adventskalender.

Es handelte sich genaugenommen nicht um nur einen Kalender sondern um mehrere (einen pro Teammitglied) hinter deren Türen sich Süßigkeiten befanden. Vor dem Daily Standup konnte jeder seine Süßigkeit des Tages an einen anderen vergeben, immer verbunden mit einer Begründung warum der sich das an diesem Tag verdient hatte. Bedingt durch den geringfügigen Wert war die Hemmschwelle deutlich geringer als sie es bei echten Boni gewesen wäre, gleichzeitig sorgte die tägliche Frequenz für einen schnellen Gewöhnungseffekt.

Selbst wenn sich die Weihnachtszeit durch den hohen Bekanntheitsgrad der Adventskalender besonders für solche Experimente anbietet kann man sie natürlich auch im restlichen Jahr durchführen. Und statt Süßkram können auch andere Belohnungen vergeben werden, von der Ernennung zum Mitarbeiter der Woche bis hin zu Wildcards mit denen Refactorings im Backlog hochpriorisiert werden können.

Letztendlich werden sich viele Teams auch nach erfolgreichen Probeläufen trotzdem gegen Merit Money-basierte Boni entscheiden, was auch in Ordnung ist. Mitunter behalten sie dann aber Elemente bei mit denen sie vorher experimentiert haben. Auch das ist dann bereits ein Mehrwert der sich gelohnt hat.

Donnerstag, 22. Dezember 2016

Ich packe meinen Koffer

Bild: Publicdomainpictures/George Hodan (1, 2, 3) - CC0 1.0
So kann es auch kommen: diese Woche habe ich von dem Scrum Master den ich gerade coache etwas gelernt, nämlich eine Übung die sich gut in Retrospektiven und Management-Workshops einsetzen lässt. Eine eingängige noch dazu, sie beruht auf einem Spiel das in Deutschland so gut wie jeder als Kind gespielt haben dürfte: Ich packe meinen Koffer.

In der Kinderversion geht das Spiel so, dass man der Reihe nach vom Packen eines Koffers erzählt und bei jeder Person einen einzupackenden Gegenstand hinzufügt. Ich packe meinen Koffer und nehme ein Paar Schuhe mit. Ich packe meinen Koffer und nehme ein Paar Schuhe und eine Sonnenbrille mit. Ich packe meinen Koffer und nehme ein Paar Schuhe, eine Sonnenbrille und ein Handtuch mit. Und so weiter. Wer als erstes einen der bereits genannten Gegenstände vergisst hat verloren.

In der Erwachsenenversion steht statt des zu packenden Koffers ein bürokratischer Prozess im Mittelpunkt, beispielsweise ein Produktionsrelease. Für ein Produktionsrelease führe ich einen Code Freeze durch. Für ein Produktionsrelease führe ich einen Code Freeze durch und führe alle Regressionstests aus. Für ein Produktionsrelease führe ich einen Code Freeze durch, führe alle Regressionstests aus und dokumentiere ihre Ergebnisse im Quality Center. Für ein Produktionsrelease führe ich einen Code Freeze durch, führe alle Regressionstests aus, dokumentiere ihre Ergebnisse im Quality Center und lade Screenshots jedes einzelnen Arbeitsschrittes hoch. Für ein Produktionsrelease führe ich einen Code Freeze durch, führe alle Regressionstests aus, dokumentiere ihre Ergebnisse im Quality Center, lade Screenshots jedes einzelnen Arbeitsschrittes hoch und bitte das Testmanagement um die QA-Freigabe. Und so weiter und so weiter.

Das Ziel ist bei dieser Version des Spiels nicht, dass der Satz so lang wird, dass jemand einen Teil vergisst (selbst wenn das vorkommen mag). Das Ziel ist vielmehr, allen Beteiligten klar zu machen wie umfangreich und ausufernd manche Prozessketten geworden sind. Das alleine kann schon einen Mehrwert (Erkenntnisgewinn) bringen, wobei sich der noch steigern lässt. Wenn irgendwann der ganze Bürokratievorgang an der Wand steht kann man nämlich hingehen und einzelne Teile davon streichen, und zwar so lange bis alles weg ist was nicht wirklich notwendig ist. Die durchgestrichenen Passagen auch in der echten Welt abzuschaffen kann dann der Arbeitsauftrag sein mit dem alle das Meeting verlassen.