Gaming the Process

Wie Sie Agile Softwareentwicklung mit Gamification noch effizienter machen

Nils Brinker, Martin Schmitz-Ohrndorf
gaming-process

© Shutterstock / file404

„Das hier ist kein Spiel!“ – wenn es um die Arbeit geht, ist eigentlich Schluss mit lustig. Budgets, Umsätze, Termindruck, Zielerreichung – zu all dem scheint das Thema „Spielen“ so gar nicht passen zu wollen, zumindest auf den ersten Blick. Denn in typischen Spielsituationen lässt sich eigentlich vieles finden, das auch für den beruflichen Alltag wünschenswert ist.

Jeder, der einmal einen PC-Spieler dabei beobachtet hat, wie er versunken in seine Spielewelt mit Hingabe Rätsel um Rätsel löst, kann die Wirkung eines guten Spiels bestätigen. In Spielsituationen finden sich die intensive Beschäftigung mit einem Thema über einen langen Zeitraum, die Arbeit auf ein Ziel hin und das Zusammenwirken im Team wieder. Die Aufgaben, mit denen es die Mitarbeiter in Unternehmen zu tun haben, sind allerdings häufig  nicht so interessant wie die neue Quest in „World of Warcraft“ oder das nächste Level von „Angry Birds“. Daran, dass sich das ändert, arbeiten die Anhänger der Gamification. Hierbei geht es darum, die analogen oder digitalen Mechanismen, die sonst in Spielen zum Einsatz kommen, um Spieler bei der Stange zu halten, in ein spielfremdes Umfeld, beispielsweise in ein Unternehmen, zu übertragen.

Dass das Arbeitsumfeld immer mehr zur Spielwiese wird, hat der Artikel „Lasset die Spiele beginnen“ in einer der letzten Ausgaben von Business Technology [1] beleuchtet. Ein Aufgabenbereich kann dabei besonders von den Mechanismen der Gamification profitieren: die Softwareentwicklung, insbesondere die agile Softwareentwicklung.

Doch mit welchen Mitteln kann eine solche „Gamifizierung“ gelingen? Stellen Sie sich dazu folgende Situation vor:

Kann man Scrum gamifizieren?

Sie haben bereits 9,6 Prozent des Artikels gelesen

Ein global tätiger Versicherungskonzern plante die Entwicklung und Einführung eines neuen Kundenportals. Die Aufgabe war komplex, sollte in zwölf Monaten erledigt sein und könnte fast sechzig Softwareentwickler Vollzeit beschäftigen. Virtuelle Vertragsordner, elektronischer Briefkasten, integrierte Kommunikation über Chat- und Videofunktionen, international skalierbar und sicher – das waren nur einige Punkte auf der Anforderungsliste der Fachabteilungen. Aufgrund des Umfangs und Investments genoss das Projekt Aufmerksamkeit bis zum Vorstand. Entsprechend groß war der Druck auf die beiden Verantwortlichen. Das Portal musste Ende des Jahres stehen.

Mit Scrum hatten bereits alle Beteiligten positive Erfahrungen gemacht. Dank Product Backlog, Sprints oder Standup-Meetings hatten die Teams in der Vergangenheit zahlreiche kleinere und größere Entwicklungsprojekte umgesetzt. Agile Entwicklung ist flexibel anpassbar und liefert schnell Ergebnisse. Aus diesen Gründen war die Methode auch für das Portalprojekt gesetzt. Aber die beiden Manager suchten nach Möglichkeiten, die Produktivität ihrer agilen Teams weiter zu erhöhen. Wie konnten die Mitarbeiter bei gleicher Qualität schneller entwickeln? Ein Artikel in einem Fachmagazin brachte die Verantwortlichen auf eine Idee. In dem Beitrag wurden Fallbeispiele erfolgreicher Gamification-Aktionen beschreiben. So konnte unter anderem Samsung mit spielerischen Mechanismen die Websiteaufrufe seiner Onlineplattform „Samsung Nation“ um 66 Prozent steigern und Domino’s Pizza erzielte durch die Einführung einer gamifizierten App ein Umsatzwachstum von 30 Prozent. Was in anderen Bereichen so gut funktioniert, müsste doch auch in einem agilen Softwareprojekt zum Erfolg führen. Denn gerade Scrum mit seiner hohen Teamorientierung und den einzelnen Aufgabenpaketen, den User Stories, erschien ihnen für die „Gamifizierung“ geeignet. Schritt für Schritt arbeiteten sich die beiden Projektverantwortlichen durch die einzelnen Schritte von Scrum, um geeignete Mechanismen für eine effektive Gamifizierung zu finden.

