Gamification im Projektmanagement
Alles nur ein Spiel?
Sich nach einem langen Arbeitstag noch zu sportlichen Höchstleistungen zu motivieren fällt nicht leicht. Der Sportartikelhersteller Nike brachte im Jahr 2012 das FuelBand auf den Markt. Das Prinzip dahinter ist eigentlich simpel. Jeder zurückgelegte Meter wird vom FuelBand registriert und in einer App oder der zugehörigen Webanwendung in sogenannte FuelPoints umgerechnet. Diese Punkte zeigen dem Nutzer nicht nur, wie sich seine persönliche Laufleistung entwickelt, sondern auch ein Vergleich unter Freunden, die ebenfalls das Nike FuelBand nutzen, spornt die Anwender dazu an, ihren Punktestand in die Höhe zu treiben. Die Idee, Nutzer durch dieses spielerische Element dazu zu motivieren, mehr Sport zu treiben, war von Erfolg gekrönt. So nutzten im ersten Jahr bereits 11 Millionen Menschen das FuelBand und sammelten insgesamt 409 Milliarden FuelPoints. Nach Angaben von Nike würde die Energie, die täglich durch die Laufleistung erzeugt wird, ausreichen, um 6.772 Häuser jeden Tag mit Strom zu versorgen.
Durch spielerische Elemente Aufgaben oder Aktivitäten für den Beteiligten angenehmer zu gestalten, dahinter verbirgt sich das Konzept der Gamification. Eine Analyse der Google-Suchanfragen nach dem Begriff Gamification zeigt, dass das Interesse an dem Konzept bis zum Jahr 2014 stetig gestiegen und in den letzten Jahren auf etwa gleichbleibend hohem Niveau geblieben ist.
Aber nicht nur im privaten Bereich lassen sich Ansätze der Gamification wiederfinden. Das Konzept lässt sich auch auf den Berufsalltag übertragen. Die Idee, alltäglich anfallende Arbeit durch spielerische Elemente anzureichern, um sie so nicht nur interessanter für die Mitarbeiter, sondern auch motivierender zu gestalten, klingt reizvoll. Das Thema Motivation von Mitarbeitern in Projekten wird stetig wiederkehrend in Projektmanager-Magazinen und Ratgebern diskutiert. So fällt es Projektleitern vor allem im Rahmen langwieriger Projekte bisweilen schwer, Beteiligte langfristig zu motivieren.
Abhilfe könnte hierbei eine Kombination der Projektarbeit mit Gamification schaffen. Diese Verbindung soll in der vorliegenden Untersuchung näher betrachtet werden.
Gamification als Mittel zur Mitarbeitermotivation
Der Begriff Gamification wurde erstmals 2002 vom britischen Entwickler Nick Pelling benutzt. Pelling verwendete bei der Programmierung von Anwendungen für kommerziell genutzte Endgeräte wie Bankautomaten, Verkaufsautomaten oder Bordunterhaltungsgeräte in Flugzeugen spielerische Elemente, um die Nutzung für Anwender auf diese Weise sowohl kurzweilig, als auch unterhaltsam zu gestalten.
Gamification – auch Gamifizierung oder Spielifizierung – bezeichnet im Allgemeinen das Verwenden von Techniken und Methoden aus Spielen, sogenannten Spiel-Design-Elementen, in einem spielfremden Kontext. Die Definition nach Deterding ist die am weitesten verbreitete Erklärung für den Begriff Gamification. Doch es existieren auch andere Definitionen. Werbach und Hunter beschreiben Gamification als „the use of game elements and game-design techniques in non-game contexts“. Im Gegensatz zu Deterding differenzieren die Autoren also zwischen game elements, den Spielelementen, und game-design techniques, Spiel-Design-Techniken. Was genau Werbach und Hunter allerdings unter gamedesign techniques verstehen, bleibt dabei offen. Als „process of game-thinking and game mechanics to engage users and solve problems“ erklären Zichermann und Cunningham die Gamification. Im Fokus der Definition steht hier im Gegensatz zu Deterding und Werbach ein konkretes Ziel, nämlich die Motivation der Nutzer, Probleme zu lösen. Auch Kapp versucht ein konkretes Ziel in die Begriffsbestimmung einzubringen und erweitert die Definition folgendermaßen:
„using game-based mechanics, aesthetics and game thinking to engage people, motivate action, promote learning and solve problems“. Kapp lehnt sich inhaltlich stark an Zichermann und Cunningham an, ergänzt deren Definition aber noch um das Element Ästhetik und erweitert die Ziele um den Bereich der Lernförderung. Spiel-Design-Elemente bilden den Mittelpunkt des Gamification-Gedankens und wurden bereits im vorangegangenen Teil der Arbeit als spezifische und charakteristische Komponenten eines Spiels definiert. Die Erstellung einer vollumfänglichen Auflistung aller möglichen Spiel-Design-Elemente ist praktisch nicht möglich. Dennoch sollen nachfolgend die wichtigsten Spiel-Design-Elemente kurz erläutert werden. In der Literatur gibt es diverse Ansätze zur Auflistung von Spiel-Design-Elementen. Keine der Auflistungen kann als abgeschlossen angesehen werden. Dennoch bieten diejenigen nach Reeves und Read, Kapp und Koch einen guten Überblick über mögliche Elemente, weshalb sie nachfolgend kurz dargestellt werden. In ihrer Sammlung Ten Ingredients of Great Games haben sich Reeves und Read mit Spiel-Design-Elementen auseinandergesetzt. Sie nennen hier die Selbstdarstellung durch Avatare, eine packende Geschichte, Feedback, Marktplätze und Wirtschaftssysteme, Ansehen sowie Rang und Levels, Wettbewerbe und Teams sowie Zeitdruck als die wichtigsten Elemente eines erfolgreichen Spiels. Die Elemente dreidimensionale Umgebung und parallele Kommunikation stellen keine Spiel-Design-Elemente im eigentlich Sinn dar, werden von den Autoren aber dennoch angeführt.
Kapp beschreibt Regeln, Ziele, Konflikte, Wettbewerb, Kooperation, Zeit, Belohnungssysteme, Feedback, Levels, Geschichte und Ästhetik als typische Elemente, die für Spiele charakteristisch sind. Die Auflistung von Reeves und Read wird also um die Punkte Ästhetik, Belohnungssysteme, Regeln und Ziele ergänzt. Koch et al. untersuchen Spiel-Design-Elemente im Zusammenhang mit Unternehmenssoftware und legen sozialen Wettbewerb und sichtbaren Fortschritt, Ranglisten und Level, Aufgaben, Feedback, eine schrittweise Darbietung von Informationen, Gruppendynamik, Countdowns und Überraschungen als wichtige Spiel-Design-Elemente fest. Neu in der Auflistung nach Koch et al. sind die Elemente sichtbarer Fortschritt, Aufgaben – sogenannte Quests –, die schrittweise Darbietung von Informationen sowie Überraschungen.
Anwendungsgebiete von Gamification
Eingangs wurde das FuelBand von Nike vorgestellt. Das Unternehmen kündigte bereits im Jahr 2014 an, die Weiterentwicklung der sogenannten Wearables einzustellen. Börsenanalysten zufolge musste Nike zu diesem Schritt greifen, da das Unternehmen sich gegen größere Mitbewerber wie Google oder Apple am Markt langfristig nicht durchsetzen konnte. Zum 30.04.2018 erfolgte die endgültige Einstellung des Nike Fuel Programms. Auch hinter Bonusprogrammen im Einzelhandel oder Kundenbindungsprogrammen von Airlines verbergen sich Ansätze der Gamification. Bei Programmen wie Payback, Miles & More oder Emirates Skywards werden Kunden für den Konsum oder das Nutzen von Leistungen eines Unternehmens mit Punkten belohnt, füllen damit ihr digitales Konto und können die gesammelten Punkte später gegen Prämien eintauschen.
Neben Programmen zur Kundenbindung finden sich abseits des Marketings noch zahlreiche andere Anwendungsgebiete von Gamification. Insbesondere im Bildungsbereich erfreut sich Gamification in den letzten Jahren großer Beliebtheit. Verschiedene Studien untersuchten den Einsatz und die Wirkung von Gamification im Hochschulbereich, vor allem durch das Sammeln von Punkten oder Abzeichen für das erfolgreiche Ablegen von E-Learning-Kursen der jeweiligen Bildungsinstitute. Die kürzlich veröffentliche Studie Gamification4Good befasst sich mit der Frage, wie Gamification in deutschen Schulen eingesetzt werden kann. Auch die für Bildung zuständigen Ministerien haben Interesse am Thema Gamification bekundet. Zudem versucht die Gesundheitsbranche vom Einsatz von Spiel-Design-Elementen zu profitieren. Von Apps zur Ernährungsberatung oder dem digitalen Fitnesstraining bis hin zu solchen, die der Dokumentation von Schmerzempfindungen bei Krebspatienten oder der Messung des Blutzuckerwertes bei Diabetespatienten dienen, motivieren Punkte, Levels, digitale Belohnungen und direktes Feedback zur regelmäßigen Nutzung der Anwendungen. Das US-amerikanische Unternehmen Bunchball bietet seit 2007 Lösungen zur Integration von Gamification in Unternehmenssoftware wie SAP, Jive oder Salesforce an und bezeichnet sich selbst als Marktführer im Bereich Gamification von Business-Software. Je nach Einsatzbereich variieren die Ziele, die mit dem Einsatz von Spiel-Design-Elementen erreicht werden sollen. So kann die Spielifizierung beispielsweise zur Förderung des Wohlbefindens oder der Motivation der Beteiligten, zur Erhöhung des Engagements und der Einsatzbereitschaft für ein Ziel, zur Förderung der Zusammenarbeit und Interaktion und schließlich zur Lernförderung eingesetzt werden.
Das Octalysis-Framework
Der taiwanesische Autor und Gamification-Forscher Yu-Kai Chou übt Kritik an dem gegenwärtigen Verständnis von Gamification, da sich viele Betrachtungsweisen nur auf die reine Technik fokussieren. Chou differenziert hingegen das ‚Functionfocused Design‘ vom ‚Human-Focused Design‘ und erklärt, dass Gamification nur dann wirkungsvoll ist, wenn es sich um Methoden des ‚Human-Focused Designs‘ handelt, also der Mensch im Fokus der Entwicklung steht.
Mehrfach weist Chou in seinem Werk Actionable Gamification Beyond Points, Badges and Leaderbords darauf hin, dass es bei Gamification nicht nur darum geht, Spielmechaniken auf einen spielfremden Kontext anzuwenden. In seiner Kritik an einer Mehrheit der Gamification-Designer wirft er diesen vor, sich zu stark auf die Implementierung von Points, Badges und Leaderboards (PBL) – also Punkten, Abzeichen und Ranglisten – zu fokussieren.
Der Erfolg eines Spiels hängt nach Chou nicht von der Anzahl der Spielmechaniken ab, sondern davon, ob die verwendeten Spielmechaniken den Nutzer auch erreichen und motivieren können. Bezogen auf die Gamifizierung des IT-Projektmanagements bedeutet dies konkret, dass auf die Wünsche und Bedürfnisse der Projektbeteiligten eingegangen werden muss und eine bloße Implementierung von Spielmechaniken in den Kontext des Projektmanagements langfristig keinen Erfolg haben wird. Jedes Spiel oder jedes Spiel-Design-Element spricht laut Chou mindestens einen der insgesamt acht Motivationsfaktoren an. Chou bezeichnet diese Motivationsfaktoren als Core Drives und erklärt, dass jede Handlung, die ein Mensch tätigt, auf mindestens einem Core Drive basiert. Die Motivationsfaktoren fasst Chou in dem Modell Octalysis zusammen. Die acht Begriffe werden dabei in einem Oktagon angeordnet.
Die Core Drives nach Chou, also die Grundlage allen spielerischen Handelns, sind:
- epische Bedeutung und Berufung (Epic Meaning & Calling),
- Entwicklung und Leistung (Development and Accomplishment),
- Selbstbestimmung zur Kreativität und Feedback (Empowerment of Creativity & Feedback),
- Besitz und Eigentum (Ownership & Possession),
- Sozialer Einfluss und Verbundenheit (Social Influence & Relatedness),
- Seltenheit und Ungeduld (Scarcity & Impatience),
- Unberechenbarkeit und Neugier (Unpredictability & Curiosity) sowie Verlust und Vermeidung (Loss & Avoidance).
Yu-Kai Chou unterteilt die einzelnen Motivationsfaktoren in extrinsische Motivatoren, die sogenannten Left Brain Drives, und intrinsische Motivatoren, Right Brain Drives. Die Left Brain Drives Leistung, Besitz und Seltenheit kennzeichnen sich dadurch, dass sie mit Logik, Analyse und Besitztum assoziiert werden können und eher extrinsische Motivatoren darstellen. Die intrinsischen Right Brain Drives Selbstbestimmung, Sozialer Einfluss und Unberechenbarkeit sind eher emotionale Motivatoren.
Wird das Octalysis-Modell zur Analyse einer gamifizierten Anwendung bzw. eines Prozesses benutzt, lässt sich relativ unkompliziert feststellen, welcher Motivator stark bzw. überhaupt nicht angesprochen wird und ob die Spiel-Design-Elemente eher extrinsisch oder intrinsisch motivierend sind. Basierend auf diesen Erkenntnissen können dann Verbesserungen vorgenommen werden.
Im Modell kann auch zwischen eher positiven Motivatoren wie Leistung, Bedeutung und Selbstbestimmung und eher negativen Motivatoren wie Seltenheit, Verlust und Unberechenbarkeit differenziert werden. Chou nennt die positiven Motivatoren White Hat und die negativen Black Hat Core Drives.
Mit der Frage, wie das Framework Scrum durch Methoden der Gamification sinnvoll ergänzt werden kann, haben sich bislang einige Forscher befasst und Praxisvorschläge erarbeitet, die nachfolgend vorgestellt werden sollen. Die Vorschläge beziehen sich in der Literatur bislang nur auf Scrum als Gesamtprozess, eine auf die Gliederung dieses Prozesses Rücksicht nehmende Bewertung der Spielifizierung der einzelnen Scrum-Ereignisse findet nicht statt.
Gamifizierung im Projektmanagement
Im IT-Projektmanagement existieren verschiedene Projektmanagementmethoden und -standards. Grundsätzlich können klassische Vorgehensweisen von agilen Methoden und Frameworks unterschieden werden. Beispiele für klassische Projektmanagementmethoden unabhängig von der Branche sind die Competence Baseline der International Project Management Association (IPMA), der PMBOK Guide des Project Management Institute (PMI) sowie die Projektmanagementmethode PRINCE.
Jeff Sutherland und Ken Schwaber gelten als Entwickler des Vorgehensmodells Scrum. Der Begriff Scrum – zu Deutsch Gedränge – stammt ursprünglich aus der Rugby-Sprache und beschreibt das Gedränge der beiden Mannschaften auf dem Spielfeld nach einem Foul. Scrum ist ein Rahmenwerk – auch Framework genannt – zum agilen Projektmanagement.
Im Gegensatz zu klassischen Projektmanagementmethoden stehen bei agilen Methoden vor allem Werte wie Transparenz, Kommunikation, Kooperation und die eigenständige Organisation von Teams im Fokus. Scrum wird hauptsächlich in Softwareentwicklungsprojekten eingesetzt, ist aber an sich nicht an eine Branche oder einen Einsatzbereich gebunden. Grundlage von Scrum sind festgelegte Rollen, Ereignisse, Artefakte und Regeln, die im Scrum Guide definiert werden. Im Grunde besteht Scrum aus drei Rollen, drei Artefakten, vier Ereignissen und fußt auf drei Säulen. Der Ablauf vollzieht sich dabei in abgeschlossenen Zyklen, die Sprints genannt werden. Ziel eines Sprints ist es, einen „Gegenstand inspizierbarer, fertiger Arbeit“ herzustellen, ein sogenanntes Inkrement.
Generell wird unabhängig von einer konkreten Aktivität im Scrum Guide darauf hingewiesen, dass alle Beteiligten des Scrum-Teams die Werte leben und verkörpern sollen, für die Scrum steht. Scrum basiert auf den Werten Mut, Selbstverpflichtung, Fokus, Offenheit und Respekt. Eine Voraussetzung dieser Werte zieht sich wie eine Vision durch alle Scrum-Aktivitäten.
In gewisser Weise ist demnach bei jeder Scrum-Aktivität der Core Drive Bedeutung angesprochen, da die Beteiligten – hier das Entwicklungsteam – Teil dieser Vision werden und die Werte aktiv leben sollen. Auch das Sprint Planning selbst steht unter einer eigenen Vision. So wird im Sprint Planning festgelegt, welches Inkrement während des Sprints hergestellt werden soll. Der Scrum Guide spricht hier von dem Festlegen eines Sprint-Ziels. Neben dem Ziel, das über dem Sprint Planning steht, kommt dem Entwicklungsteam hier aber auch eine hohe Entscheidungskompetenz zu. Diese Entscheidungskompetenz spricht unter anderem den Core Drive Bedeutung an, da den Teammitgliedern vermittelt wird, dass nur sie dazu berufen sind, die Frage zu beantworten, wie genau die anfallende Arbeit im Sprint zu erledigen ist.
Die Entscheidungskompetenz im Sprint Planning wird an mehreren Stellen im Scrum Guide explizit festgeschrieben. So bestimmt „ausschließlich das Entwicklungsteam […] die Anzahl der ausgewählten Product-Backlog-Einträge für den kommenden Sprint“, denn „nur es selbst kann beurteilen, was im kommenden Sprint machbar ist“.
Der Core Drive „Bedeutung“ wird somit stark angesprochen und ist mit 7 von 10 Punkten zu bewerten. Die bisherige Leistung des Teams wird im Sprint Planning vorgestellt. Durch diese Offenlegung werden Fortschritte und Leistung des Teams sichtbar und der Core Drive „Leistung“ angesprochen. Das Sprint-Ziel spricht also nicht nur den Core Drive Bedeutung an. Auch die Leistungsbereitschaft wird hier in Anspruch genommen. Das gemeinsam vereinbarte Ziel im Sprint ist als eine Messlatte zu sehen, die vom Entwicklungsteam erreicht werden muss. Insgesamt sind im Scrum Guide zwar Punkte vorhanden, die den Core Drive Leistung ansprechen, es werden aber keine konkreten Ausgestaltungen definiert, weshalb der Core Drive Leistung im Sprint Planning mit nur 3 von 10 Punkten zu bewerten ist.
Das Bedürfnis der Entwickler, sich selbst auszuleben und die eigene Kreativität bei Erfüllung der Aufgaben zu nutzen, wird im Sprint Planning stark angesprochen. Das Entwicklungsteam darf eigenständig über die Ausgestaltung der zu erledigenden Arbeit entscheiden. Das Ziel wird gemeinsam mit den anderen Beteiligten im Scrum Team besprochen, der Weg dorthin ist aber eigenständig durch die Entwickler festzulegen.
Die Entwickler entscheiden dabei auch selbstständig über den Umfang der zu erledigenden Arbeit, also wie viele Teile des Product Backlogs im kommenden Sprint umgesetzt werden sollen. Die große Freiheit des Entwicklungsteams kann durchaus als motivierend angesehen werden, weshalb der Core Drive „Selbstbestimmung“ mit 7 von 10 Punkten bewertet wird.
Der Core Drive „Besitz“ wird nur insofern angesprochen, als die Entwickler durch Auswählen von Einträgen des Product Backlogs und Überführung dieser in das Sprint Backlog quasi Eigentümer der Spezifikationen werden. Das Sprint Backlog wird in dieser Arbeit aber hauptsächlich dem Bereich Daily Scrum zugeordnet, da im Rahmen des Sprint Plannings hier zwar Vorarbeiten geleistet werden, die tägliche Arbeit am Backlog aber im Daily Scrum stattfindet. Der Core Drive wird daher nur mit 1 von 10 Punkten bewertet.
Dadurch, dass die Entwickler mit dem Scrum Master und dem Product Owner zusammenarbeiten und auch andere Personen in das Sprint Planning einladen dürfen, wird der Core Drive „Sozialer Einfluss“ angesprochen. Der Plan im Sprint Planning wird gemeinschaftlich erstellt, was gamifiziert gesprochen einem Gruppen-Quest, also einer Gruppenaufgabe, entspricht. Der soziale Einfluss wird mit 4 von 10 Punkten bewertet, da er zwar vorhanden, aber nicht sehr stark ausgeprägt ist. Zu den Core Drives „Seltenheit“ und „Unberechenbarkeit“ wurde keine passende Textpassage gefunden, weshalb beide mit 0 von 10 Punkten bewertet werden. Dadurch, dass eine maximal verfügbare Zeitspanne für das Sprint Planning – in der Regel bis zu acht Stunden – vorgegeben wird, sehen sich die Beteiligten im Sprint Planning dazu angehalten, möglichst schnell zu einem sinnvollen Ziel zu kommen. Der Core Drive „Verlust“ wird durch diesen Umstand bedingt angesprochen. Zwar steht nur eine begrenzte Zeit zur Verfügung und die Beteiligten möchten sich vor der negativen Situation – also dem Überschreiten der Zeit – schützen, die acht Stunden stellen dabei aber eine kaum zu erreichende Obergrenze dar, die für kleinere Sprints in der Regel zu hoch angesetzt ist. Der Verlust daher wird nur mit 1 von 10 Punkten bewertet.
Aus der Textanalyse des Scrum Guide ergibt sich zusammenfassend die in Tabelle 4 dargestellte Beurteilung der Core Drives im Sprint Planning. Das Sprint Planning erreicht einen GF von 125 Punkten. Der Aufwandsschätzung kommt im Sprint Planning eine große Bedeutung zu. Eine Variante, den Aufwand zu schätzen, stellt dabei das sogenannte Planning Poker oder Estimation Poker dar. Planning Poker bezeichnet eine Methode, in der die Teammitglieder mittels Spielkarten den Aufwand zur Umsetzung einer Produktanforderung einschätzen. Jeder Teilnehmer erhält einen Satz an Karten, aus dem er jeweils eine Karte auswählt, um den Aufwand eines Product Backlog Items zu schätzen.
Alle Teilnehmer schätzen den Aufwand zur gleichen Zeit und die Schätzung wird so oft wiederholt, bis in der Gruppe ein Konsens hergestellt ist. Als Maß für den Aufwand kann auch statt Personentage der Begriff Story Points verwendet werden. Jeder Aufgabe ist je nach Komplexität eine bestimmte Punktzahl zuzuweisen, die vom Entwicklerteam zu Beginn festgelegt wird. Über verschiedene Sprints hinweg lässt sich so analysieren, wie viele Story Points das Entwicklungsteam durchschnittlich in einem Sprint abarbeitet.
Die Schätzung mittels Planning Poker und Story Points spricht die Core Drives Leistung, Selbstbestimmung, Sozialer Einfluss und Unberechenbarkeit an. Der Core Drive Leistung wird angesprochen, da die Story Points in folgenden Scrum-Ereignissen als Fortschrittsanzeige verwendet werden können. Im Sprint Planning erhöht sich die Bewertung des Core Drives so auf 4 von 10 Punkten. Dadurch, dass jedes Teammitglied selbst eine Entscheidung trifft, welche Karte es beim Planning Poker dem Product Backlog Item zuweist oder wie viele Story Points das Mitglied der Anforderung zuordnet, wird die Selbstbestimmung gefördert und mit 8 von 10 Punkten neu bewertet. Auch der Soziale Einfluss gewinnt einen Punkt in der Beurteilung, da die Teammitglieder die Schätzung gemeinsam durchführen und dies nach Chou motivierend wirkt. Durch den Einsatz von Spielkarten im Planning Poker wird die Neugier bei den Beteiligten geweckt, da sie vor der ersten Schätzung nicht wissen, wie die anderen Teammitglieder die Anforderung einschätzen. Nach Chou ist diese Situation förderlich für den Core Drive Unberechenbarkeit, der durch den Einsatz von Planning Poker daher mit 2 von 10 Punkten bewertet wird.
Die Abbildung zeigt das Ausmaß der Gamifizierung im Sprint Planning. Die blaue Fläche beschreibt die Beurteilung nach der Textanalyse des Scrum Guides und die orange Fläche stellt die Gamifizierung des Sprint Plannings dar, wenn die Methoden Planning Poker und Story Points zum Einsatz kommen. Durch Planning Poker und Story Points erhöht sich der GF von 125 auf 160 von insgesamt 800 Punkten.
Gamification von Scrum
Es ist auf diese Weise möglich, die anderen Elemente wie Sprint Review oder die einzelnen Sprints ebenfalls zu bewerten. Wir wollen an dieser Stelle ein Zwischenfazit ziehen. Mit Hilfe der einfachen Methode einer Textanalyse gelingt es leicht, wirkungsvoll die Gamifizierung von Scrum aufzuzeigen. Geht man in diesem Sinne Daily Scrum, Sprint Review und Sprint Retrospektive durch, ergibt sich für die Gamification des gesamten Scrum (nach einer Durchschnittsbildung) folgendes Bild:
Optimierung der Punkte in der Praxis
Scrum als Gesamtprozess hat einen GF von 97,75 Punkten nach der Analyse des Scrum Guide bzw. 130,31 Punkten wenn man die Praxisvorschläge annimmt, die wir im Folgenden diskutieren wollen. Die Core Drives Seltenheit und Unberechenbarkeit werden gar nicht bzw. nur in geringem Maße angesprochen. Grundsätzlich werden eher die White Hat Core Drives, also die positiv motivierenden Core Drives, verstärkt.
Dies führt dazu, dass sich das Entwicklungsteam zwar bestärkt und positiv fühlt, dabei allerdings der nötige Druck fehlen könnte. Durch die Implementierung von Black Hat Core Drives lässt sich eine Spannung aufbauen, die zusätzlich motivierend wirkt. Vor allem die Faktoren Seltenheit und Unberechenbarkeit sollten stärker angesprochen werden.
Ein Element zur Erweiterung des Daily Scrums sind die Story Points. Die einzelnen Einträge aus dem Product Backlog werden im Sprint Planning im Hinblick auf den Aufwand mit Story Points bewertet. Aus der Sammlung der Product Backlog Einträge werden im Planning Elemente für den nächsten Sprint ausgewählt und diese in das Sprint Backlog überführt. Das Entwicklungsteam bespricht in den Daily Scrums täglich die erreichten Fortschritte.
Da jedem Punkt des Sprint Backlogs Story Points zugewiesen sind, kann im Daily Scrum der bereits erreichte Punktestand an Story Points berechnet und veranschaulicht werden. In ihrem Artikel zur Gamifizierung von Scrum machen Dopatka, Ondrusch und Schumacher den Vorschlag, den einzelnen Teammitgliedern im Daily Sprint je nach Arbeitsaufwand anteilig am Gesamterfolg Story Points als eine Art digitale Währung gutzuschreiben. Die von den Teammitgliedern gesammelten Story Points können entweder in eine Rangliste münden oder von den Mitgliedern gegen Belohnungen eingetauscht werden. Dies zeigt in der Praxis eine enorme Wirkung. Es erhöht außerdem den Wert für Besitz auf 1,75.
Weitere Praxisempfehlungen zur Gamifizierung des Daily Scrums sind die Vergabe von Abzeichen oder Rangtiteln für Aktionen der Teammitglieder wie beispielsweise die regelmäßige Teilnahme oder das Einhalten der Zeitvorgaben.
Die Methodik des Blind Sprint Backlog hat einen starken Einfluss auf den Core Drive Unberechenbarkeit. Man zieht „blind“ eine Aufgabe aus dem Backlog heraus, die an diesem Tag gelöst werden muss. Da die Mitglieder zu Beginn des Tages nicht wissen, welche Aufgabe aus dem Sprint Backlog sie erfüllen müssen, ist die Situation in sich unberechenbar und weckt Neugier bei den Beteiligten. Die Unberechenbarkeit erhöht sich durch Einsatz der Methode Blind Sprint Backlog auf 5 von 10 Punkten für dieses Element und setzte einen Wert für das gesamte Scrum auf 1,75. In der Praxis zeigt sich, dass die Gamifizierung von Sprint Reviews keine Erfolge gebracht hat.
In der Sprint Retrospektive wird deutlich, was das Team im vergangenen Sprint geleistet hat und wie die einzelnen Teammitglieder hierzu beigetragen haben. Eine in der Praxis empfohlene Methode, die Teamleistung im Vergleich zu früheren Sprints zu visualisieren, bildet die sogenannte Velocity. Die Velocity eines Teams berechnet sich aus der Summe der erreichten Story Points, die den jeweiligen Aufgaben zugwiesen wurden. Aus den erzielten Punkten wird ein Durchschnitt gebildet, der die Teamgeschwindigkeit darstellt. Erzielt ein Team im ersten Sprint beispielsweise 20 Story Points durch das erfolgreiche Abarbeiten von 2 Aufgaben und im aktuellen Sprint nur 10 Story Points, so beträgt die durchschnittliche Velocity des Teams 15. Anhand des Mittelwertes über alle Sprints hinweg kann die Leistung des vergangenen Sprints besser eingeschätzt werden.
Die Errechnung der Velocity spricht deutlich den Core Drive Leistung an, da hierdurch die Effektivität des Teams über alle Sprints hinweg sichtbar wird. Auch der soziale Einfluss wird bedingt angesprochen, da die Teammitglieder hier in einen Wettbewerb mit sich selbst treten und die Steigerung der Velocity zu einer Gruppenaufgabe wird. Beide Core Drives erhalten zwei weitere Punkte im Bereich Retrospektive, wodurch sie einen Gesamtwert von jeweils 7 Punkten erreichen. Für Scrum bedeutet dies eine Steigerung auf 6,25 und im Punkt Selbstbestimmung auf 5. Der soziale Einfluss steigert sich auf 5.
Als weitere Vorschläge zur Erhöhung der Gamification im Scrum bieten sich an: Der Core Drive Seltenheit und Ungeduld wird im Rahmen des Sprint Reviews bislang gar nicht angesprochen. Chou schlägt zur Einbeziehung dieses Core Drives das Spiel-Design-Element Magnetic Caps – übersetzt etwa magnetische Obergrenze – vor. Hierbei wird für eine gewisse Aktion oder Aktivität eine Obergrenze festgelegt, die nicht zu überschreiten ist. Die Obergrenze soll für eine Aktivität festgelegt werden, die die Anwender nicht gern ausführen. Magnetisch ist diese Grenze insofern, als sie die Nutzer dazu motiviert, die Aktivität dennoch durchzuführen. Meist gilt das Erstellen einer Dokumentation von Funktionalitäten in der Softwareentwicklung als unbeliebt. Um diesem Phänomen entgegenzuwirken, könnten die Entwickler angehalten werden, im Sprint Review eine kurze Dokumentation der Funktionalität vorzustellen, die allerdings auf eine Höchstzahl an Wörtern pro Funktionsbestandteil begrenzt ist. Es gilt noch dieses Element in der Praxis zu verproben.
Nach dem Scrum Guide sollte ein Sprint Review Meeting maximal vier Stunden dauern. Um diese Zeitvorgabe besser einzuhalten, kann als Spiel-Design-Element ein Countdown Timer eingesetzt werden. Nach Chou motiviert die Anzeige der noch verbleibenden Zeit und spricht den Core Drive Verlust und Vermeidung an. In einem Probedurchlauf konnte dieser Aspekt bereits positiv getestet werden.
Situationen im Pilot-Projekt
Die Textanalyse und die Optimierungspunkte in der Praxis ergaben ein erstes interessantes Bild. Projekte, die schlecht laufen, tendieren dazu entweder mehr Mittel zu beanspruchen oder Unterstützung von außen zu holen. Doch was ist mit den intrinsischen Motivationsfaktoren? Gerade die Aspekte des Zufalls oder der Überraschung können für zusätzliche Motivation und Abwechslung sorgen. Im oft zitierten CHAOS Report der Standish Group werden Gründe angegeben, warum Projekte scheitern. Scheitern Projekte sind auch Mitarbeiter unzufrieden. Mitarbeiter verlassen ein Unternehmen in der Regel aus verschiedenen Gründen. In den Studien kommt immer wieder das Thema „Unzufriedenheit“ vor. Besonders junge Menschen der nachfolgenden Generation beklagen, dass sie das Gefühl haben in einer Sackgasse zu stecken und sich nicht entwickeln können. Gerade hier kann Gamification auch Abhilfe schaffen. Steigert man den Zufall und damit die Unvorhersehbarkeit von Projekten erhöht sich nicht nur der Core Drive, sondern auch die Möglichkeit das berühmte Gefühl „etwas Neues zu machen“. Das Projektteam, im gewählten Pilotprojekt, bestand aus ca. 20 Leuten, die in einem mittelständischen Unternehmen an einem 2 Jahresprojekt mitgearbeitet haben. Ein buntes Team aus Sachbearbeitern eines Fachbereiches und vielen Entwicklern unterschiedlicher Technologien. An dieser Stelle ist es unmöglich, dass alle Mitglieder des Projektes auch alles machen können. Kein Sachbearbeiter wird über Nacht ein ABAB Programmierer.
Aus diesem Grund wurden im Pilotprojekt sogenannte „Task Pools“ gebildet. Task Pools sind Gruppen von Aufgaben, die einen ähnlichen Charakter haben und ausgewählten Mitarbeitern zugeordnet werden. Dabei kann es sich um einfache Sachaufgaben handeln bzw. auch um einfache Programmierung. In der Praxis hat sich gezeigt, dass sich bei einer Projektgröße von ca. 20 Mitarbeitern etwa 5 – 7 Taskpools anbieten können. Nachdem man ein Muster in den Aktivitäten erkannt hatte, konnte man den einzelnen Pools auch Namen geben. Der interessanteste Pool (Kontrolle & Qualität) bestand in einer Woche beispielsweise ausfolgenden Aktivitäten:
- Kreditlinien überprüfen (fachlich)
- Kontrahentenlimite abgleichen (fachlich)
- Sourcecode Checks durchführen (technisch)
- Auswertungen des automatischen Tests vergleichen (technisch)
- Projektplan prüfen und ergänzen (organisatorisch)
Man beachte an dieser Stelle, dass sich auf diese Weise einfache Aufgaben aus verschiedenen „Welten“ in einem Pool befanden. Das Bedürfnis, eine wiederkehrende Tätigkeit einer anderen Person zu geben und gleichzeitig dafür zu sorgen, dass sich die Teamgruppen im Projekt untereinander austauschen können, erhöhte die Core Drives für Sozialisation (sozialer Einfluss) und Unberechenbarkeit. Der Level, auf dem sich die Aufgaben befanden war ungefähr gleich. Jeder konnte eine dieser Aufgaben schnell übernehmen. Entwickler checkten fachliche Kreditlinien und Sachbearbeiter untersuchten Quellcode mit Tests nach Lücken oder Fehlern. Mit einfachen Worten oder einer kurzen Erklärung konnte das Wissen für die Tätigkeit bereitgestellt werden. In einem zweiten Schritt verstand man schnell, was Kreditlinien sind oder was es für Kontrollen und Analysen im Sourcecode gibt und welche Hinweise man den Entwicklern zuführen kann. Der Nebeneffekt: Projektmitarbeiter konnten sich durch ihre Zuteilung für einen Sprint aus dem Pool „Kontrolle & Qualität“ auch gut in die jeweils „andere Welt“ hineindenken. Oftmals erlebt man, dass wenig Verständnis für technische Tätigkeiten vorherrscht, die keine Funktionalität beinhalten oder man auf der anderen Seite kein Problembewusstsein hat für tägliche Arbeiten, die eine hohe Wichtigkeit in der Firma haben.
Das Pooling der Themen in diese Form der Sprints muss nicht auf ewig Bestand haben, kann aber dazu führen, einen kurzen aber sehr effizienten Motivationsschub auszulösen. Gerade die Kombination aus diesen Core Drives ist sehr wertvoll und sollte nicht unterschätzt werden.
Fazit
Die dargelegten Ergebnisse bieten Anlass für weitere Forschungsfragen. So gilt es zu untersuchen, ob verschiedene Spielertypen Gamification unterschiedlich wahrnehmen und inwiefern Gamification auch in Projektmanagementmethoden wie IPMA, PMI oder Prince2 angewendet werden kann.
Ebenso wurden Elemente in der Praxis zwar verprobt, jedoch sollte man weitere Untersuchungen starten, die dazu führen, andere Core Drives zu verstärken oder in den Mittelpunkt zu stellen. Es wurde noch kein Praxisvorschlag gefunden, welcher den Core Drive Seltenheit anspricht.
Zusammenfassend betrachtet sollten die Core Drives Seltenheit und Unberechenbarkeit generell stärker angesprochen werden. Das Daily Scrum zeigt bereits eine gute Gamifizierung. Die Scrum-Aktivität Sprint Review hingegen weist ein geringes Ausmaß an Spielifizierung auf. Wird das Sprint Review um Methoden wie das Sprint-Ziel, das Blind Sprint Review, Magnetic Caps oder Countdown Timer ergänzt, erhöht sich die Spielifizierung, also auch die Motivation des Entwicklungsteams.
Grundsätzlich sollte bei der Einführung gamifizierter Elemente in ein Unternehmen eine enge Abstimmung mit Interessensvertretern wie dem Betriebsrat stattfinden. Vor allem das Sichtbarmachen von Fortschritten und die Einführung von Teambeurteilungen können als Werkzeuge für unzulässige Mitarbeiterkontrolle missbraucht werden.
Autoren
Thomas Oster studierte berufsbegleitend Betriebswirtschaftslehre und IT-Management an der FOM Hochschule in Frankfurt am Main. In seiner Master-Thesis zum Thema Ga-mification im IT-Projektmanagement untersuchte er die Anwendung von Spiel-Design-Elementen im Rahmen des Projektmanagements. In seiner aktuellen Funktion als Business Analyst bei einem familiengeführten Mittelständler bildet er die Schnittstelle zwischen Fachbereich und IT.
xing.com/profile/Thomas_Oster3
linkedin.com/in/thomas-oster-80066a86/
Patrick Hedfeld studierte Theoretische Physik und Philosophie an der TU Darmstadt und an der Universidad de Salamanca. Nach seiner Dissertation über Kognitionspositionen bei Hegel ist er Publizist und Freier Dozent an der FOM Hochschule und hält dort Kurse über Wirtschaftsethik und IT-Management. Hauptberuflich arbeitet er als Senior IT Projektleiter bei der Deutschen Leasing AG in Bad Homburg.
![eStrategy Magazin letzte Ausgabe](/fileadmin/_processed_/8/c/csm_Cover-eStrategy-01-2023_a96559893d.jpg")