Gamification – wie geht das?

Sie haben bereits 21 Prozent des Artikels gelesen

Es geht um Mechanismen, um so genannte Game-Mechanics (Abb. 1). Diese sind es, auf denen die meisten gamifizierten Anwendungen aufbauen: Level, Punkte, Quests, Badges, Fortschrittsanzeigen, Leaderboards und Virtual Goods. Sie alle dienen nur einem Zweck: Der Motivationssteigerung des Nutzers. Um dieses Ziel zu erreichen, wird versucht, mithilfe der Mechanismen fundamentale, menschliche Bedürfnisse zu schüren und zu befriedigen: Status, Erfolg, Belohnung, Feedback, Selbstdarstellung, Wettbewerb, Kooperation und noch viele mehr.

Abb. 1: Game Mechanics

Abb. 1: Game Mechanics

Die beiden Manager entwickelten ein Konzept, mit dem sie den Scrum-Prozess um Game Mechanics erweitern konnten. Dazu gingen sie die Mechanismen der Reihe nach durch und entschieden, welcher Mechanismus an welcher Stelle im Scrum-Prozess (Abb. 2) zu einer effektiven Gamifizierung führen könnte.

Abb. 2: Scrum-Prozess

Abb. 2: Scrum-Prozess

So spielerisch Gamification auch klingt, den Verantwortlichen war klar, dass sie das Wichtigste – nämlich die Softwareentwicklung – nicht aus den Augen verlieren durften. Die täglichen Aufgaben mussten im Mittelpunkt der Gamifizierung stehen. Die Suche nach geeigneten Quests war deshalb schnell beendet. Für die Projektverantwortlichen stand außer Frage, dass sie die Aufgaben pro Sprint aus dem Sprint Backlog als Quests definieren mussten. Sie boten sich vor allem deshalb an, weil neben der Personenzuteilung und Priorisierung pro Aufgabe eine Aufwandsschätzung im Sprint Planning durchgeführt wird. Deshalb konnten sie jede Quest problemlos durch einen Fortschrittsbalken ergänzen.

Die beiden Manager wussten, dass die Erfüllung von Quests belohnt werden muss. Doch welche Belohnung sollte man hier vergeben? Einerseits sollte die Belohnung Begehren bei den Mitarbeitern wecken, andererseits sollte sie dem Unternehmen keine Zusatzkosten verursachen. Darüber hinaus sollte die Belohnung Spaß machen und den Sammeltrieb fördern. In Frage kamen beispielsweise Virtual Goods wie Sammelkarten oder Ausrüstungsgegenstände für einen virtuellen Avatar. Da sich der unternehmensinterne Messenger wegen der Smileys seit geraumer Zeit großer Beliebtheit erfreute, beschlossen die Manager, spezielle und limitierte Smileys als Belohnung zu vergeben, die im Messenger an andere Kollegen verschickt werden können.

Die Frage lag auf der Hand: „Und das Interesse der Benutzer wird geschürt, indem sie immer mehr Smileys sammeln?“ Leider nein, denn wozu sollte man noch weiter Smileys sammeln, wenn der Vorrat schon überquillt? Um das zu verhindern, belegten die Projektleiter die eine Hälfte der Smileys mit dem Attribut „verbleibende Zeit“ und die andere Hälfte mit dem Attribut „verbleibende Nutzungshäufigkeit“. So wurde nicht nur eine künstlich knappe Ressource, sondern auch eine weitere Möglichkeit für den Einsatz von Fortschrittsbalken geschaffen.

Jetzt kamen bereits Quests, Fortschrittsbalken und eine Belohnung in Form von Smileys zum Einsatz. Was noch fehlte, waren Punkte. Punkte lassen sich vielfältig einsetzen. Neben Erfahrungs- und Talentpunkten spielen vor allem einlösbare Punkte in gamifizierten Anwendungen und Spielen eine große Rolle. Die Projektverantwortlichen kamen auf die Idee, Punkte zu vergeben, die die Entwickler am Ende eines Sprints oder des gesamten Projekts (wie bei Payback-Punkten) gegen reale Belohnungen eintauschen können – beispielsweise gegen einen Gutschein. Zu beachten ist dabei der so genannte Korrumpierungseffekt: Einige Forscher gehen davon aus, dass eine Tätigkeit nach Einführung von Belohnungen und deren späterer Absetzung weniger attraktiv ist als noch vor der Belohnungsphase. Wenn Projektverantwortliche reale Belohnungen einführen und später, beispielsweise wegen Kostenersparnissen, wieder streichen, ist es wahrscheinlich, dass die Produktivität darunter leidet. Deshalb entschieden sich die Projektverantwortlichen zunächst für Erfahrungspunkte, die sie Scrum-Points nannten. Im Hinblick auf das Ziel der Produktivitätssteigerung kamen sie auf die Idee, diese Punkte bei der Erledigung von Quests zu vergeben, wenn der Entwickler die Quest in weniger Zeit erledigt hat als im Sprint Planning veranschlagt wurde. Deshalb legten sie fest, dass die Entwickler für je zehn Minuten Zeitersparnis einen Scrum-Point bekommen sollten.

Nicht entmutigende Ranglisten erstellen

Sie haben bereits 43 Prozent des Artikels gelesen

Ein Blick auf die Game Mechanics zeigt, dass Leaderboard und Level in dem Scrum-Projekt bisher noch nicht eingesetzt werden.

Vor allem die Einführung von Ranglisten fanden die Manager interessant. Sie vermuteten, so nicht nur einen künstlichen Wettbewerb zu schaffen, der die Entwickler weiter anspornt, sondern auch ein Managementwerkzeug, mit dem sich die Effektivität der Entwickler beobachten lässt. Beim Einsatz von Ranglisten besteht allerdings die Gefahr, dass Benutzer demotiviert werden, wenn sie sich auf den hinteren Plätzen wiederfinden. Um eine sinkende oder stagnierende Motivation durch Ranglisten zu vermeiden, können Projektleiter eine so genannte „nicht entmutigende Rangliste“ einführen. Dabei sieht sich der Benutzer unabhängig von der tatsächlichen Platzierung immer im oberen Drittel eines Ranglistenausschnitts, und zwar vor Kollegen, die weniger Punkte haben und hinter dem Kollegen, der unmittelbar vor ihm ist. So weiß er immer, wie viele Punkte er gutmachen muss, um den nächsten Kollegen einzuholen. Als Indikator für die Rangliste wählten sie die kurz zuvor definierten Scrum-Points.

Diese Punkte waren es auch, die die Projektverantwortlichen für ihr Levelsystem benutzen wollten. Das System sollte es den Benutzern ermöglichen, ihren Status zu erhöhen, indem sie nach Überschreiten vordefinierter Punktehürden in den nächsten Level bzw. den nächsten Rang aufsteigen. Dazu legten sie immer prestigeträchtigere Levels fest, deren Titel anderen Benutzern während des Chats neben dem Benutzernamen angezeigt werden sollten. Sie entschieden sich für die folgenden Levels, wohl wissend, dass sie die Liste erweitern müssten, wenn die Gamifizierung langfristig eingesetzt werden sollte: Taugenichts (0 Punkte) – Rekrut (10 Punkte) – Lehrling (20 Punkte) – Halbstarker (30 Punkte) – Profi (40 Punkte) – Meister (50 Punkte).

Bei ihren Überlegungen fiel den Projektverantwortlichen auf, dass die Mitarbeiter nur für ihre normalen Aufgaben und somit nur sehr selten belohnt wurden. Dabei ist es gerade häufiges, direktes und überraschendes Feedback, das am effektivsten zur Steigerung der Benutzermotivation beiträgt. Daher entschlossen sie sich, neben den Quests weitere Aufgaben zu definieren, die völlig quest-unabhängig waren und sich nur durch Aktivitäten lösen ließen, die innerhalb des Gamification-Konzepts vorgesehen waren. Als Belohnung für diese Aufgaben vergaben sie Badges – kleine, runde Abzeichen, wie man sie häufig bei Pfadfindern sieht.

Diese bieten sich für alle Aktionen an, die innerhalb der gamifizierten Anwendung möglich sind. Pro Aktion sollten die Manager Hürden definieren, nach deren Erreichen der Benutzer das Badge bekommt. Solche Aktionen können beispielsweise sein: Einloggen, Smileys benutzen, Punkte erhalten, Ranglistenaufstieg, Chatfenster öffnen, Worte im Chat schreiben etc. Die Projektverantwortlichen in dem Beispiel entschieden sich außerdem dafür, alle Scrum-Aktivitäten miteinzubeziehen. So sollten die Entwickler Badges sammeln, indem sie an einer bestimmten Anzahl Daily-Scrum-Meetings, dem Sprint Planning oder dem Sprint Review teilnahmen.

Damit hatten die Manager jeden Mechanismus in ihrem Scrum-Prozess untergebracht und mussten sich unweigerlich fragen:

Reicht es, den Prozess nur mit Game Mechanics auszustatten?

Sie haben bereits 61 Prozent des Artikels gelesen

Nein, denn den Prozess nur mit Mechanismen zu erweitern, mag zwar Gamifizierung sein, gewährleistet aber noch keine effektive Motivationssteigerung. Und schließlich wollten sie genau das erreichen. Damit die Entwicklerteams die Gamifizierung auch akzeptierten, mussten die Projektleiter Abhängigkeiten und Abläufe zwischen den Mechanismen schaffen. Besonders wichtig war, dass der Ablauf einen Kreislauf enthielt, in dessen Mittelpunkt die Bearbeitung von Quests stand. Zu diesen können die Entwickler dann immer wieder zurückkehren und so im Spiel weiter vorankommen.

Im Großen und Ganzen hatten sie dieses Ziel bereits erreicht. Die Entwickler bearbeiteten Quests und sobald sie eine erledigt hatten, erhielten sie dafür Smileys und je nach Zeitersparnis Scrum-Points. Die Smileys konnten sie im Chat verbrauchen und die Punkte sammeln, um sich im Wettbewerb mit ihren Kollegen anhand der Rangliste zu messen und um ihren Status zu erhöhen. Damit ihr Vorrat an Smileys nicht auf null sank, und um wettbewerbsfähig zu bleiben, mussten sie wiederum Quests erledigen. Währenddessen arbeiteten sie unbewusst an Badges und wurden so immer wieder überraschend belohnt.

Was jetzt noch fehlte, war eine Möglichkeit, dem Benutzer die Gamification-Funktionen zur Verfügung zu stellen. Denn neben der Anreicherung des Scrum-Prozesses mit Game Mechanics musste vor allem geregelt werden, wie aus Benutzern Nutznießer der Gamification werden sollten.

Die Projektverantwortlichen beschlossen, eine zentrale Benutzeroberfläche zu schaffen, die nicht nur alle nötigen Funktionen und Game Mechanics anbot, sondern auch zur Verwaltung und Transparenz des gegenwärtigen Sprints dienen sollte.

Gamification-GUI als zentrale Plattform?

Sie haben bereits 72 Prozent des Artikels gelesen

Das ist die perfekte Lösung, um gleichzeitig die Gamification-Elemente und den Scrum-Prozess über eine zentrale Plattform zu regeln. Deshalb definierten die Projektverantwortlichen, welche Funktionen dem Entwickler innerhalb der Benutzeroberfläche zur Verfügung gestellt werden sollten.

Die verfügbaren Quests müssen dem Entwickler in einer Liste angezeigt werden, aus denen er die nächste Quest auswählen kann. Dabei sollte die Liste nicht anzeigen, welches Smiley die Spieler für die jeweilige Quest bekommen, da sie die nächste Quest dann nicht nach Priorität, sondern nach ansprechendster Belohnung auswählen würden. Während der Bearbeitung der Quest füllt sich der Fortschrittsbalken und sobald sie erledigt ist, poppt ein Fenster auf, das den Benutzer über den Gewinn eines neuen Smileys und neuer Scrum-Points informiert. Neben einer Quest-Liste mussten die Manager also auch ein Benachrichtigungssystem einführen. Die erhaltenen Smileys sollten in einem Inventar gespeichert und dort für die Verwendung im Chat verfügbar sein. Da der Messenger eine zentrale Rolle in der Gamifizierung einnahm, musste auch er in die Benutzeroberfläche eingebunden werden. Darüber hinaus wollten die Projektverantwortlichen gewährleisten, dass der Status eines Benutzers für diesen immer und für andere auf Abruf sichtbar war. Aus diesem Grund blendeten sie auf der Benutzeroberfläche ein Profil ein. Dieses Profil enthielt neben den Scrum-Points die bisher gewonnenen Badges, die aktuelle Quest, die nicht entmutigende Rangliste, den Level sowie eine Personenbeschreibung mit Foto. Außerdem sollte die Oberfläche eine Übersicht mit Informationen zum Stand des gegenwärtigen Sprints enthalten. Besonders wichtig war den Projektverantwortlichen die Einführung eines Newsfeeds, der den Benutzer über Neuigkeiten in seiner Umgebung informieren sollte, beispielsweise den Levelaufstieg oder das erfolgreiche Erledigen von Quests anderer Nutzer.

Nachdem nun alle Funktionen und deren Zusammenhänge geklärt waren, erstellten sie ein erstes Konzept der zentralen Benutzeroberfläche (Abb. 3).

Abb. 3: Gamification-GUI

Abb. 3: Gamification-GUI

Im Beispiel sollte die Benutzeroberfläche der beiden Projektverantwortlichen bei der Entwicklung des Portalsystems im Mittelpunkt des Scrum-Prozesses stehen. Dabei gingen die im Sprint Planning abgeleiteten Aufgaben als Quest in die Quest-Liste der jeweiligen Entwickler ein. Anhand der Aufwandsschätzung pro Quest zeigte ein Fortschrittsbalken an, wie viel Zeit für diese Aufgabe noch verbleibt und diente bei Unterschreitung der Zeitanforderung zur Ableitung der Scrum-Points. Diese Punkte dienten als Indikator für die Rangliste. Durch den Einsatz der nicht entmutigenden Rangliste wurde gewährleistet, dass sie in keinem Fall eine motivationssenkende oder -stagnierende Wirkung hatte.

Auf dieser Basis konnte im Daily-Scrum-Meeting der Fortschritt der einzelnen Gruppenmitglieder besprochen werden. Darüber hinaus erhielten die Entwickler Badges für die Teilnahme an Meetings und benutzeroberflächenabhängige Aktionen und wurden so permanent überraschend belohnt und motiviert. Smileys förderten diese Motivation und vor allem die Kommunikation und den Spielspaß. Sie wurden durch Zeitknappheit und begrenzte Nutzungshäufigkeit als knappe Ressource verwendet und gewährleisteten somit, das Interesse der Entwickler an der Bearbeitung weiterer Quests hoch zu halten, um ihren Vorrat an Smileys wieder aufzufüllen. Das Sammeln von Scrum-Points für das frühzeitige Erledigen von Aufgaben förderte die Produktivität der Entwickler. Dabei sollten die Verantwortlichen sicherstellen, dass die Lösungen auch bei kürzerer Entwicklungszeit die geforderte Qualität erreichen. Des Weiteren hielten es die Manager für eine effektive Idee, dass die Entwickler die Scrum-Points am Ende eines Sprints oder des Projekts gegen reale Gegenstände eintauschen konnten. Da diese Idee allerdings mit weiteren Kosten verbunden gewesen wäre, wollten sie zunächst die Reaktion des Vorstands abwarten. Sie führten jedoch an, dass die potenziell hohe Kosten- und Zeitersparnis diese Investitionen durchaus rechtfertigen könnte.

Alles in allem waren die Projektverantwortlichen mit ihrem Konzept zufrieden. Aus agilen Entwicklern waren Nutznießer der Gamification geworden (Abb. 4).

Abb. 4: Die Gamification-GUI als Zentrum des Scrum-Prozesses

Abb. 4: Die Gamification-GUI als Zentrum des Scrum-Prozesses

Fazit

Sie haben bereits 95 Prozent des Artikels gelesen

Dieses Beispiel verdeutlicht, dass Gamification nicht allein aus der Anreicherung eines bestehenden Prozesses mit Game Mechanics besteht. Stattdessen bedarf es viel Kreativität und Einfallsreichtum, damit aus der Grundidee ein effektives Motivationskonzept entsteht. Natürlich handelt es sich bei dem Konzept der beiden Projektverantwortlichen um ein einfaches und ausbaufähiges System. Beispielsweise können Gamification-Verantwortliche der gesamten Anwendung ein fiktives Szenario geben, wie ein Piraten- oder Mittelalterdesign. Auch das Bedürfnis nach Kooperation wurde in diesem Beispiel vernachlässigt, kann aber gut durch Team-Quests oder -Badges und erweiterte Interaktionsmöglichkeiten erfüllt werden.

Wichtig für Gamification-Designer ist es, die grundsätzlichen Game Mechanics zu verstehen, der Kreativität keine Grenzen zu setzen und nie aus den Augen zu verlieren, wer hier überhaupt motiviert werden soll. Ganz besonders sollten sie darauf achten, einen Kreislauf zu erzeugen, in dessen Mittelpunkt die Bearbeitung der konkreten Aufgaben liegt, um einen motivierenden und effizienten Spielfluss zu erschaffen.

Dann kann Gamification ein sehr mächtiges Motivationswerkzeug sein und bietet vor allem im Bereich der Softwareentwicklung, und wie hier gezeigt auch in der agilen Softwareentwicklung, viele Einsatzmöglichkeiten und hohes Potenzial.

Herzlichen Glückwunsch! Sie haben 100 Prozent des Artikels gelesen. Sie erhalten den Badge „King of the Gamification Hill“ und haben sich einen Business-Technology-Punkt verdient!

Aufmacherbild: game joypad via Shutterstock / Urheberrecht: file404

Geschrieben von
Nils Brinker

Nils Brinker ist gelernter Industriekaufmann und studiert Angewandte Informatik mit der Vertiefung Software Engineering an der Universität Duisburg in Essen. Er arbeitet am Paluno – The Ruhr Institute for Software Technology schwerpunktmäßig an der Erforschung von Modellen zur konzeptionellen Gamifizierung von Software.

Martin Schmitz-Ohrndorf

Martin Schmitz-Ohrndorf ist Principal Consultant und Competence Center-Leiter Consulting beim IT-Dienstleister adesso AG.

Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: