SCRUM FOR GAMES | DAS TEAM ALS ZENTRALES ELEMENT DER GAMEENTWICKLUNG STEFAN RANDELSHOFER 2012

SCRUM FOR GAMES | DAS TEAM ALS ZENTRALES ELEMENT DER GAMEENTWICKLUNG Masterarbeit zur Erlangung des akademischen Grades »Master of Arts In Arts and Design« Verfasser: Mag. (FH) Stefan Randelshofer

Vorgelegt am FH-Studiengang MultiMediaArt, Fachhochschule Salzburg

Begutachtet durch: Mag.a Jeanny Gucher (inhaltliche Gutachterin 1) Prof. Mag. Dr. Gerhard Blechinger (inhaltlicher Gutachter 2)

Salzburg, 10.05.2012

 

DANKSAGUNG Ruhm. Ehre und vor allem Dank geht an:

Meine Verlobte Iva, für ihre Liebe, ihre moralische und tatkräftige Unterstützung und dafür, dass es diesmal einfach war. Meine Mutter Renate, wieder einmal für die Ruhe. Meinen Vater Helmut, wieder einmal für die Energie. Meinen Freunden Seppi und Harry, dafür dass es sie gibt und ich mich seit mittlerweile fast einem viertel Jahrhundert auf sie verlassen kann. Meinem Freund Mike, dem dieses Mal der Stress erspart blieb. Meine Betreuerin Jeanny Gucher, für die Hilfe, einen roten Faden für die Arbeit zu finden und die viele zusätzliche Beratungszeit. Meinen Betreuer Gerhard Blechinger, für die guten Tipps und die spannende Diskussion über die Postmoderne. Meinen Freund und Kollegen Josef Schinwald, dafür, dass er mein Gejammer über das Schreiben dieser Thesis ertragen hat und für die Hilfe und das Game-Design bei Don´t Drop! Meinen Kollegen Michael Manfé, für die Hilfe bei den Formalitäten dieser Arbeit. Meinen Ausbilder zum ScrumMaster Boris Gloger, für den überzeugenden Einblick in die Materie. Mein Team von Don´t Drop! - für die gute Zusammenarbeit und das tolle Produkt, welches wir innerhalb eines Jahres zusammen auf die Beine gestellt haben: Roland Haagen, Iva Müller, Doris Wimmer, Martin Klappacher, Phillip Huber und Alexander Cerny.

EIDESTATTLICHE ERKLÄRUNG Hiermit versichere ich, Stefan Randelshofer, geboren am 10.06.1978 in Traunstein, dass ich die Grundsätze wissenschaftlichen Arbeitens nach bestem Wissen und Gewissen eingehalten habe und die vorliegende Masterarbeit von mir selbstständig verfasst wurde. Zur Erstellung wurden von mir keine anderen, als die angegebenen Quellen und Hilfsmittel verwendet. Ich versichere, dass ich die Masterarbeit weder im In- noch Ausland bisher in irgendeiner Form als Prüfungsarbeit vorgelegt habe und dass diese Arbeit mit der, den BegutachterInnen vorgelegten Arbeit übereinstimmt.

Salzburg, am 10.05.2012



1010627033

Stefan Randelshofer

Matrikelnummer

 

KURZFASSUNG Vor- und Zuname:

Mag. (FH) Stefan Randelshofer

Institution:

FH Salzburg

Studiengang:

MultiMediaArt

Titel der Diplomarbeit: Scrum for Games |

Das Team als zentrales Element der Gameentwicklung

Begutachterin 1:

Mag.a Jeanny Gucher

Begutachter 2:

Prof. Mag. Dr. Gerhard Blechinger

Schlagwörter:

1. Scrum



2. Team



3. Agile Methode



4. Management



5. Videospiele



6. Game

KURZBESCHREIBUNG Unsere Gesellschaft und die Arbeit, die in ihr verrichtet wird, hat sich seit der Industrialisierung stark gewandelt. Der/die moderne WissensarbeiterIn hat bereits bei einem Drittel der heute verrichteten Arbeit den/die FacharbeiterIn ersetzt. Wir befinden uns innerhalb eines Paradigmenwandels des Arbeitsmarktes. Diesem Wandel muss auch auf Führungs- und Managementebene mit Vernunft gegenübergetreten werden. Der/die ManagerIn kann auf Grund der enormen Spezialisierung der ExpertInnen keine direkten Arbeitsanweisungen mehr geben, so wie es früher üblich war, da er/sie die Expertise seiner/ ihrer WissensarbeiterInnen nicht mehr teilt. Seine/ihre Aufgaben sollten vielmehr in eine dienende Rolle verschoben werden. Er/sie soll den/die WissensarbeiterIn bei seiner/ihrer Arbeit unterstützten und ihm/ihr einen Impediment-freien Arbeitsraum zur Verfügung stellen. Der/die ManagerIn ebnet in erster Linie den Weg für die Arbeit der ExpertInnen. Dazu bedarf es neuer Managementmethoden und Frameworks in denen diese umgesetzt werden können. Bei der Gameentwicklung, die vollkommen in dieses Schema fällt, bietet sich Scrum als agile Managementmethode für Software an. Es geht genau auf solche Voraussetzungen ein und stellt dem/der modernen ManagerIn Methoden und Wege zur Verfügung, um sich in seine/ihre neue Rolle einzufinden. Zusätzlich ermöglicht es auch den WissensarbeiterInnen, sich ihrer, mittlerweile partizipativen Aufgabe als Team zu stellen. In Scrum liegt es nun an dem/der WissensarbeiterIn, sich auf Grund seiner/ ihrer Expertise um die Wege der Umsetzung und die entsprechende Selbstorganisation eigenständig zu kümmern. Damit rückt das Scrum-Team in den Mittelpunkt der Gameentwicklung. In der vorliegenden Arbeit wird dieses Thema genauer durchleuchtet und es werden das Team als Mittelpunkt des Scrumprozesses in der Gameentwicklung und die Vorteile, die sich daraus ergeben, detailreich beschrieben.  

ABSTRACT Since the industrialization, our society and its ways of working have gradually changed. Almost a third of nowadays' modern jobs is performed by knowledge workers, who slowly replaced the former majority of craftsmen. This situation lead to a paradigm shift of the employment market. Such changes affected people in many fields of expertise and now the leadership and management have to face this novel trend as well. Comparing to former working methods, the management is no longer able to instruct the employees in the same way as before, as they now are experts and their professional expertises exceed those of their superiors. The modern management resembles the model of a servant leadership, more than a directing authority. One of the main tasks of such a management is to support the knowledge workers and to ensure an impediment-free working environment for successful productivity of experts. In order to succeed, there is a need for new approaches and frameworks within the management. Especially in video game production, which is a good example for such new working constellations, Scrum offers many opportunities as an agile management method. Based on software engineering workflows, it is a suitable tool for modern managers, as it suggest several ways on how to deal with the recent development of the management level. Scrum also enables knowledge workers to increase their participation within the team and to enhance personal commitment. That way, each member of the team takes full responsibility of his/ her actions and it is up to everybody to increase the productivity by making use of their expertise. In Scrum, the team and its skills are the center of video game development. This present thesis deals with the issues of Scrum and the positioning of the team within this management method. It also describes advantages resulting from such approaches and their contribution to the overall productivity.

INHALTSVERZEICHNIS 1

Einleitung | Forschungsfrage

2

Begriffsklärung



2.1 Führung



2.2 Vertrauen



2.3 Innovation



2.4 Projekt



2.5 Expertentum



2.6 Diversität

3

Scrum | Der Prozess



3.1 Agile Methoden



3.2 Herkunft



3.3 Anwendungsbereiche



3.4 Prozess



3.4.1 Rollen



3.4.1.1 Team



3.4.1.2 ScrumMaster



3.4.1.3 Product Owner



3.4.1.4 Customer



3.4.1.5 End User



3.4.1.6 Manager



3.4.2 Artefakte

1 7 8 13 15 21 24 28 33 34 39 41 44 44 45 46 46 48 48 49 50 50



3.4.2.1 Product Backlog



3.4.2.2 Selected Product Backlog



3.4.2.3 Task Board

52



3.4.2.4 Burn Down Chart

53



3.4.2.5 Potentially Shippable Product Increment

54



3.4.2.6 Impediments Backlog

55



52



3.4.3 Meetings



3.4.3.1 Time-Boxed



3.4.3.2 Estimation Meeting



3.4.3.3 Sprint



3.4.3.4 Sprint Planning 1



3.4.3.5 Sprint Planning 2



3.4.3.6 Daily Scrum



3.4.3.7 Sprint Review



3.4.3.8 Sprint Retrospective

4 Scrum | Die Erfolgsmethode - Conclusio

4.1 Führung macht das Team



4.2 Das Team macht das Game

56 56 57 58 59 60 61 62 64 66 67 73

Quellenverzeichnis | Literatur

79

Quellenverzeichnis | Online

82

Anhang

83 A1



Werk | Don´t Drop!

ABKÜRZUNGSVERZEICHNIS Aufl.

Auflage

Ausg.

Ausgabe

Bd.

Band

bearb.

bearbeitete

bzw.

beziehungsweise

ca.

circa

ebd.

ebenda

erarb.

erarbeitete

erw.

erweiterte

etc.

et cetera

f.

und folgende Seite

ff.

und folgende Seiten

FH

Fachhochschule

Hrsg.

HerausgeberIn

o.A.

ohne Angabe

o.J.

ohne Jahr

o.O.

ohne Ort

o.T.

ohne Titel

o.V.

ohne VerfasserIn

Orig.

Orginal

S.

Seite

sog.

so genannte

überarb.

Überarbeitete

usw.

und so weiter

vgl.

vergleiche

z.B.

zum Beispiel

zit.n.

zitiert nach

 

»Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.«

[AGILES MANIFEST] [BORIS GLOGER] »Im Sprint regiert das Team.«

»Manager führen Menschen mit unterschiedlichen Kenntnissen zusammen, um gemeinsam Ergebnisse zu erzielen. Sie haben die Aufgabe, die Stärken der Menschen für Leistungen zu nutzen und den Schwächen der Menschen ihre Bedeutung zu nehmen.«

[PETER F. DRUCKER]

»Production and management are like salt: A little helps a lot, but a lot ruins the dish.«

[LAURA FRYER]

»Jedes Ding is Gift und kein Ding ist ohne Gift, allein die Dosis mach, dass ein Ding kein Gift ist.«

[PARACELSUS]

1

EINLEITUNG

Einleitung

2

Wenn es um das Verhalten bei der Führung von Teams geht, verweist selbst Trivialliteratur wie der Zombie Survival Guide von Brooks auf eine einfache Tatsache hin: »Vergewissere dich, welche individuellen Fähigkeiten deine Teammitglieder haben und setze sie dementsprechend ein.« (Brooks 2010, 135) Aber auch in ernst zu nehmenden Werken, welche auf die Zusammenarbeit von Menschen aufbauen, wird auf die Kernidee dieser Masterthesis verwiesen. Im Buch Orientierung mit Karte, Kompass, GPS von Linke, welches sich mit dem elementarsten aller menschlichen Bedürfnisse beschäftigt – dem Überleben – wird auf einen partizipativen Führungsstil verwiesen. Selbst bei solch wichtigen und essentiellen Themen wie Survival wird diese Idee als Best Practice vorgeschlagen. »Wer in einer Wandergruppe die Orientierung übernommen hat, trägt in schwierigem oder unerschlossenem Gelände eine große Verantwortung, die ihn auf dem Weg und bei der Rast nicht loslässt. Das darf aber nicht dazu führen, dass man sich nur auf sich und seine Geräte verlässt, sondern sehr viel spricht dafür, die Mitwanderer an seinen Überlegungen zu beteiligen und auf ihre Einwände zu hören. [...] Die Bereitschaft der Mitwanderer zum Mitdenken muss man pflegen und nutzen. Sich durchsetzen und ,Recht behalten‘ mag zwar befriedigen, aber Recht haben verbessert die Standort- und Kursbestimmung.« (Linke 2011, 57) Natürlich sind weder die Aussagen von Brooks noch von Linke wissenschaftlich belegt und werden daher in dieser Thesis nicht als Literaturverweise geltend gemacht. Dennoch sollte es zum Denken anregen, wenn selbst in Werken bei denen es um Überlebenstechniken geht, ein Common Sense vorherrscht, welcher sich auch bei der Verwendung von Scrum für Games widerspiegelt. Diese Einleitung soll nicht die übliche Vorschau auf die Thesis geben, sondern soll vielmehr dazu genutzt werden, die persönliche Motivation und die subjektiven Gedanken des Autors darzustellen. Der/die LeserIn soll sich dem Thema Scrum für Games und vor allem dem Team als Mittelpunkt der Gameentwicklung mit diesen Grundgedanken annähern. Die Themen Scrum und Team und deren Peripherie sind zwar in den weiteren Kapiteln der Kern dieser Arbeit und werden noch sehr objektiv bearbeitet und hinterfragt, allerdings beschäftigt sich der Autor auch mit den historischen, kulturellen und soziologischen Aspekten der Entwicklung von Management im Bezug auf den jeweiligen Zeitgeist unserer Gesellschaft. Das dadurch gewonnene Verständnis des Autors wird hier subjektiv dargestellt, um dem/der LeserIn einen ganzheitlicheren Ansatz zum Thema zu bieten.

Einleitung

3

Grundsätzlich handelt es sich bei den vorherrschenden Managementmethoden, welche in dieser Thesis beschrieben und hinterfragt werden, um zwei übergeordnete Gruppen. Auf der einen Seite werden Managementmethoden aufgezeigt, welche den/die ManagerIn bzw. die Führung als höher gestellte Personen mit Weisungsbefugnis ansehen. Dieser Führungsstil ist und war schon sehr lange verbreitet. Auf der anderen Seite werden Managementmethoden besprochen, welche den/die ManagerIn bzw. die Führung in einer dienenden Rolle sehen. Zu solchen zählt z.B. auch Scrum. Diese grundsätzliche Trennung zeigt sich in vielen verschiedenen Ebenen: Management, Kultur, Gesellschaft und auch Religion. Sie spiegelt in vielen Ebenen den jeweiligen Zeitgeist wider. Grundsätzlich könnten solche Ansätze in ihrer reduziertesten Form auch mit Monismus und Pluralismus verglichen werden. Der Monismus steht für eine Weltanschauung in der es eine große Wahrheit, bzw. ein großes Ziel gibt. Der Pluralismus hingegen, stellt die Vielfalt der Wahrheiten und Ansichten in den Mittelpunkt. Beide Konzepte haben sich in der Geschichte mehrfach gegenseitig abgelöst, oder existierten oftmals auch gleichzeitig nebeneinander. Monistische Konzepte ließen sich schon immer in der Gesellschaft finden. Man denke z.B. nur an die monotheistischen Ansätze des »einen wahren Gottes« im Christentum oder im Islam, welche konträr zu den zuvor weit verbreiteten polytheistischen Ansichten der Griechen und Römer standen. Dieser Glaubensansatz hinderte jedoch die Philosophen der Antike keinesfalls daran, monistische Ideen zu verfolgen: Thales führte alles auf das Wasser als Urstoff zurück, Heraklit tat das Selbe mit dem Feuer und Pythagoras verwies auf die Zahlen als abstrakte, rationale aber absolute Größe. Gerhard Dorn – ein Schüler Paracelsus´ – schuf das Konzept des »unus mundus« also der »einen Welt«, welche für ihn als die eine wahre Realität galt, aus der alles entstand und in die auch alles wieder zurückkehre. Carl G. Jung griff dieses Konzept auf und benutzte es, um mit Wolfgang Pauli über das psychophysische Problem zu diskutieren. Alle genannten Ansätze basieren auf jeweils einem Grundprinzip, auf einer universellen Wahrheit. In den Zeiten der Industrialisierung mussten vielschichtige Arbeitsprozesse von einer großen Anzahl an ArbeiterInnen innerhalb riesiger Fabriken erledigt werden. Frederick Taylor entwickelte speziell für das Management solcher Werke das Scientific Management. Dieses setzt ebenfalls eine große Wahrheit – ein Urprinzip – voraus: nämlich die Unfehlbarkeit des Managements und seiner Überlegungen. ArbeiterInnen hatten kein Mitspracherecht und wurden mittels Stoppuhr kontrolliert. Sie waren gesichtslose und damit ersetzbare Ressourcen. Der/die ManagerIn war sozusagen die monistische Wahrheit und gab direkte Arbeitsanweisungen an seine/ihre Angestellten. Selbst Managementmethoden aus jetziger Zeit beinhalten oftmals noch eine solche monisitsche Wahrheit. So in etwa reduziert das

Einleitung

4

Management by Objectives ganze Teile von Organisationen auf eine messbare Größe: das jeweilige Objective. Gewisse Absatzzahlen sollen eingehalten oder verbessert werden. Dass sich Leistung nicht unbedingt nur auf eine einzige Zahl reduzieren lässt, wird dabei außer Acht gelassen. Das Management in Zeiten der Industrialisierung entsprach somit dem damaligen Zeitgeist; Es herrschten noch Monarchien vor, die Kirchen hatten zwar bereits an Macht eingebüßt, waren aber immer noch eine zentrale Größe und die ersten Gedanken von Demokratie und der Beteiligung der Masse waren damals erst im Entstehen begriffen bzw. auf dem Weg sich zu verbreiten. Vielleicht war die Managementmethode für die damalige Zeit genau die richtige und eine Beteiligung vieler hätte nicht funktioniert. Allerdings haben sich laut Peter Drucker die Zeiten seitdem stark geändert. Bereits ein drittel der Arbeit wird von WissensarbeiterInnen – wie er die extrem spezialisierten ExpertInnen nennt – erledigt. Der Zeitgeist hat sich gewandelt. Monistische Systeme haben eine Schwächung erfahren. Natürlich sind sie vertreten und werden nie ganz verschwinden, doch viele Theorien der letzten Jahrzehnte weisen auf Pluralismus hin, bzw. fordern diesen sogar. Pluralistische Konzepte sind selbstverständlich keine Idee der neueren Zeit. Selbst Platon beschrieb in seinem Höhlengleichnis gewissermaßen nichts anderes, als dass es keine einheitliche Wahrheit gibt. Selbst wenn die Schatten an der Wand für die angeketteten Menschen als »die eine große Wahrheit« gelten, hat diese nichts mit dem eigentlichen Geschehen draußen vor der Höhle zu tun, die man erfahren könnte, wäre es den Menschen drinnen möglich, die Höhle zu verlassen. Er beschreibt kein pluralistisches System, aber erklärt, dass es »die eine große Wahrheit« nicht gibt. Auch Kant deutet mit seinem Konzept der Inneren und Äußeren Erfahrung auf die Unmöglichkeit einer gemeinsamen allgemeingültigen Realität hin. Jeder nimmt die Welt mit seinen Filtern und Dispositiven wahr und schafft sich dadurch ein eigenes Bild. Niemand könnte »die eine äußere Realität« – falls es sie denn gäbe – erkennen, da wir weder die Mittel zu ihrer Wahrnehmung, noch die gleiche Interpretation hätten. In der Psychologie wird eine ähnliche Idee mit dem Münchhausen-Trilemma beschrieben, welches auf den fünf Tropen des Philosophen Agrippa begründet ist. Dabei wird versucht nachzuweisen, dass es unmöglich ist, eine Aussage wirklich zu begründen. Jeder der Begründungsversuche endet entweder in einem infiniten Regress, muss also immer tiefer erklärt werden, bis es keine Beweise mehr gibt, oder einem Zirkel, bei dem tautologisch eine Aussage mit sich selbst erklärt wird, oder wird mittels eines Dogmas – z.B. Gott – begründet. Diese Ideen laufen im Grunde genommen auf einen Grundsatz hinaus: Es gibt nicht die »eine große Wahrheit«. Dieser Gedanke würde vielleicht eher dem modernen Zeitgeist entsprechen - der Forderung nach Selbstverwirklichung und

Einleitung

5

der Akzeptanz von Andersartigkeit. Mit anderen Worten ist es ein sehr pluralistischer Gedanke. Im Management könnte man diesen Gedanken nun als eine Forderung nach der Beteiligung vieler sehen. Und tatsächlich gibt es weltweit immer mehr Managementsysteme, welche nicht mehr auf das monistische Management setzen, sondern die, von Drucker beschriebenen WissensarbeiterInnen in den Mittelpunkt stellen. Man denke nur an die modernen Prinzipien des Servant Leadership, Lean Management, Diversity Management oder die Agilen Methoden zu denen auch Scrum zählt. Natürlich sind dies nur die sehr subjektiven Gedanken des Autors dieser Thesis und sie sind nicht nachgewiesen oder begründet. Aber genau diese Ideen haben das Interesse an Scrum geweckt und zur Forschungsfrage dieser Arbeit geführt, welche nun zumindest Teile der oben angeführten Theorien beweisen soll:

Einleitung

6

Warum und wie stellt Scrum das Team in den Mittelpunkt der Gameentwicklung? Welche Vorteile ergeben sich aus der Verwendung von Scrum?

2

BEGRIFFSKLÄRUNG

Begriffsklärung

8

2.1 FÜHRUNG Game-Development ist mühseelig. Game-Development ist chaotisch. GameDevelopment wird von »freakigen« Experten oder Expertinnen betrieben. GameDevelopment ist immer ein Projekt. Einem solchen Setting mit normaler Führung beizukommen, ist schwierig. Wenn ein großer Haufen Experten sich zusammen findet, um ein Spiel zu erstellen, braucht es daher spezielle Methoden der Führung und des Managements. Nach dem Ende des Fordismus und der Entstehung des mittlerweile nicht mehr weg zu denkenden Systems der projektorientierten Arbeit, kann man nicht mehr per se davon ausgehen, dass sich spezialisierte MitarbeiterInnen ohne Hilfe und Führung problemlos integrieren, leistungsfähig sind und vor allem zufrieden bleiben. Wie ist einer solchen Entwicklung beizukommen? Die Antwort auf diese Frage ist Scrum. Bei Scrum handelt es sich um eine agile, iterative Projektmanagementmethode, die in den letzten Jahren Einzug in fast alle größeren Game-Studios hatte. Warum gerade Scrum? Welchen Vorteil verschaffen sich die Studios dadurch? Für diese Fragen müssen Begrifflichkeiten geklärt und einige Gedanken vertieft werden. Vor allem der Begriff der Führung muss hier einer Kritik unterzogen werden. »Wahre Führung heißt, Menschen für sich einzunehmen, die definitiv nicht unter ihren offiziellen Machtbereich fallen.« (DeMarco 2001, 140) Wenn Führung bedeutet Menschen für sich einzunehmen, für seine Sache zu gewinnen, wie lässt sich dies innerhalb eines Projekts, dass ja bekanntlich ein Anfang und ein Ende hat, bewerkstelligen? Schlicht und einfach durch Vertrauen. Wenn einer MitarbeiterIn vertraut wird, wird dies durch Einsatz, Energie und wiederum Vertrauen belohnt. Wie lässt sich, ansonsten über jahrelange Zusammenarbeit, geschöpftes Vertrauen innerhalb einer kurzen Zeitspanne von ca. ½ bis 2 Jahren aufbauen? Der Schlüssel hierzu liegt in der Vermittlung von klaren Visionen und dem Streben nach gemeinsamen Zielen.

(Vgl. DeMarco 2001, 137)

Also in einer klar kommunizierten

gemeinsamen Vision eines fertigen Spieles, das mit Freuden von Gamern in aller Welt gespielt wird. Vor allem wird durch die Übergabe von Verantwortung an das Team bzw. die Teammitglieder großes Vertrauen geschaffen. Nur durch das Gefühl selbstbestimmt zu handeln, kann sich Vertrauen gegenüber der ProjektleiterIn aufbauen. Die Umsetzung eines Game-Projekts wird von ExpertInnen durchgeführt. Das bedeutet, dass viele verschiedene, aus den unterschiedlichsten Fachbereichen stammende, SpezialistInnen sich zu einem Team zusammensetzen. Die Fachbereiche reichen von 3D-Animation, Sound-Design und 2D-Grafiken über verschiedenste Arten

Begriffsklärung

9

von Programmierung hin zum Management und Marketing. Es handelt sich in den meisten Fällen um kleinere Teams bis zu 100 Personen. All diese ExpertInnen stammen somit aus den unterschiedlichsten Bereichen und kommen mit den unterschiedlichsten Ansichten über eine Unternehmenskultur in dieses Projekt. Vielleicht sind die vielen Coder gewohnt, in geregelten Arbeitszeiten ihr Soll zu erfüllen, während die 2D-Artists mehr von einer Kunst-Universität kommen und sich in ihrer Kreativität nicht gerne durch feste Arbeitszeiten einschränken lassen. Diese beiden Beispiele sollen nur auf überspitzte Art veranschaulichen, welche Divergenzen sich durch das breite Spektrum von Fachbereichen und den dazugehörigen ExpertInnen innerhalb eines kleinen GameTeams ergeben können. Zusätzlich zu der Problematik der divergierenden Persönlichkeiten und Herkünfte, wird die Führung eines Game-Teams auch durch das System der projektorientierten Entwicklung erschwert. Ein Projekt zeichnet sich durch einen Anfang und ein Ende aus. Also durch eine zeitliche Begrenzung. (Vgl. Patzak/ Rattay 2004, 18ff) Dies bedeutet für die Mitglieder solcher Projekte natürlich, sich immer wieder nach einem Projektende in ein neues Team einzufügen. Vertrautheit kann in einem solchem Setting nur sehr schwer aufgebaut werden. Damit ist Vertrauen von Team-Mitglied zu Team-Mitglied und auch das Vertrauen von Team-Mitglied zu ProjektleiterIn gemeint. Durch beide Problematiken, die divergenten Fachbereiche und das schwer aufzubauende Vertrauen durch kurze Projekintervalle, ergeben sich für die Führung und für das Management solcher Teams mehrere Schwierigkeiten. Man kann weder aus dem projekorientierten Arbeiten, noch aus den divergierenden Teams einfach ausbrechen, da sich beides durch die immer wieder unterschiedlichen Anforderungen eines jeden Games nicht vermeiden lässt. Ein Browser-Game, welches für einen Kunden entwickelt werden soll, erfordert z.B. den Einsatz von Flash und ausschließlich 2D-Art und kann in 5 Monaten mit 6 Leuten umgesetzt werden. Während ein Game für die Xbox360 geübte C++ Coder und sehr gute 3D-Artists benötigt und von 100 Personen in 2 Jahren erschaffen werden kann. Daher können die genannten Probleme fast nicht vermieden werden. ProjektleiterInnen und Teamleader müssen sich also mit dieser Tatsache abfinden und einen anderen Weg einschlagen der es ihnen ermöglicht, in kurzer Zeit ein möglichst großes Vertrauen innerhalb des Teams aufzubauen. »Im Mittelpunkt des Managements steht der Mensch. Die Aufgabe des Managements besteht darin, Menschen in die Lage zu versetzten, gemeinsam Leistung zu erbringen. Es muss ihre Stärken nutzen und ihren Schwächen die Bedeutung nehmen.« (Drucker 2001, 27)

Begriffsklärung

10

Bei Game-Teams handelt es sich in den meisten Fällen um IdealistInnen und sehr Game-affine ExpertInnen. Als Coder für ein Spiel muss man eine gewisse Liebe für das Thema mitbringen, da es für viele der gelernten ProgrammiererInnen im Bereich der Wirtschaft weit besser bezahlte Jobs gibt. Die meisten MitarbeiterInnen in GameFirmen bringen diese gewisse Liebe zu Games bereits aus ihrem Privatleben mit sich. Dies wäre demnach ein guter Punkt, um Gemeinsamkeiten herauszuarbeiten. Man kann davon ausgehen, dass es fast niemanden in einer Game-Firma gibt, der sich nicht im Privatleben mehr oder weniger stark mit Games beschäftigt. Eine gute HR-Abteilung legt viel Wert darauf, sich wirklich nur MitarbeiterInnen an Bord zu holen, die sich für die Materie begeistern können. Diese inhaltliche Verbindung zwischen allen TeamMitgliedern ist zwar nur ein schwacher, aber doch nicht zu unterschätzender, kleinster, gemeinsamer Nenner innerhalb eines Game-Development-Teams. Ausgehend davon muss der Teamleader beginnen, eine gemeinsame Vision des fertigen Games zu etablieren. Je eher dies gelingt, desto schneller können sich innerhalb des Teams andere Gemeinsamkeiten bilden bzw. fundieren. Daher zählt der Etablierung und die Aufrechterhaltung einer Vision zu den wichtigsten Aufgaben der Führung innerhalb eines Game-Teams. (Vgl. Peters 2008, 18ff) Diese Vision ist nicht nur wichtig, um am Ende das gewünschte Game in Händen zu halten, sondern auch eine Gemeinsamkeit zu schaffen, die für das jeweilige Team von hoher Bedeutung ist. Es ist die Gemeinsamkeit an der alle mitarbeiten können und jeder seinen Beitrag leistet. Dies verbindet die, vorher so unterschiedlichen, ExpertInnen zu einem Team. Diese Vision ist der Mörtel im Gebäude des Game-Developments. Um das Team nicht nur mittels inhaltlicher Gemeinsamkeiten zusammen zu schweißen, sollten auch prozessorientierte Strukturen eingeführt werden, welche für alle im Team gültig sind und somit eine Ebene der gemeinsamen Arbeit darstellen. Diese Prozesse sind auf der Ebene des Managements angesiedelt und stellen sich als Rahmenbedingungen des Arbeitablaufs dar. Daher müssen diese Strukturen fächerübergreifend gelten und angewandt werden. Beim Game-Development hat sich in den letzten Jahren weltweit die agile Methode Scrum durchgesetzt. Die meisten GameStudios, ob groß oder klein, verwenden mittlerweile diese Methode. Dazu zählen große Entwickler wie EA, Ubisoft und Microsoft. Aber auch kleine Studios wie Sproing, Travian oder Chimera Entertainment arbeiten mit Scrum. Scrum stellt ein simples Regelwerk für komplexe Projekte bereit. Und dieses System ist fächerübergreifend. D.h. alle MitarbeiterInnen werden in diesen Prozess involviert und kommen sich trotz inhaltlicher Divergenzen (Coder oder Artist) bei den Rahmenhandlungen (Meetings oder Prozesse) näher.

Begriffsklärung

11

Scrum ist eine Methode die grundsätzlich davon ausgeht, dass das Team aus ExpertInnen auf ihren jeweiligen Gebieten besteht. Es fördert nicht nur die Heterogenität des Teams, sondern setzt sie sozusagen bereits voraus. Damit zählt Scrum zum kooperativen Führungsstil, der die Teammitglieder »an den Entscheidungen über Inhalt und Prozess beteiligt. Die Rollenträger sind auf das Zusammenwirken aller angewiesen, um die gesetzten Ziele zu erreichen.« (Patzak/ Rattay 2004, 288) Dieser Führungsstil setzt aber voraus, dass man seinen Teammitgliedern vertraut. Immerhin überlässt man ihnen wichtige Entscheidungen und im Falle von Scrum sogar die Bestimmung der Menge der zu erledigenden Arbeit für den nächsten Zeitintervall, welcher Sprint genannt wird. Dazu muss der Teamleader seinem Team vertrauen können. Man könnte annehmen, dass durch das Entgegenbringen von Vertrauen erst ein Risiko besteht. Nach Sprenger besteht das Risiko eines aufwändigen Projekts aber bereits von vornherein und entsteht nicht erst durch das Vertrauen welches man gibt.

(Vgl. 2007, 59ff)

Dies macht es dem

Teamleader leichter, seinen Teammitgliedern Vertrauen zu schenken, da er/sie ja nur von der positiven Kultur im Team gewinnen kann. »Vertrauen ist sinnvollerweise [sic] immer begrenzt.« (Sprenger 2007, 67) In diesem Fall gibt der Teamleader sein/ihr Vertrauen immer nur für eine gewisse Zeit. Die Begrenzung bei Scrum ist also ein Sprint. (Vgl. Gloger 2010, 11f) Dies ist der iterative Zyklus innerhalb des Scrum-Frameworks, üblicherweise handelt es sich dabei um zwei bis vier Wochen. Innerhalb dieser Zeit macht es für den/ die ProjektleiterIn Sinn, seinen Teammitgliedern voll zu vertrauen. Immerhin sind sie ExpertInnen auf ihren Gebieten. Von vornherein ihren Arbeitswillen anzuzweifeln, wäre eine sinnlose und auch sinnfreie Befürchtung. Am Ende des Sprints gibt es ein Sprint Review Meeting. In diesem Meeting wird das Ergebnis der letzten zwei bis vier Wochen Arbeit vor dem ganzen Team und dem Kunden vorgestellt. Zusätzlich zu diesem Meeting gibt es innerhalb des Sprints ein extrem kurzes (max. 10 min) Meeting, genannt Daily Scrum. Dieses Treffen schafft vollständige Transparenz für alle Teammitglieder, indem jeder kurz berichtet, was er oder sie gestern erledigt hat und was bis morgen zu erledigen ist. Daily Scrum und Sprint Review sind nichts anderes als Kontrollmaßnahmen. Dies bedeutet, dass einerseits Vertrauen gegeben wird, dieses aber durch Kontrollen auch überprüft werden kann. In diesem Kontext muss verstanden werden, »dass nicht jede Kontrolle Vertrauen untergräbt. Kontrolle kann auch Vertrauen sichern.« (Sprenger 2007, 71) Die beiden genannten Kontrollinstanzen werden allerdings vom Scrum-Team nicht als solche aufgefasst. Die passenden Ausdrucke sind an dieser Stelle Transparenz und Ehrlichkeit. Diese entstehen durch den konstanten Austausch von Informationen innerhalb des Teams. Durch die ständige Vermittlung kleiner Arbeitsfortschritte kommt es nie zu Spekulationen, ob die KollegIn vielleicht doch nichts arbeitet und nur kurz vor

Begriffsklärung

12

Abgabe etwas improvisiert. Die Transparenz lässt eine offene und aufgeschlossene TeamKultur entstehen und fördert damit die Zusammenarbeit. Außerdem wird durch die klare, übersichtliche Darstellung der erledigten Aufgaben auch die Steuerbarkeit für den Scrum Master bzw. den Teamleader leichter und somit die Führung und das Managen des Teams erleichtert. Scrum ist also durch seine schnelle und flexible Steuerbarkeit und ein implementiertes Feedback-System für den schnelllebigen Prozess der Game-Entwicklung bestens geeignet. Somit können große Gruppen von divergenten ExpertInnen besser an komplexen Game-Projekten arbeiten.

Begriffsklärung

13

2.2 VERTRAUEN »Die Besten unter ihnen verstehen, dass Führung letztlich Vertrauenssache ist.«

(Peters 2008, 40)

Vertrauen gehört zu den wichtigsten Prinzipien, die in einer Führungs- oder Managementposition gegeben werden können. Aber natürlich wird Vertrauen nicht nur von ManagerIn zu MitarbeiterIn gegeben, sondern auch der/die MitarbeiterIn vertraut ihrem/ihrer ManagerIn und der Organisation. Diese Wechselseitigkeit beim Vertrauen muss immer Aufrecht erhalten werden, denn einmal zerstörtes Vertrauen bedarf langer Arbeit, um wieder hergestellt zu werden. Grundsätzlich muss verstanden werden, dass Vertrauen erst benötigt wird, wenn ein Risiko eingegangen wird. Das bedeutet, dass jedes Projekt grundsätzlich auf Vertrauen basiert, da die potenziellen Gefahren und Risiken am Anfang eines Projekts – und natürlich auch im weiteren Verlauf – weitgehend zunehmen. Aber man muss sich als ManagerIn die Frage stellen, wann und durch wen diese Risiken verursacht werden, bzw. wie sie entstehen. Risiken entstehen nicht durch das Geben von Vertrauen, sie bestehen schon vorher. Zu dem Zeitpunkt an dem ein Projekt angenommen wird, sind die Risiken und Gefahren vorhanden. Sie werden nicht durch die Arbeitsanweisung an den/ die MitarbeiterIn erzeugt. Daher macht es für den/die ManagerIn und die Führung gar keinen Sinn, sein/ihr Vertrauen nicht sofort von Anfang an in seine/ihre MitarbeiterInnen zu setzen, da diese auf alle Fälle gegen die Risiken anarbeiten und versuchen werden, das Produkt fertig zu stellen. Wenn nun von Anfang an Vertrauen in die MitarbeiterInnen gesetzt wird, ändert sich aus der Sichtweise des Risikopotentials gar nichts. Aber aus Sicht der Moral der MitarbeiterInnen stellt sich eine sicherere Arbeitsumgebung ein, wo ohne Angst und Druck gearbeitet werden kann. (Vgl. Sprenger 2007, 59ff) Wenn zum Beispiel am Anfang eines Sprints (ein vollständiger Zyklus des Scrumprozesses, der in der Regel zwei bis drei Wochen andauert) ein Arbeitsauftrag vom Team ausgewählt wird, bringt ein ständiges Nachfragen und Nachkontrollieren des Ergebnisvortschritts seitens des ScrumMasters nichts, da sich das Team auf die Fertigstellung dieser Aufgabe innerhalb der nächsten zwei bis drei Wochen verpflichtet hat. Erst am Ende dieser zwei bis drei Wochen macht es Sinn, die Ergebnisse einzufordern. Falls der ScrumMaster vor diesem gemeinsam abgesprochenen Termin immer wieder nachkontrolliert, glaubt das Team nicht mehr an das Vertrauen in sie. Das bedeutet anders ausgedrückt, der ScrumMaster sei nicht davon überzeugt, dass sie diesen

Begriffsklärung

14

Arbeitsauftrag überhaupt fertigstellen können. Dieses Misstrauen schafft eine negative Stimmung im Team und wird letztendlich dazu führen, dass das Team im Gegenzug das Vertrauen in den ScrumMaster verliert. Peter Drucker beschreibt dies folgendermassen: Manager »[...] haben die Aufgabe, die Stärken der Menschen für Leistungen zu nutzen und den Schwächen der Menschen ihre Bedeutung zu nehmen.« (Drucker 2001, 360) Welchen besseren Weg gibt es, Schwächen ihre Bedeutung zu nehmen, als Vertrauen zu schenken?

Begriffsklärung

15

2.3 INNOVATION »Es gibt Innovationen, die nicht gezielt und systematisch vorangetrieben werden. Gelegentlich wird ein Innovator ‘von der Muse geküsst’ und hat einen ‘Geistesblitz’, anstatt sich die Innovation mühevoll und gezielt erarbeiten zu müssen. Doch derartige Innovationen können unmöglich wiederholt werden. [...] Entgegen dem verbreiteten Glauben an den Zauber der Erfindung und der Innovation sind ‘Geistesblitze’ außergewöhnlich selten.« (Drucker 2001, 318)

Der berühmte Zukunftsanalytiker und Management-Experte Peter Drucker betont, dass erfolgreiche Innovationen in erster Linie von harter Arbeit und sorgfältiger Analyse abhängen. Die einzige Form der Innovation, die vom Management aus gezielt gesteuert und unterstützt werden kann, hängt mit der gezielten Neuerung zusammen. Im Allgemeinen werden die Prinzipien der Innovation von einer Reihe an Geboten und Verboten bestimmt. Eine ausführliche Analyse der Chancen und Stärken ist die Ausgangsbasis für weitere Vorgehensweisen. In diesem Zusammenhang definiert Drucker die Sieben Quellen der Innovationschance: »1. Die unerwarteten Erfolge und Misserfolge der Organisation sowie die

unerwarteten Erfolge und Misserfolge ihrer Konkurrenten 2. Inkongruenzen, insbesonders solche im Produktions- oder Vertriebsprozess, oder Widersprüche im Verhalten der Kunden



3. Prozesserfordernisse



4. Wandel der Branchen- und der Marktstruktur



5. Demographischer Wandel



6. Wandel der Bedeutung und der Wahrnehmung



7. Neues Wissen«



(Drucker 2001, 319)

Ein wesentlicher Aspekt, der zu einer erfolgreichen Innovation beiträgt und die Chancen für Erfolg erhöht, ist die Fähigkeit offen zu sein, aufnahmefähig und bereit, relevante Fragen zu stellen, um heraus zu finden, was Kunden wirklich brauchen. Ebenso ist ein Verständnis für Werte und Gewohnheiten essenziell, damit das Produkt oder der Prozess von der Zielgruppe verstanden und auch richtig aufgenommen wird.

Begriffsklärung

16

Die Grundcharakteristik einer Innovation zeichnet sich durch ihre Einfachheit und Offensichtlichkeit aus. Innovation sollte in Kürze in einem Satz beschrieben werden: »Das ist so nahe liegend. Warum bin ich nicht auf die Idee gekommen?« (Drucker 2001, 320) Eine erfolgreiche Innovation deckt zudem auch immer ein Grundbedürfnis der Zielgruppe. Daher ist es wichtig, dass sie eine gezielte Aufgabe erfüllt und sich konkret mit der Lösung einer relevanten Problemstellung befasst. Laut Drucker fängt jede Innovation klein an, das sowohl von der Idee her, als auch von der Größe des Umsetzungsteams. Nichtsdestotrotz soll als Ziel der Innovation immer die Führungsposition verstanden und angestrebt werden, denn das Wesen einer Innovation strebt immer eine Marktlücke an und versucht, Konsumentenwünsche wie kein anderes, bis jetzt da gewesenes Produkt zu befriedigen. Mit dieser Einstellung sind jedoch auch gewisse Gefahren verbunden: Schafft das innovative Produkt oder der Prozess nicht den gewünschten Erfolg und endet in Mittelmäßigkeit, wird dadurch oftmals der Konkurrenz der Weg für ein erfolgreicheres Unterfangen geebnet. Ausgehend von diesen Erkenntnissen definiert Drucker drei ausschlaggebende Bedingungen für erfolgreiche Innovationen. 1. Innovation ist Arbeit Diese Annahme beruht auf der Tatsache, dass für eine erfolgreiche Innovation ein fundiertes Wissen im entsprechenden Fachbereich Voraussetzung ist. In den meisten Fällen ist ein solches Wissen das Resultat harter Arbeit und konsequenter Vertiefung in ein bestimmtes Subjekt. Nur selten sind Innovatoren vielseitig begabte und interessierte Menschen - in den meisten Fällen handelt es sich um verbissene, hart arbeitende ExpertInnen auf einem Fachgebiet, die sich mit Leib und Seele auf die eine Thematik spezialisiert haben und sich im Laufe der Zeit ein umfangreiches Wissen dazu angeeignet haben. 2. Um sich durchsetzen zu können, muss die InnovatorIn auf ihren Stärken aufbauen Hierbei wird darauf eingegangen, dass das Erkennen von Markt- und Wirtschaftschancen, zwar eine wesentliche Rolle bei der Innovation spielt, das wirklich ausschlaggebende jedoch die Kenntnis über die eigenen Stärken und Leidenschaften ist. Es macht wenig Sinn, eine Marktlücke befüllen zu wollen, die nichts mit dem eigenen Metier zu tun hat, weil in einem solchen Fall sowohl das entsprechende Wissen und die Skills nicht ausreichend vorhanden sind, als auch die Faszination an dieser Arbeit fehlt.

Begriffsklärung

17

3. Eine Innovation hat eine wirtschaftliche und eine gesellschaftliche Wirkung Es ist zu jeder Zeit essenziell, dass eine Innovation die Marktnähe und die Verbindung an die Kunden sucht, da sie grundsätzlich die Eigenschaft besitzt, Verhaltensveränderungen herbei zu führen. Schlägt eine Innovation richtig ein, so verändert sie nicht nur die Verwendungsart eines Produktes, sie greift auch unmittelbar in die Prozesse der Herstellung und des Managements ein. (vgl. Drucker 2001, 323 ff.) Innovative Produkte werden nicht von UNinnovativ geführten Firmen gemacht! In den meisten Fällen wird eine Firma, welche in sich sehr konservativ und starr geführt wird, zwar über lange Zeit ein solides Produkt liefern, innovatives, avantgardistisches Voranschreiten zählt allerdings nicht zu den bekannten Verhaltensmustern dieser Firmen. Also gilt es als Führungskraft nicht nur darauf zu bestehen, innovative Produkte zu erzeugen, sondern auch den Freiraum und die Atmosphäre innerhalb der Firmenund Entwicklungsprozesse zu schaffen, die nötig sind, um kreativ an Ideen zu arbeiten und diese Ideen innovativ (also ökonomisch wertvoll) umzusetzen. Somit zeigt sich, dass einem innovativem Produkt eine innovative Arbeitsumgebung vorausgeht. An welchen Stellen können nun innovative Arbeitsumgebungen ansetzen? Innovationen werden bei einem Projekt in sehr vielen Ebenen angewandt. Prof. Thom nennt hierbei zum Beispiel die Produkt-, Verfahrens- und Sozialinnovation.

(Vgl. Thom

1980)

Damit sind die Projektgrößen relativ gut abgesteckt, welche bedient werden müssen, um ein möglichst innovationsförderndes Umfeld zu erzeugen. Einerseits gibt es das Produkt welches neuartig und am Zahn der Zeit sein sollte, andererseits das Verfahren, also die Umsetzung mit der dieses Produkt erzeugt wird. Dazu zählen Prozesse wie Rahmenbedingen innerhalb des Projekts, oder auch die Projektmanagement-Methode. Und als ein extrem wichtiger Punkt, darf auch der soziale Faktor, also das Zusammenspiel zwischen den Mitarbeitern nicht vernachlässigt werden. In diesen drei Bereichen kann man als Führungspersönlichkeit, bzw. als ManagerIn innovativ vorgehen und andererseits dadurch auch Innovation fördern. Eine spezielle, innovative Methode im Bereich der Verfahrensinnovation ist Scrum. Bei der Game-Entwicklung wird mittlerweile in fast allen größeren Studios mit agilen Projektmanagementmethoden gearbeitet. Dazu zählen z.B. XP (Extremprogramming) und Scrum. Beide Methoden erleichtern auf der einen Seite den extrem komplexen Prozess der Sofwareentwicklung, bieten aber auf der anderen Seite auch sehr viele Möglichkeiten zum kreativen Austausch zwischen den Teammitgliedern. Dieser kreative Austausch führt zu extrem kreativen Innovationen innerhalb des Games, also des Produkts

Begriffsklärung

18

(Produktinnovation). Scrum als solches ist ebenfalls das Ergebnis einer Innovation, bei der sich mehrere SoftwareentwicklungsmanagerInnen entschlossen haben, mit den starren Systemen in ihren Firmen zu brechen und die Managementmethode den realen Begebenheiten anzupassen. Bei Softwareentwicklung muss ständig sehr schnell auf veränderte Bedingungen eingegangen werden. Scrum als iterative Methode, bietet auf der einen Seite konstante Meetingstrukturen (Sprintplanning 1 und 2, Daily Scrum, Retrospective und Sprint Review) und sehr genaue Meetingregeln, lässt aber den zu besprechenden Inhalt vom Team erarbeiten und diskutieren. Das bindet die Teammitglieder viel besser in die Meetings ein, als ein Meeting, bei dem die Führungskraft seinem/ihrem Team ausschließlich Aufgaben zuweist. Außerdem wird durch die Eigeninitiative der Ehrgeiz der Teammitglieder angeregt und sie geben mehr und vor allem besseren Output. Der wichtigste Punkt ist allerdings darin zu sehen, dass die Teammitglieder nicht als reine ArbeiterInnen angesehen werden, sondern durch die Scrum Meetingstrukturen dazu gebracht werden, untereinander zu diskutieren und somit ihre ExpertInnen-Meinungen in den kreativen Prozess einzubauen. Das Ergebnis dieses kreativen Prozesses ist in der Regel ein innovatives Produkt. Dieser Punkt findet auch eine wesentliche Übereinstimmung mit Druckers Ansatz zu dem Prinzip der WissensarbeiterInnen. Die Gesellschaft des 21. Jahrhunderts beruht zum Großteil auf Wissensarbeit, was bedeutet, dass ein/e Angestellte im 3. Sektor ein/e ExpertIn in seinem/ihrem Fachgebiet ist und selber über sein wichtigstes Kapital - das Fachwissen - verfügen muss. Somit treten aber auch starre Managementstrukturen außer Kraft, die darauf aufgebaut wurden, dass eine gelehrte, fachlich omni-kompetente Führungskraft über seine/ihre, im Wissen und Fähigkeiten beschränkten MitarbeiterInnen bestimmt und ohne Absprache die Arbeit vergeben kann. Heutzutage sind WissensarbeiterInnen ExpertenInnen auf ihrem Gebiet und die wichtigste Aufgabe der Führungskraft besteht darin, sie dazu zu motivieren, ihr Wissen, also ihr essenziellstes Kapital, zum Wohl der Firma oder des Projekts zur Verfügung zu stellen. In diesem Sinne spielt Scrum eine tragende Rolle, denn wie kaum bei einer anderen Management Methode werden die WissensarbeiterInnen in den Prozess aktiv eingebunden und es werden ihnen auch wichtige Kompetenzen und Verantwortungsbereiche übertragen, sodass die Motivation aufrecht erhalten wird, sich bewusst mit dem erworbenen Fachwissen für den Prozess oder das Projekt zu engagieren. Innovationen sind ein Faktor, der sowohl sehr erstrebenswert, aber auch risikoreich ist, da er die Schwierigkeit mit sich bringt, den potenziellen Erfolg eines Produktes oder eines Prozesses in der Zukunft zu beschreiben. Dadurch ist ein solcher Innovationsaspekt durch hohe Unsicherheit geprägt und nicht jedes Unternehmen ist bereit, dieses Risiko

Begriffsklärung

19

einzugehen. Doch auch für jene, die durchaus innovationsfördernd agieren, ist es von großem Vorteil, über entsprechende Methoden zu verfügen, die dabei helfen sollen, den Innovationsgrad zu bemessen und vor allem eine Antwort auf die Frage liefern sollen, welche Innovationen sich finanziell auch für das Unternehmen auszahlen und welche hingegen mit größter Wahrscheinlichkeit mehr Kosten als Gewinne verursachen würden. Allgemein gibt es zahlreiche Methoden, die zu einer soliden Innovationsbewertung herangezogen werden können. Eine der, am häufigsten in der Praxis angewandten Herangehensweise, ist die sogenannte Discounted-Cash-Flow-Methode (DCFMethode). »Grundsätzlich liegt die Problematik in der schwierigen Prognose der künftigen Potenziale eines Innovationsvorhabens. Innovationsprojekte sind meist langfristig angelegt, weisen eine hohe Komplexität auf und sind mit großer Unsicherheit und Dynamik behaftet, da die Zielrealisierung bei Innovationsprojekten häufig weit in der Zukunft liegt. Viele Einflussmöglichkeiten müssen berücksichtigt werden. Erschwerend kommen außergewöhnliche Ereignisse, die derzeitige Finanzkrise ist hierfür ein Beispiel, hinzu.«1 Die DCF-Methode ist eine gute Möglichkeit für eine quantitative Bewertung von Innovationsprojekten und wendet das Verfahren der Investitionsrechnung an. Dabei wird in erster Linie ein wertorientierter Ansatz verfolgt, der auf einer kapitaltheoretischen Grundlage basiert. In einer frühen Innovationsphase werden die Einnahmen geschätzt, die durch die betreffende Innovation in Zukunft erwirtschaftet werden könnten. Dies wird auch die »ökonomische Rendite der Innovation« genannt. Das bedeutet, dass sich der Wert einer Innovation im Allgemeinen aus zwei Faktoren zusammen setzt, erstens aus der Summe der Kapitalerträge, die in der Zukunft durch das Produkt erwirtschaftet werden und zweitens aus den bereits angefallenen Ausgaben für die betreffende Innovationsforschung- und entwicklung. Auf Grund dieser Herangehensweise ist es möglich, unterschiedliche Innovationen miteinander zu vergleichen und sie in ihrem Marktwert zu vergleichen. Dennoch sind die Marktzahlen, die bei der DCF-Methode aufgestellt werden, zu einem Teil rein hypothetisch, da die Prognose zukünftiger Kapitaleinträge nie ganz korrekt und verlässlich erstellt werden kann, zumal sie von sehr vielen Einflussfaktoren abhängt. Um eine halbwegs realistische Einschätzung tätigen zu können, sind neben Risikoabschätzungen und Szenarioanalysen auch weitere Faktoren relevant, wie in etwa eine gute Einsicht in die wirtschaftlichen Entwicklungen der globalisierten Weltwirtschaft, oder die Preiseinschätzung über die Entwicklung von Rohstoffen, 1) TWC - Methoden der Innovationsbewertung. In: http://www.tcw.de/news/methoden-der-innovationsbewertung-483

Begriffsklärung

20

Kundenanforderungen, Nachfrageschwankungen, Währungsschwankungen, Technologiewandel, Qualitätsschwierigkeiten bis hin zur Zuverlässigkeit von Lieferanten.2 Abgesehen von der beschriebenen DCF-Methode gibt es noch zahlreiche Herangehensweise zur Innovationsbestimmung, so wie das Ertragswert-Verfahren, das Liquiditionswert-Verfahren oder das Substanzwert-Verfahren. Grundsätzlich ist die DCF-Methode in der Praxis am weitesten verbreitet. Ein weiterer Faktor, der überaus relevant für die Bewertung von Innovationen ist, wird durch den Mehrwert des Produkts oder des Prozesses dargestellt. Wesentliche Module, die hierbei eine tragende Rolle spielen, sind die Innovationshöhe, die Produkt/-Marktsituation, Organisation/ Unternehmensführung / Management und die Finanzplanung. Zusätzlich können bewehrte Methoden in Anspruch genommen werden, so wie die SWOT-Analyse, Beratung durch ExpertInnen mit fundiertem wissenschaftlichen Background, die auch dazu beitragen, dass durch neue Sichtweisen eine Risikominimierung eines »blinden Flecks« innerhalb des Konzepts aufgezeigt wird.3 Die Umsetzung einer Innovation stellt ein kompliziertes Unterfangen dar, bis eine Idee in ein marktreifes Produkt resultiert, zudem ist auch der gewünschte Erfolg schwer zu kalkulieren. Die erwähnten Verfahren bringen ein gutes Hilfsmittel für eine Erfolgsabschätzung mit sich, aber sie werden umso effektiver, wenn sie mit qualitativen Methoden verbunden werden. Trotz der Schwierigkeiten, die eine Messbarkeit von Innovationen mit sich bringt, ist es für Unternehmen unerlässlich, solche Zukunftsprognosen zu erstellen, da dadurch eine zielorientierte Selektion von innovativen Projekten stattfindet und unnötige Misserfolge mindert.

2) Vgl. TWC - Methoden der Innovationsbewertung. ebd. 3) Vgl. inno Nord GmbH. In: www.gtz.info/information/Download/Barthel/

Begriffsklärung

21

2.4 PROJEKT Ein Videospiel zu entwickeln, bedeutet ein Projekt durchzuführen. Der Begriff des Projekts muss an dieser Stelle nochmals definiert und umrissen werden, um zu verstehen, was dies für das Managen und das Entwickeln bedeutet. Die Geschichte des Projekts beginnt bereits mit der Entwicklung der Moderene. In der Zeit der modernen Naturforschung Galileis um 1581 wird als erstes der Begriff des Projektemachers erwähnt. Der Autor Daniel Dafoe schrieb in seinem Essay upon Projects über den Projektemacher als einen Entwickler und Ideenschmied, der allerdings alles für die Umsetzung seiner Idee vorausplant, aber eben diese Umsetzung jemand anderem überlässt. (Vgl. Nausner 2006, 24) »Der Begriff ‚Projekt’ leitet sich aus dem lateinischen ‚partizipium projectus’ (hingeworfen, entworfen) ab und bezeichnet ein Vorhaben mit entsprechendem Plan dazu – also ein Konzept das mehr ist als eine Idee.« (Nausner 2006, 24) Erst ein fertiggestelltes Projekt, welches sich auch vermarkten lässt, bzw. nach einer zuvor getroffenen Definition erfolgreich war, wird zur Innovation. »Durch das Gelingen wird ein Projekt zum Produkt und zur Innovation. Begreift man Innovation als Produkt spezifischer Wertschöpfungsprozesse, dann ist das Projektemachen zwischen Erfinden und Vermarkten anzusiedeln – man würde es heute als Entwickeln bezeichnen.« (Nausner 2006, 25) »Das moderne Projektmanagement entsteht in den 1940er Jahren im Wettrennen um kriegsentscheidende Innovationen, da sich angesichts der hochkomplexen, komplizierten und zeitkritischen Aufgabenstellungen herkömmliche Organisationsformen als unbrauchbar erweisen. Im Rahmen der Raumfahrtindustrie werden schließlich erste Rahmenregelwerke für die effiziente Abwicklung von Projekten entworfen. Ausgehend von der erfolgreichen Nutzung durch amerikanische Industrieunternehmen gelangt die Projektmanagementphilosophie auch nach Europa.« (Nausner 2006, 38) Mit dem derzeitig immer noch laufendem Niedergang des Fordismus, also der extrem standardisierten Form von Produktion, stellt sich in den Neuen Medien und damit auch in der Videospiele-Industrie, immer mehr das Projekt als etablierte Form der Produktentwicklung in den Vordergrund. »Projekte mit ihrer temporären Organisationsform werden als spezifische Problemlösung für die Gestaltung von Innovationsprozessen verstanden.« (Nausner 2006, 69)

Begriffsklärung

22

Nach Patzak und Rattay ist ein Projekt folgendermaßen definiert: »Projekte sind Vorhaben, die im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet sind. Die daraus resultierende mangelhafte Erfahrung schlägt sich als Unbestimmtheit bzw. Unsicherheit nieder.« (Patzak/ Rattay 2004, 18ff) Außerdem sind Projekte durch einen Anfang und ein Ende gekennzeichnet. Aus diesen Definitionen lassen sich viele Erkenntnisse ableiten. Innovationsprozesse, also das Ausarbeiten und Vermarkten von Ideen, bedürfen immer wieder aufs neue eine frische, unverbrauchte Herangehensweise an das jeweilige Produkt. Dies bedeutet, dass neue Modelle der Entwicklung bzw. der Umsetzung quasi mit dem Produkt erfunden werden müssen. Es gibt wenige geregelte Bahnen an die man sich als EntwicklerIn einer Innovation halten könnte. Allerdings kann man diese, immer wieder aufs Neue entstehenden Herausforderungen eines Projekts umarmen, akzeptieren und mit ihnen Arbeiten. Vor allem der temporäre Charakter von Projekten bereitet dem Management bzw. der Führung immense Probleme; Für jedes Projekt werden je nach Anforderung, welche auf den jeweiligen Ideen basiert, die umgesetzt werden sollen, MitarbeiterInnen neu als Projektteam zusammengestellt. Das bedeutet im Fall eines Gameprojekts, dass man für ein Jahr als GrafikerIn in einem Team für die Entwicklung eines Browsergames arbeitet und dort mit FlashprogrammiererInnen zusammenarbeiten musste, während man als Folgeprojekt für ein innovatives Wii-Game Grafiken gestalten muss und dabei mit völlig anderen ExpertInnen (z.B. C++ - ProgrammiererInnen) zusammenarbeitet. Dies ist nur ein Beispiel von vielen. Je nach Idee und passender Innovation muss man als Führungskraft neue Teams zusammenstellen, um die neue Aufgabe, also das neue Projekt zu bewältigen. Dies bedeutet für die Teams immer wieder einen neuen Teambildungsprozess zu durchlaufen. Tuckmann erklärt diesen Prozess mit seinem Fünf-Phasen-Modell. Demnach durchläuft das Team folgende Phasen:

1.

Forming (Orientierungsphase)



2.

Storming (Konfrontationsphase)



3.

Norming (Kooperationsphase)



4.

Performing (Wachstumsphase bzw. Produktionsphase)



5.

Adjourning (Auflösungsphase) (Vgl. Mai 2011)

Begriffsklärung

23

Die einzelnen Phasen des Phasen-Modells werden von Hight und Novak sehr gut in kurzen Worten erklärt:

»Forming / uncertainty about the group’s purpose and structure



Storming / intragroup conflict



Norming / close relationships and cohesiveness, accepted behaviors and goals



Performing / fully functional, high task performance



Adjourning / focus on disbanding (temporary groups)« (Hight / Novak 2008, 198)

In der Forming Phase wird ein Team zusammengeführt. Innerhalb des Teams herrscht noch Unklarheit über ihre Aufgaben und über die Rollenverteilungen. Umgangssprachlich würde sich die Beschreibung – die Hackordnung ist noch nicht festgelegt – am besten eignen. In der Storming Phase entstehen vielerlei Konflikte und werden auch ausgefochten. Diverse Konzepte von Hierarchien innerhalb der Gruppe und Arbeitsweisen hinsichtlich der Aufgaben prallen aufeinander und die Mitglieder des Teams müssen diese Konflikte ausleben. In der Norming Phase müssen diese Konflikte geklärt werden. Die Hierarchien innerhalb des Teams verfestigen sich und kommen zu einem Punkt, an dem sie größtmöglichen bestand haben. Die Performing Phase sollte nun frei von grösseren Konflikten sein und es dem Team ermöglichen, zügig und konzentriert an die eigentliche Arbeit zu gehen. In dieser Phase wird die eigentliche Leistung erbracht. Als Adjourning Phase wird das Zerfallen des Teams und die nachträgliche Organisation des Projekts angesehen. Hierbei lösen sich Teamverbände wieder auf und das Projekt sollte mit einem Post-Mortem nachbesprochen werden, um einen möglichst großen Lernerfolg für das Team und alle anderen beteiligten Parteien zu erzielen. Dabei ist es wichtig zu verstehen, dass diese Phasen bei jedem neu gebildeten Team immer wieder durchlaufen werden müssen. Das bedeutet, dass die Storming- und Normingphase, also die Zeit in der Konflikte innerhalb des Teams ausgelebt und geklärt werden, bei jedem neuen Team immer erst durchlaufen und ausgefochten werden müssen, um zu einem funktionierenden Team zusammen zu wachsen. Dies ist eine eher unproduktivere Phase und stellt das Management immer wieder vor das Problem eines nur auf Sparflamme funktionierenden Teams. Kaum ist das Team dann in der Performingphase, geht die Entwicklung besser voran, solange das Team durch gute Führung durch die Klippen der Storming- und Normingphase geführt worden ist.

Begriffsklärung

24

2.5 EXPERTENTUM Der/die ExpertIn, ist ein Ausdruck für eine Person, welche Wissen zu einem Fachgebiet angesammelt hat und dieses Wissen auch einsetzen kann. Es gibt verschiedene Modelle, um den Aufbau von Expertentum zu umschreiben. Dabei werden Stufenmodelle von Glaser oder Schumacher und Czerwinski beschrieben. Diese erklären den Weg zum Erlangen von Expertentum. Doch die wichtigen Erkenntnisse und das Verständnis der besonderen Rolle des Expertentums in Scrum, wird erst die Idee des/der WissensarbeiterIn von Peter Drucker erschließen. Glaser umschreibt in seinem Aufsatz Changing the agency for learning. Acquiring expert performance den Weg vom Laien zum Experten in drei Stufen: 1. External Support Durch verschiedene didaktische Methoden innerhalb einer Lernumgebung helfen TrainerInnen, LehrerInnen oder auch die Eltern dem Laien. 2. Transitional Stage In dieser Übergangsphase bedarf es nahezu keiner Hilfe mehr von außen. Das Expertentum formuliert und baut sich auf. 3. Self-Regulatory Stage Der/die angehende ExpertIn ist auf keine äußere Hilfe mehr angewiesen und kann nun selbstständig das Lernen organisieren. (Vgl. Glaser 1996, o.A.) Schumacher und Czerwinski umschreiben in ihrem Aufsatz Mental models and the acquisition of expert knowledge ebenfalls unterschiedliche Stufen, die Ähnlichkeit mit dem oben angeführten Modell aufweisen: »Vortheoretische Stufe Beim ersten Kontakt mit einem neuen Stoffgebiet versucht man, anhand eigener oberflächlicher Arbeitsmethodik und der vordergründigen Eigenschaften des Themas, im Gedächtnis Vergleichbares zu finden, um die neuen Informationen sinnvoll einordnen zu können.

Begriffsklärung

25

Empirische Stufe Bei der Auseinandersetzung mit dem neuen Stoff wird versucht, durch Analogiebildung, Induktion, Abstraktion usw. ein erstes Verständnis für tiefere strukturelle Eigenschaften und Kausalzusammenhänge zu gewinnen. Expertenstufe Abstraktionen über mehrere Fachgebiete hinweg werden möglich und erlauben dadurch den Lerntransfer des neuen Wissens.« (Vgl. Schumacher/ Czerwinski 1992, o.A.) Beide Modelle umschreiben das Erreichen des Expertentums auf offensichtliche Art und Weise. Der Weg vom Laien, also dem/der Unwissenden zum/zur ExpertIn wird im besten Fall von Außen, durch eine positive Lernumgebung und bekannten Methoden zur Vermittlung von Wissen unterstützt. Danach setzt Eigeninteresse ein und es werden Zusammenhänge und Analogien durch den/die heranwachsende ExpertIn eingesetzt, um ein tieferes Verständnis für sein/ihr Fachgebiet zu erlangen. Am Schluss wird ohne weitere Hilfe von Außen ein fundiertes Wissen eingesetzt, um Zusammenhänge zu verstehen und eigene Lösungen zu finden; Das ExpertInnenwissen wird entsteht. Schumacher und Czerwinski umschreiben in ihrer Expertenstufe mit der »Abstraktion über mehrere Fachgebiete hinweg« einen sehr wichtigen Punkt, den auch Drucker bei der Umschreibung der gebildeten Person verwendet. »Wir brauchen keine Universalgebildeten, die in vielen Wissensgebieten zu Hause sind, und werden sie auch nicht bekommen. Vielmehr wird die Spezialisierung wahrscheinlich weiter fortschreiten. Doch wir brauchen die Fähigkeit die verschiedenen Wissensbereiche zu verstehen. Und dieses Verständnis wird die gebildete Person in der Wissensgesellschaft auszeichnen. Worum geht es in den einzelnen Wissensgebieten? Was sind ihre Ziele? Welches sind ihre zentralen Theorien? Welche wichtigen Erkenntnisse haben sie zuletzt hervorgebracht? Wo weisen sie Lücken auf, wo liegen ihre Probleme und Herausforderungen?« (Drucker 2001, 341) Damit umschreibt Drucker sein Verständnis der gebildeten Person und weist somit darauf hin, dass es in der Wissensgesellschaft, in der wir heute leben, immer wichtiger sein wird, eine gebildete Person zu sein. Diese muss einerseits ein/e ExpertIn auf dem eigenen Fachgebiet sein und muss auf der anderen Seite ein fundiertes Verständnis der Fachdisziplinen der KollegenInnen besitzen, um die Zusammenarbeit in einer Organisation zu ermöglichen. Drucker beschreibt mit der Wissensgesellschaft ein Modell in dem ein Großteil der Arbeit durch WissensarbeiterInnen für Organisationen erledigt

Begriffsklärung

26

wird. WissensarbeiterInnen arbeiten in Organisationen zusammen, oder arbeiten einer Organisation zu. Dabei wird die Spezialisierung im zunehmenden Maße immer wichtiger und die Feingliedrigkeit der Spezialisierungen immer größer. Frühere Fachgebiete sind heute zu grob eingeteilt und werden oftmals in noch detailliertere Unterdisziplinen aufgebrochen. Für all diese Disziplinen gibt es wiederum WissensarbeiterInnen, welche mit den anderen WissensarbeiterInnen zusammen an größeren Produkten für die Organisation arbeiten. (Vgl. Drucker 2001, 334ff) Dieses Modell bildet den derzeitigen Stand der Game Produktion sehr genau ab. Heutige Game-Produktionen werden in Studios erledigt, die viele verschiedene ExpertInnen unterschiedlichster Disziplinen zusammenführen, um zusammen ein Game (Produkt) zu erzeugen. Es arbeiten technisch orientierte Coder mit künstlerisch arbeitenden

DesignerInnen

und

KomponistInnen

zusammen.

Freidenkende

GameDesignerInnen müssen Hand in Hand mit strategisch planenden Controllern an einem Strang ziehen. Dabei wird die Wichtigkeit des Expertentums in der GameProduktion klar. Aber auf der anderen Seite werden auch die Gefahren und die Risiken offensichtlich. Ohne ein gutes Management würden die Projekte scheitern. Eine Tatsache, die immer wieder bei den Zusammenbrüchen von Game-Studios klar zu sehen ist. Es ist nicht einfach, in einem solchen Studio eine Führungskraft oder ein/e ManagerIn zu sein. »Der Intellektuelle betrachtet die Organisation als Werkzeug, das es ihm ermöglicht, sein spezifisches Fachwissen einzusetzen. Der Manager betrachtet das Wissen als Werkzeug im Dienst der Organisationsleistung. Beide haben Recht. Sie stehen einander gegenüber, doch sie sind eher einander ergänzende Pole als unvereinbare Gegensätze. Und sie sind aufeinander angewiesen: Der Forscher braucht den Manager ebenso wie der Manager den Forscher. Hat einer von beiden ein Übergewicht, so beeinträchtigt dies die Leistung beider und führt zu allgemeiner Frustration. Ohne das Gegengewicht des Managers macht in der Welt des Intellektuellen jeder, was er will, ohne dass irgendetwas erreicht wird. Ohne das Gegengewicht des Intellektuellen verwandelt sich die Welt des Managers in eine lähmende Bürokratie. Besteht jedoch ein Gleichgewicht zwischen ihnen, so wird die Kreativität mit der Ordnung und die Erfüllung der Aufgaben mit einer Mission vereinbart.« (Drucker 2001, 339) Dieser Zusammenhang scheint eindeutig und klar, führt aber zu einer neuen Problematik, der man sich als ScrumMaster oder Führungskraft innerhalb eines GameStudios unbedingt bewusst sein muss: Die Teammitglieder sind WissensarbeiterInnen und das Wissen in ihrem Spezialgebiet übersteigt das Wissen der Führungskraft. Die MitarbeiterInnen sind auf ihrem Spezialgebiet gebildeter als die Führung. Das

Begriffsklärung

27

bedeutet, dass das geradlinige System der Befehlskette von Führung, Management und WissensarbeiterIn nicht mehr funktioniert. Entscheidungen die von der Führung getroffen wurden und für welche das Management einen Plan zur Umsetzung entwickelt hat, können sehr schnell sinnlos oder zumindest umständlich werden, wenn sie von den fachkundigen WissensarbeiterInnen begutachtet werden. Wie kann es sich ein/e ManagerIn herausnehmen, Arbeitsaufträge und Systeme für die Umsetzung komplexer Fachthemen vor zu geben und zu entwerfen, wenn es doch Aufgabe des, extra dafür engagierten, Expertentums ist, die beste Umsetzung zu gewährleisten? Gucher und Kana umschreiben diese Problematik folgendermaßen: »Die Notwendigkeit zur hochgradigen Spezialisierung in den Gesellschaften führt in Unternehmen letztendlich dazu, dass hochgradig spezialisierte ExpertInnen die Arbeits- und Produktionsprozesse umzusetzen haben. Da es sich um Wissensarbeit handelt, die Inhalte und Arbeitesergebnisse also durch Denkleistungen erbracht werden, müssen WissensarbeiterInnen wesentlich mehr Information im Produktionsprozess erhalten als bisher nötig war, um produzieren zu können. Im Prinzip hat sich dadurch eine neue, 2. Führungsebene etabliert, an der alles, was strategisch festgelegt wurde, nochmals durchbesprochen werden muss. Diese Verschiebung hat fundamentale Bedeutung und gravierende Auswirkungen auf zukünftige Produktionsprozesse. Denn der erste Schritt im Prozess, in dem die 1. Führungsebene die Strategien und Ausrichtungen an das Management kommuniziert, ist faktisch nutzlos geworden, wenn an späterer Stelle dieselben Fragen (bei zumeist unzureichender Kenntnis der Sachlage) nochmals besprochen werden müssen.« (Gucher/ Kana 2006, 33) Welche Lösung gibt es nun für dieses Dilemma? Eine Alternative, zumindest bei der Produktion von Games, ist Scrum. Es definiert die WissensarbeiterInnen als Team und stellt sie in den Mittelpunkt der Game-Produktion. Auf der anderen Seite gibt es dem Management in Form des ScrumMasters eine dienende Rolle. Der ScrumMaster ist hauptsächlich dafür verantwortlich, dem Team die Arbeitsumgebung und die Mittel zur Verfügung zu stellen, die es benötigt, um das Game zu produzieren. Die WissensarbeiterInnen oder auch ExperteInnen, bieten also ihr Fachwissen und ihre Kompetenz an und erhalten im Gegenzug den Raum und die Zeit, aus diesem Werkzeug für die Organisation und damit auch für sich selbst, Kapital zu gewinnen.

Begriffsklärung

28

2.6 DIVERSITÄT Grundsätzlich ist die Thematik der Diversität, also der Vielfalt des Unterschieds einfach zu erklären. Stuber beschreibt in der Einleitung seines Buches Diversity. Das Potenzial von Vielfalt nutzen - den Erfolg durch Offenheit steigern. die Grundidee der Thematik mit folgenden einfachen Worten: »Diversity im Sinne von Vielfalt beschreibt eine unverrückbare Realität. Nämlich, dass jeder Mensch in gewisser Hinsicht vielen, wenigen und/oder keinem Menschen gleicht.« (Stuber 2004, 16) Aus dieser Realität ergeben sich aber sehr viele Herausforderungen für das Management der modernen WissensarbeiterInnen. Wie bereits beschrieben wurde, divergieren Menschen in Projekten und den damit entstehenden Teams schon durch die Zusammenstellung ihrer Spezialisierungen. In einer Organisation müssen viele verschiedene WissensarbeiterInnen zusammenarbeiten, um ein Produkt für die Organisation produzieren zu können. Aber diese inhaltliche Vielfalt ist nur der Anfang dieser Überlegung. Nicht nur die Spezialisierungen haben zu einer Vielfalt bei den WissensarbeiterInnen geführt, sondern auch die Globalisierung der Welt. Menschen setzen (unter anderem eben auf Grund ihrer Spezialisierungen) ihren Lebensmittelpunkt in anderen Städten, Ländern oder sogar Kontinenten fest. Sie haben andere Interessen, Leben ihre Sexualität anders aus, sind extrovertiert und gehen auf andere zu, oder ziehen sich lieber zurück und fühlen sich in »social situations« unwohl. Jeder Mensch ist anders. Mor Barak beschreibt dies im Buch Managing Diversity folgendermaßen: »Workforce diverstity is not a transient phenomenon; it is today’s reality, and it is here to stay. Homogeneous societies have become heterogeneous, and this trend is irreversible.« (Mor Barak 2011, 2) Der Trend des Diversity Managements steht hier nur am Anfang der folgenden Überlegungen. Trotzdem stellt sich die Grundidee des Diversity Managements folgendermaßen dar: Diversity Management » [...] bezieht sich explizit auf die Wahrnehmung von MitarbeiterInnen als Individuen und enthält die eindeutige Feststellung, dass in Unternehmen und Organisationen nicht homogenisiert werden darf.«

(Gucher/ Kana

2006, 78)

Entwickelt hat sich diese Idee leider nicht aus einer humanen Überlegung heraus, sie liegt in dem amerikanischen Recht zur Gleichbehandlung zugrunde. Amerikanische MitarbeiterInnen können ihre Organisationen wegen Diskriminierung verklagen. Dies führte zu einer Gegenbewegung in den Firmen, die versuchten, durch gewisse Managementmethoden diesen Klagen zu entgehen und Herr der Lage zu werden.

Begriffsklärung

29

Die betroffenen Minderheiten sind in Amerika gesetzlich definiert und werden im Diversity Management als »grounds« bezeichnet. (Vgl. Gucher/ Kana 2006, 11f) »Diese grounds sind:

1)

Gender (soziales Geschlecht)



2)

Behinderung



3)

Ethnische Herkunft



4)

Religion



5)

Sexuelle Orientierung



6)

Alter« (Gucher/ Kana 2006, 11)

Unter diesen Voraussetzungen entwickelte sich der, durchaus als positiv zu betrachtende, Trend des Diversity Managements, also dem Umgang mit Vielfalt oder Andersartigkeit. Stuber beschreibt diesen Umgang folgendermaßen: »Wer mit Vielfältigkeit nicht umzugehen weiß, wird schon bald zu den Verlierern oder zumindest nicht zu den besten gehören können. Ähnlich waren die Überlegungen, die in den USA Mitte der 1980er Jahre zu ‘Managing Diversity’ geführt hatten. Ein Managementansatz, dessen Kern die positive Berücksichtigung von Unterschieden zwischen Menschen darstellt. Dies umfasst ein

- Bewusstes (An-)Erkennen von Unterschieden,



- Umfassendes Wertschätzen von Individualität,



- proaktives (Aus-)Nutzen der Potenziale von Unterschiedlichkeit,



- gezieltes Fördern von Vielfalt und Offenheit.« (Stuber 2004, 5)

Der Gedanke der Diversität spiegelt sich auch in den unzähligen Methoden zur Erstellung von Persönlichkeits-Profilen wider. Es gibt diverse Persönlichkeitsmodelle die für die Typisierung der MitarbeiterInnen geschaffen wurden. Sie sollen dem Management helfen, besser auf ihre Angestellten einzugehen. Beispiele für diese Modelle wären:

INTERPLACE



3 Doshas



Erbbiologische Auffassung

LIFO



Managerial GRID



DISC



Biostrukturanalyse



INSIGHTS MDI



ALPHA PLUS



Human Synergetics



Enneagramm



DISG (Vgl. Schimmel-Schloo 2002, 13ff)



TMS

Begriffsklärung

30

Das DISG Modell, welches auf der Arbeit und Forschung von William Moulton Marston beruht, wird hier kurz zur Veranschaulichung näher erläutert: »Das DISG Persönlichkeitsprofil basiert auf einem Modell, das Verhalten in konkreten Situationen beschreibt. Dadurch, dass Verhaltensweisen definiert werden, hilft das Modell dem Unternehmen und dem Einzelnen, Verhalten zu verstehen und eine spürbar bessere Kommunikation aufzubauen. Wer sich und andere Menschen versteht, kann Konflikte entpersonalisieren und sachlich behandeln.« (Gay 2004, 14) Marston ist dabei auf vier verschiedene Verhaltensdimensionen gestoßen: »Dominanz Menschen mit einer ausgeprägt dominanten Verhaltensdimension sehen die Herausforderungen, die es zu überwinden gilt, wobei sie sich für stärker halten, als diese Herausforderungen. Sie versuchen Dinge zu ändern oder zu steuern. Initiative Menschen mit einer ausgeprägt initiativen Verhaltensdimension versuchen andere zu beeinflussen, weil sie das Gefühl haben, in einer günstigen Umwelt stark zu sein. Stetigkeit Menschen mit einer ausgeprägt stetigen Verhaltensdimension wollen ein günstiges Umfeld bewahren, weil sie sich als weniger stark als ihre Umwelt wahrnehmen und daher große Veränderungen scheuen. Gewissenhaftigkeit Menschen mit einer ausgeprägt gewissenhaften Verhaltensdimension nehmen sich selbst als weniger stark in einer ungünstigen Umwelt wahr. Deshalb versuchen sie, die Dinge sorgfältig zu analysieren und arbeiten daran, hohe Standards zu erreichen.« (Gay 2004, 18) Diese Verhaltensdimensionen können mit Fragenbogen, welche von Geier auf den Theorien von Marston aufbauend, erstellt wurden, der Führungskraft oder dem/ der MitarbeiterIn zugeordnet werden. Anhand dieser Fragebögen und den, daraus resultierenden Verhaltensdimensionen kann auf eine Situation oder auf einen Missstand im Team eingegangen werden. Leider haben diese Modelle auch viele Nachteile, da sie streckenweise verallgemeinen oder Eigenschaften als negativ einordnen. Außerdem ist der Begriff »Persönlichkeitstypologie« mehr mit der Psychologie verbunden. Diese Einteilungen

Begriffsklärung

31

werden streckenweise als Pathologien gesehen und haben in einer Managementmethode nichts zu suchen. Auf solche Probleme sollte geschultes Personal, also PsychologInnen oder TherapeutInnen eingehen, aber nicht die Führung oder das Management der MitarbeiterInnen. Allerdings können Verhaltenstypologien aus manchen der Persönlichkeitsmodelle abgeleitet werden, die durchaus einem/einer ManagerIn helfen können, besser auf seine/ihre MitarbeiterInnen einzugehen. Speziell ausgebildete Coaches können durch manche Modelle durchaus helfen, gewisse Situationen in einer Gruppe zu verbessern. In einer Gesellschaft, in welcher WissensarbeiterInnen den Großteil der arbeitenden Bevölkerung stellen und es wichtig ist, auf Individuen einzugehen, würde dies durchaus hilfreich sein. In Wirklichkeit gehen die Ideen des Diversity Managements und der Persönlichkeitsmodelle aber noch viel weiter und wenn diese Gedanken ausgeweitet, bzw. genauer durchleuchtet werden, stellt sich heraus, dass es um Homogenität und Heterogenität von Gruppen innerhalb der Organisationen geht. (Vgl. Gucher/ Kana 2006, 47) Die Industrialisierung und der Fordismus standen unter dem Zeichen von homogenen Gruppen. FabrikarbeiterInnen wurden in Managementmethoden wie dem »Scientific Management« als austauschbare Betriebsmittel betrachtet und damit homogenisiert. Diese Methoden sind immer noch in unserer Kultur tief verankert. Drucker schreibt über den Wandel der Gesellschaft von IndustriearbeiterInnen zu WissensarbeiterInnen und die Relevanz, solche Gedanken fallen zu lassen und die Individualitäten und Stärken der einzelnen WissensarbeiterInnen herauszuarbeiten. (Vgl. Drucker 2005, 339ff) Auch Gucher und Kana klären nochmals die Herkunft der Homogenisierung auf und beschäftigen sich mit der Frage, warum sie sich bis zum heutigen Tage halten konnte: »Die Homogenisierungsstrategie ist eine Strategie, die 200 Jahre lang politisch-kulturell prägend für die Industrialisierung war. Sie ist mittlerweile so tief verwurzelt im Prozess der Zivilisation, dass ohne Bewusstmachen dieser Strategie eine Veränderung nicht möglich ist. Wir alle sind sozialisiert nach der Homogenisierungsstrategie, wenn auch in unterschiedlichen Formen und Graduierungen, dennoch finden wir selten die Frage: Wie kann ich meine Stärken entfalten und leistungsbezogen einsetzen? Die häufig gestellte Frage hingegen ist: Wie kann ich unter diesen und jenen Bedingen durchkommen?« (Gucher/ Kana 2006, 83) Sollten hochbezahlte WissensarbeiterInnen sich mit der zweiten Frage belasten, oder sollte der Gedanke der Homogenisierung fallen gelassen werden und das moderne Management sich anderen Wegen öffnen? Bereits unter den bisher genannten Gesichtspunkten erscheint dies sinnvoll. Auf diesen Aspekt wird in späteren Kapiteln

Begriffsklärung

32

dieser Arbeit noch genauer eingegangen. »Es gibt nicht den oder die Menschen. Das zu akzeptieren ist nach meiner Beobachtung für die meisten ManagerInnen bemerkenswert schwierig, obwohl es auf der Hand liegt. Immer wieder wird generalisiert, was nicht generalisierbar ist, und zusammengefasst, was nicht zusammengehört.« (Malik 2005, 249) Unsere Gesellschaft hat sich durch Globalisierung und Expertentum zu einer sehr heterogenen Gruppe entwickelt. Solche Gruppen finden sich nun natürlich auch in den Organisationen wieder. Anstatt die Methode der Homogenisierung, welche zu ihrer Zeit vielleicht sogar die richtige war, in eine Gesellschaft zu ziehen, die sich geändert hat und mittlerweile andersartig funktioniert, sollte es die Aufgabe des modernen Managements sein, sich mit den Heterogenitäten auseinanderzusetzen und diese sogar zu ihrem Vorteil zu nutzen. Die derzeitige Gesellschaft und die, ihr Inne wohnenden, Organisationen verlangen nach ManagerInnen und Führungskräften, welche Heterogenitäten zum Vorteil nutzen können und nicht gegen sie arbeiten. »Das Konzept der WissensarbeiterInnen legt den Fokus auf die produzierenden Menschen, sodass Management nicht umhinkommt, sich mit einzelnen Individuen auseinanderzusetzen und letztendlich Heterogenitäten managen zu müssen. Dem Management von Heterogenitäten stehen allerdings [...] massive kulturelle Barrieren entgegen. Von Managementseite wird daher allzu oft homogenisiert, wo Unterschiede gemanagt werden müssten, um produktive Bedingungen mit und für WissensarbeiterInnen herbeizuführen.« (Gucher/ Kana 2006, 11) Scrum bietet ein Framework, welches den ManagerInnen dabei helfen kann, mit Heterogenitäten umzugehen.

3

SCRUM | DER PROZESS

Scrum | Der Prozess

34

3.1 AGILE METHODEN Um die vorletzte Jahrhundertwende wurde von Frederick Taylor eine ManagementMethode entwickelt, bei der es um die strikte Zuweisung von Aufgaben und die genaue Kontrolle der Einhaltung derselben ging. Diese Methode fand unter dem Namen »Scientific Management« oder »Taylorismus« Einzug in die Produktionshallen vieler Firmen. Dabei wurden folgende Vorgehensweisen eingeführt:

»Detaillierte Vorgabe der Arbeitsmethode ‘one best way’, exakte Fixierung des Leistungsortes und des Leistungszeitpunktes, extrem detaillierte und zerlegte Arbeitsaufgaben, Einwegkommunikation mit festgelegten und engen Inhalten, detaillierte Zielvorgaben bei - für den Einzelnen nicht erkennbarem Zusammenhang zum Unternehmungsziel sowie externe (Qualitäts-)Kontrolle.«4

Zusammengefasst bedeutet dies, dass MitarbeiterInnen in keiner Weise Einfluss auf die Entstehung eines Produkts nehmen konnten, sondern ausschließlich das Management entschied wie, was in welcher Zeit zu erledigen sei. Dies bedeutet, dass MitarbeiterInnen im extremen Maß auf eine ausführende Funktion reduziert wurden. Damit wurde jedoch das Sozialkapital der ArbeiterInnen in keinster Weise genutzt. Taylor drückt dies in seinem Buch Die Grundsätze wissenschaftlicher Betriebsführung folgendermaßen aus: »Bisher stand die 'Persönlichkeit' an erster Stelle, in Zukunft wird die Organisation und das System an erste Stelle treten« (Taylor 1913, o.A.) Über hundert Jahre später muss man nun einsehen, dass dieses Modell nicht wirklich praktikabel war. Mehr noch, es ließ, auf Grund seiner Unmenschlichkeit, sehr viel Kritik aufkommen. Allerdings wurde dieses System, mit Unterbrechungen, bis in die 60er Jahre des letzten Jahrhunderts verwendet (in manchen Ländern dieser Welt selbst bis zum heutigen Tage). Die Hoffnungen durch starre, fest vorgeschriebene Systeme die Effizienz bei der Produkterstellung zu steigern, gingen nicht auf. Außerdem wurden MitarbeiterInnen und somit Sozialkapital verschwendet und ausgebeutet. Durch ein solches System wurde das Potenzial hunderter ArbeiterInnen nicht in die Produktion mit einbezogen, was einen immensen Verlust an Expertenwissen darstellt. Daher muss der Niedergang des Taylorismus im Management und der Wandel vom Fordismus zum projektbezogenen Arbeiten klar als eine positive Wandlung angesehen werden.

4) Taylorismus. In: http://de.wikipedia.org/wiki/Taylorismus

Scrum | Der Prozess

35

Selbst im neuen Feld der Softwareentwicklung in den 80er Jahren des letzten Jahrhunderts wurde noch mit sehr starren Systemen gearbeitet. Diese Relikte des Taylorismus mussten jedoch entgültig für die Softwarentwicklung als nicht praktikabel eingestuft werden. (Vgl. Gloger 2009,16f)

Ein gutes Beispiel hierfür ist die Wasserfallmethode. Diese Methode wurde in den frühen Phasen der Softwareentwicklung von Royce konzipiert und stellt sich folgendermaßen dar: »Implementation steps to develop a large computer program for delivery to a customer

System Requirements



Software Requirements



Analysis



Program Design



Coding



Testing



Operations«5

»Es ist ein lineares Vorgehensmodell in der Softwareentwicklung, bei dem der Softwareentwicklungsprozess in einzelnen, festen Phasen organisiert wird. Dabei gelten die Phasenergebnisse immer als bindende Vorgaben für die nächste Phase. Jede Phase muss komplett abgeschlossen sein, damit die nächste beginnen kann. Dazu produziert jede Phase als Ergebnis ein ausführliches Dokument oder Programm.«6 Das Wasserfallmodell zwingt die EntwicklerInnen des Produkts also am Anfang des Entwicklungsprozesses die komplette Vorgehensweise festzulegen. Dabei muss alles in Designdokumenten, wie dem Lasten- und Pflichtenheft, festgehalten werden. Außerdem ist hierbei auch nicht die Möglichkeit des Irrtums vorgesehen. Irrtümer können nur nach Beendigung einer Phase erkannt und durch die Wiederholung der jeweiligen Phase korrigiert werden. In dieser Methodik können Phasen allerdings mehrere Monate in Anspruch nehmen. Es ist sehr leicht zu erkennen, dass ein solch starres System bei einer komplexen Aufgabe wie Softwareentwicklung zu Problemen führt. Die

agilen

Methoden

können

als

Gegenbewegung

zu

den

starren

Entwicklungsprozessen wie der Wasserfallmethode verstanden werden. Am 17. Februar 2001 versammelten sich diverse Softwareentwickler, darunter Beck, Schwaber, Sutherland und Fowler, und fassten ihre Ideen einer agilen Softwareentwicklung in einem Manifest zusammen. 5) Managing the Development of large Softwaresystems. In: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf 6) Wasserfall-Modell. In: http://www.scrum-kompakt.de/grundlagen-des-projektmanagements/wasserfall-modell/

Scrum | Der Prozess

36

»Manifest für Agile Softwareentwicklung Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge



Funktionierende Software mehr als umfassende Dokumentation



Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung



Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein. Prinzipien hinter dem agilen Manifest:

- Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche



Auslieferung wertvoller Software zufrieden zu stellen.



- Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen.



Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.



-Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder



Monate und bevorzuge dabei die kürzere Zeitspanne.



- Fachexperten und Entwickler müssen während des Projektes



täglich zusammenarbeiten.



- Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die



Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.



- Die effizienteste und effektivste Methode, Informationen an und innerhalb eines



Entwicklungsteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.



- Funktionierende Software ist das wichtigste Fortschrittsmaß.



- Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und



Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.



- Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.



- Einfachheit - die Kunst, die Menge nicht getaner Arbeit zu maximieren -



ist essenziell.

Scrum | Der Prozess

37



- Die besten Architekturen, Anforderungen und Entwürfe entstehen durch



selbstorganisierte Teams.



- In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und



passt sein Verhalten entsprechend an.«7

Wie sich leicht aus den zwölf Prinzipien des agilen Manifests erkennen lässt, zielen agile Methoden auf Nachhaltigkeit und einen menschlichen Umgang mit den MitarbeiterInnen hin. Natürlich ist dies auch in solchen Methoden nicht als reiner Selbstzweck zu betrachten. Es liegt auch den agilen Methoden weiterhin ein wirtschaftlicher Aspekt zugrunde. Nur wird dieser hier langfristiger angedacht und versucht durch Qualität und Funktion zu überzeugen. Dabei werden die Mitarbeiter und deren Expertenwissen als eines der höchsten Güter, welche dem Projekt oder der Organisation zugrunde liegen angesehen. Dies wird durch diverse Prinzipien des Manifests dargestellt. Selbstorganisierte Teams finden als beste EntwicklerInnen von Architekturen, Anforderungen und Entwürfen Erwähnung und stellen somit die MitarbeiterInnen als wichtige Quelle von Qualität dar. Agile Prozesse werden auch als nachhaltige Entwicklung bezeichnet. Dies beruht auf dem selbstbestimmten und damit, im besten Falle, gleichmäßigen Tempo der EntwicklerInnen. Natürlich kann kurzfristig durch Überstunden oder intensive »Crunch-Times« ein höherer Output erzielt werden. Es ist allerdings fraglich, wie lange man es sich als Organisation leisten kann, eingelernte und gut zusammenarbeitende ExpertInnen durch ein solches Verhalten zu »verheizen«. Fast alle wichtigen Aussagen und Aspekte die auf das Team als zentrales Element der Entwicklung hindeuten, sind in folgendem agilen Prinzip zusammengefasst: »Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.«8 Dabei wird auf motivierte MitarbeiterInnen hingewiesen, was auch bedeutet, dass man als ProjektleiterIn ebensolche suchen sollte, aber auch darauf, dass man die MitarbeiterInnen durchaus motiviert halten soll. Durchgehend Überstunden zu machen und abzuarbeitende Aufgaben unter Druck zugewiesen zu bekommen – vielleicht sogar von einem/einer Vorgesetzten, welche/r auf dem Gebiet weniger Wissen hat als der/die ExpertIn selbst – motiviert niemanden, bzw. demotiviert sogar den/die engagierteste/n MitarbeiterIn. Außerdem wird im erwähnten agilen Prinzip auch auf die nötige Unterstützung und auf ein passendes Umfeld hingewiesen. Dies sind quasi die Baupläne für die Motivation von MitarbeiterInnen und somit auch zu langfristig qualitativen Produkten. 7) Manifest für agile Softwareentwicklung. In: http://www.agilemanifesto.org/iso/de/ 8) Manifest für agile Softwareentwicklung. ebd.

Scrum | Der Prozess

38

Der letzte und trotzdem sehr wichtige Aspekt, ist der Hinweis auf das Vertrauen. Nichts kann eine/n MitarbeiterIn schneller und radikaler demotivieren, als der Mangel an Vertrauen durch seine/ihre Vorgesetzten. Dabei stellt sich für ihn/sie auch immer die Frage, warum er/sie überhaupt eingestellt wurde. Warum sollte man eine/n MitarbeiterIn einstellen und ihm/ihr dann nicht vertrauen? An dieser Stelle wird wiederum die Wichtigkeit einer überlegten und durchdachten Human Resources Politik hervorgehoben und betont. Zusammengefasst sind die agilen Methoden also eine Gegenbewegung zu veralteten und starren Systemen. Sie zielen darauf ab, menschlich und nachhaltig Produkte zu entwickeln und stellen zu diesem Zweck den/die MitarbeiterIn in den Vordergrund. Aus dem agilen Manifest und den daraus folgenden Überlegungen haben sich diverse agile Methoden herausgebildet. Dazu zählen Crystal Clear, Extreme Programming (XP), Agiles Datawarehousing (ADW), Adaptive Software Development, Dynamic Systems Development Method (DSDM), Feature Driven Development (FDD) und Scrum. Weitere Beschreibungen und Herangehensweisen in der vorliegenden Arbeit werden sich meistens auf die agile Methode Scrum beziehen.

Scrum | Der Prozess

39

3.2 HERKUNFT Die Geschichte von Scrum ist stark mit denen des Agilen Manifests verbunden, ist aber trotzdem älter als das Manifest selbst. Vom ersten Scrum-Team bis zum Verfassen des agilen Manifests sollten damals fast zehn Jahre vergehen. »1990 hatte Jeff Sutherland in einem Projekt für die Guinness Peat Aviation herausgefunden, dass Gantt Charts für sie nicht funktionierten. Er schaffte diese Form der Projektkontrolle ab und schuf eine neue Rolle für die damaligen Projektleiter. Er machte sie zu Teammitgliedern und gab ihnen eine eher moderierende als managende Rolle. Das erste Scrum-Team entsteht, als Sutherland Jeff McKenna und John Scumniotales als erste ScrumMaster engagiert. 1994 wird das erste Release des Easel Object Studios nach sechs Sprints und das zweite Release nach weiteren sechs Sprints geliefert.« (Gloger 2009, 17) Scrum wurde in seiner Begrifflichkeit an einen Mannschaftssport angelegt. »Der Begriff Scrum stammt aus dem Rugby und wird auf Deutsch als ‘Gedränge’ übersetzt. Vereinfacht lässt der Spielzug folgendermaßen beschreiben: Jeweils acht Spieler der beiden Mannschaften formen das Gedränge. Beide Spielergruppen stehen sich eng umschlungen und nach vorne gebeugt gegenüber. Die vordersten drei Spieler verkeilen Kopf und Schultern. Alle Spieler drücken nun nach vorne. Ein Spieler außerhalb des Gedränges, der sog. Gedrängehalb der ballführenden Mannschaft, wirft den Ball seitlich in das Gedränge. Seine Mitspieler im Gedränge müssen den Ball mit den Füßen nach hinten schieben. Erst wenn der Ball das Gedränge verlassen hat, darf er wieder aufgenommen und ein Angriff eingeleitet werden. Das Gedränge ist komplizierter Spielzug, der sorgsam einstudiert und orchestriert werden muss. Er verlangt eine disziplinierte Teamarbeit.« (Pichler 2008, 2) Das agile Manifest kann somit als Zusammenfassung vieler einzelner Ideen von diversen Teams und Individuen weltweit angesehen werden. Dies zeigt, dass das, im Kleinen praktizierte, Zusammenarbeiten von motivierten ExpertInnen auch damals im weltweiten Kontext funktionierte. Die agilen Prozesse sind somit eine Gemeinschaftsidee und wurden nicht durch einen Vorgesetzten mehreren MitarbeiterInnen aufgezwungen. Sie sind Managementmethoden von WissensarbeiterInnen für WissensarbeiterInnen. In Japan entstanden bereits in den 80er Jahren die ersten Ideen für ein einfacheres und sinnvolleres Management. Unter dem Begriff »Lean Management« wurden einfache – also schlanke – Prozesse bei Toyota eingeführt.

Scrum | Der Prozess

40

»Beeinflusst wurde Scrum von Anfang an von neuen, innovativen Wegen in der Produktentwicklung, wie sie insbesondere von japanischen Unternehmen pilotiert wurden [Takeuchi&Nonaka 1986]. Diese neue Form des Managements und der Produktentwicklung wird heute als ‘schlank’ (lean) bezeichnet [Womack&Jones 1996]. Besonders Toyota hat bei der Entwicklung schlanker Entwicklungsprozesse eine führende Rolle eingenommen [Liker 2003].« (Pichler 2008, 3) Schwaber, Sutherland und Beedle waren 2001 Mitverfasser des Agilen Manifests und begründen damit den Begriff »agile Methoden«. Die Grundzüge von Scrum wurden noch 2001 im Buch Agile Software Development mit Scrum von ihnen zusammengefasst. 2003 wurden erste ScrumMaster-Trainings von Schwaber durchgeführt. Er zeichnete sich allgemein für die Weiterentwicklung von Scrum als federführend aus. Eine Organisation mit dem Namen Scrum Alliance entstand im Jahr 2004. Jährlich werden dort sogenannte Scrum Gatherings, also Treffen von Mitgliedern der Scrum Alliance und Interessierten abgehalten. Derzeit bietet die Scrum Alliance diverse Zertifizierungen an. All diese Ideen zeigen deutlich, dass vorhandene Methoden nicht mehr ausreichend waren, um den damaligen und heutigen Bedingungen der Produktentwicklung standzuhalten. Daher kamen agile Methoden wie Scrum ins Spiel, die dem Zeitgeist mehr entsprachen und dabei auch noch auf Dauer bessere Ergebnisse erzielten. »Jetzt (Mitte 2009) gibt es nach sechs Jahren Scrum-Training bereits ca. 60 000 Certified ScrumMaster. Scrum ist kein Geheimtipp mehr, sondern schon fast State of the Art.« (Gloger 2009, 17)

Scrum | Der Prozess

41

3.3 ANWENDUNGSBEREICHE Scrum ist grundsätzlich als eine Softwareentwicklungsmethode konzipiert worden. Diese Spezifizierung hat sich bis zum heutigen Zeitpunkt nicht geändert. »Scrum lässt sich auf alle Arten der Softwareentwicklung anwenden: Software als unternehmensinterne Lösung oder Software, die im Auftrag eines Kunden entwickelt wird; Software, die neu entwickelt, und Software, die gewartet wird.« (Pichler 2008, 1) Allerdings haben sich mittlerweile durch den Einzug der neuen Medien wie Games und der Integrierung des Internets in nahezu alle Lebensbereiche der Begriff Software seine Grenzen erweitert. Unter Software versteht man nun nicht mehr ausschließlich komplexe Programme für Banken und Firmen, viel mehr hat der Begriff auch Einzug in diverse Lebensbereiche erhalten. Webseiten werden einerseits von Codern entwickelt, aber benötigen auch den Input von GrafikerInnen, um am internationalen Markt konkurrenzfähig zu sein. Die Game-Industrie hatte 1998 Market Sales von ca. 20 Millionen Dollar pro Jahr, weltweit und konnte diese bis zum Jahr 2009 auf nahezu 50 Millionen Dollar pro Jahr steigern. »This represents a steady growth of about 10% a year. Few markets can boast such consistent and steady growth.« (Keith 2010, 8) In Amerika hatte die Movie-Industrie 1996 einen Revenue von 5,6 Millionen Dollar und konnte diesen bis 2009 auf ca. 10 Millionen steigern.9 Weltweit wurde die Movie-Industrie bereits zwischen 2005 und 2007 von der Game-Industrie um ein gutes Stück überholt.10 »The U.S. video game industry boomed in the early 2000s and became one of the leading forms of entertainment in terms of total revenue. Presently, the industry is at around $22 billion for 2008 (conservative estimate) in the US and $30 to $40 billion globally. Here is how it compares with other entertainment industries.

Music industry - $10.4 billion (US 2008) and $30 to $40 billion globally.



Movie industry - $9.5 billion



Book industry - $35.69 billion (US 2007) and roughly $63 billion globally

(US) and $27 billion globally.



(2002) (Euromonitor Intl)



(US) (buying $16B, renting $7B)

DVD industry - $23 billion

9) Vgl. US Movie Market Summary. In: http://www.the-numbers.com/market/ 10) Vgl. Comparison with other forms of entertainment. In: http://vgsales.wikia.com/wiki/Video_game_industry

Scrum | Der Prozess

42

It surpassed the U.S. movie and music industry in 2005 and 2007 respectively. In the 2008, the UK industry blew past the music industry and is expected top DVD sales in the near future.«11 Eine Industrie dieser Größe muss sich mit dem Thema der Entwicklungsmethoden auseinandersetzen. Daher wurden und werden auch in der Game-Industrie sinnvolle Methoden zur Produktentwicklung gesucht. Früher konnten Games von einem/einer einzelnen ProgrammiererIn in kurzer Zeit erstellt werden. Mittlerweile benötigt man ein großes Team aus diversen SpezialistInnen in den verschiedensten Disziplinen. Dabei werden Games grundsätzlich als Software angesehen, da alle Funktionen innerhalb eines Codes geschrieben werden. Allerdings arbeiten hier viel mehr verschiedene Fachbereiche zusammen, als es bei reiner Softwareentwicklung der Fall ist. ProgrammiererInnen sind nur noch ein Bestandteil des Teams. Es sind auch noch 3D-Artists, GrafikerInnen, SounddesignerInnen, Game-DesignerInnen und viele andere Gruppen an der Entwicklung eines solch umfangreichen Produktes beteiligt. Dies macht es umso komplexer, ein Game zu entwickeln und bedarf daher ebenfalls einer team-orientierten Projektmanagementmethode. Um 1980 herum benötigte man zur Erstellung eines Games maximal 1 bis 2 Personen-Jahre. Um 2005 steigerte sich die durchschnittliche Entwicklung auf bereits 120 Personen-Jahre. (Vgl. Keith 2010, 9) Diese Games können natürlich nur noch in sehr großen Teams (durchaus zwischen 100 und 200 Personen pro Titel) umgesetzt werden. In Game-Teams arbeiten so viele verschiedene Disziplinen zusammen, dass es nahezu essentiell ist, diesen divergierenden Expertenteams eine Unterstützung in Form eines ScrumMasters zur Verfügung zu stellen. Von der Bankensoftware, zur Webseite, bis hin zum Spiel handelt es sich im Kern immer um Softwareentwicklung. Daher erscheint es nur logisch, funktionierende Entwicklungssysteme wie Scrum bei diesen Projekten einzusetzen. Bekannte Firmen die Scrum für die Entwicklung ihrer Software einsetzen12:

Adobe Systems

IBM

Quantum Leap



Bank of America

LinkedIn

SAP



BenQ

Logitech

Siemens



Bose

Microsoft

SUN



British Telecom

Motorola

Unisys



Google

Nokia

Xerox



HP

Philips

Yahoo



FH Salzburg IS

11) Comparison with other forms of entertainment. ebd. 12) Vgl. Firms Using Scrum. In: https://docs.google.com/spreadsheet/ccc?key=0AgfBeuoRfUzNdDlMNG82SlhmUVRhOEk0REtrdmth NWc#gid=0

Scrum | Der Prozess

43

Auch die größten Firmen in der Game-Industrie, EA und Ubisoft verwenden bereits in vielen ihrer Studios Scrum. So in etwa, arbeitet EA Phenomic bereits mit mehreren Scrumteams. Aber auch viele kleine Studios haben diese Methode bereits in ihren Arbeitsalltag eingeführt. Unter die bekannteren von ihnen im deutschsprachigen Raum fallen Chimera Entertainment oder Travian in München. In den folgenden Kapiteln wird hauptsächlich auf die Anwendung von Scrum bei der Gameentwicklung eingegangen. Da dort die divergierenden Teams mit WissensarbeiterInnen aus den unterschiedlichsten Disziplinen zu betreuen sind, bedarf es eines guten Verständnisses dieser Methode.

Scrum | Der Prozess

44

3.4 PROZESS »Scrum [skrʌm] ist ein agiles Projektmanagementframework zur Entwicklung von Software, das aus wenigen klaren Regeln besteht. Diese beinhalten die Anwendung der drei Rollen Product Owner, Team und ScrumMaster, die Verwendung eines priorisierten Product Backlog sowie das Erstellen von Produktinkrementen innerhalb kurzer Arbeitszyklen, die Sprints genannt werden.« (Pichler 2008, 1)

3.4.1 Rollen Scrum hat eine klar definierte Rollenverteilung. Diese hilft allen Beteiligten klare Verantwortungen innerhalb des Scrumprozesses zu definieren und einzuhalten. Dabei ist es immens wichtig zu verstehen, dass eine Rolle keine Position darstellt. Boris Gloger stellt sich in seinem Buch Scrum. Produkte zuverlässig und schnell entwickeln. die Fragen: »Wer sollte in einer Organisation der ScrumMaster sein? Wo finden wir die vielen ScrumMaster, wenn jedes Team einen eigenen Master benötigt?« (Gloger 2009, 63) Die Antwort liegt in der Tatsache begründet, dass bei Managementprozessen in den agilen Methoden vielmehr die Rolle für eine Verantwortlichkeit steht, als für eine Postion. »Rollen sind Container für Verantwortlichkeiten. Das war die Antwort. Die obigen Fragen waren zwar im Kontext einer Organisation sinnvoll und mussten beantwortet werden. Aber sie gehen von der falschen Annahme aus, der ScrumMaster sei eine Position innerhalb einer Organisation. Wenn wir aufhören, den ScrumMaster, den Product Owner und die Teammitglieder als ein Position innerhalb einer Organisation zu sehen (sei es innerhalb einer Abteilung oder eines Projektes), lassen sich die obigen Fragen sehr einfach beantworten. Wenn der ScrumMaster nur ein Container für Verantwortlichkeiten ist, kann in reiner Organisation jeder diese Verantwortung übernehmen. Jeder Teamleiter, der beginnt, diese Position zu gestalten, ist sofort ein ScrumMaster. Jeder Entwickler, der anfängt, Scrum-Ideen umzusetzen, ist ein ScrumMaster. Jeder, der inhaltlich zu einem Produkt beiträgt, ist ein Teammitglied. Und jeder, der die Verantwortung für ein Produkt übernimmt, ist ein Product Owner.« (Gloger 2009, 63) Nur durch eine solch klare Trennung können Schuldzuweisungen vermieden werden. Selbst bei kleinen Projekten ist es somit möglich, mit Scrum zu arbeiten und die Vorteile dieser Methode für die Entwicklung zu nutzen.

Scrum | Der Prozess

45

Der traditionelle Scrumprozess sieht folgende Rollen vor: Das Team, den ScrumMaster und den Product Owner. Boris Gloger erweitert dieses Rollenbild noch um den Customer, den End User und den Manager.

3.4.1.1Team Das Team spielt bei Scrum eine sehr große Rolle und wird als Kern des Prozesses verstanden. Es bekommt ein ungleich größeres Mitspracherecht, bzw. fast absolute Entscheidungsfreiheit, als bei anderen Managementprozessen, muss aber dafür auch ungleich mehr Verantwortung und Eigeninitiative einbringen. Grundsätzlich gilt: »Das Team erarbeitet mit den Anforderern – Kunden und Anwendern – die Product Backlog Items und somit die Anforderungen, analysiert sie, entwickelt das Design, implementiert und testet die Anforderungen und liefert das Produkt wie vereinbart aus.« (Gloger 2009, 65) »Das Team führt alle Arbeiten aus, die zur Umsetzung der Anforderungen in auslieferbare Produktinkremente notwendig sind.« (Pichler 2008, 13) »Das Team eines Scrum-Projekts entwickelt die Software und ist für den Erfolg jedes einzelnen Sprints verantwortlich. Das Team muss alles dafür tun, das im Sprint Planning Meeting vereinbarte Sprint-Ziel zu erreichen. Am Ende eines Sprints steht funktionierende Software, die vom Team geliefert wird. Das Team hat die volle Autorität, alle erforderlichen Maßnahmen zu ergreifen, die fürs Erreichen dieses Zieles notwendig sind. Diese Autorität zu besitzen, geht weit über das hinaus, was Teams aus traditionell gemanagten Projekten kennen.« (Wirdemann 2009, 37f) »Das Team verpflichtet sich feiwillig auf die Sprint-Ziele und nimmt so viel in einen Sprint auf, wie es bearbeiten kann.«

(Gloger 2009, 65)

Somit übernimmt das Team die Rolle der

ausführenden ExpertInnen. Ihre Expertise ist der entscheidende Punkt der es sinnvoll macht, dem Team selbst so einen großen Entscheidungspielraum zu geben. Durch ihr jeweils spezielles Wissen sind die Teammitglieder in Belangen der Produktentwicklung ihren Vorgesetzten, bzw. den anderen Rollen bei Scrum überlegen. Genau diese Expertise macht man sich der Scrumprozess zu nutze, um das Beste aus dem Produkt raus zu holen.

Scrum | Der Prozess

46

3.4.1.2 ScrumMaster Die Rolle des ScrumMasters wird am besten durch eine Analogie beschrieben: ein Hirtenhund. Seine Aufgabe ist es, das Team vor äußeren Einflüssen zu schützen und in es zu einer Einheit bzw. einer echten Gemeinschaft zu bringen. »Er schützt das Team vor äußeren Störungen und er versucht Blockaden, die das Team am produktiven Arbeiten hindern, sofort aus dem Weg zu räumen. Der ScrumMaster ist der 'beste Freund des Teams'.« (Gloger 2009, 86)

Die wichtigste Aufgabe des ScrumMasters ist es also, das Team als ExpertInnen arbeiten zu lassen. Auch Wirdemann bestätigt Glogers Ansichten zu den Hauptfunktionen. »Er hat zwei Hauptverantwortlichkeiten: Erstens muss er dafür sorgen, dass Scrum funktioniert und die zugrunde liegenden Regeln und Prinzipien eingehalten werden. Und zweitens muss er für optimale Arbeitsbedingungen für das Team sorgen.« (Gloger 2009, 39) Der Hirtenhund ist eine sehr gute Analogie, da sie sich auch auf das Produkt anwenden lässt. Der ScrumMaster ist ausschließlich für das Team und den Prozess verantwortlich. Er kann nicht für ein nicht funktionierendes Produkt verantwortlich gemacht werden. »However he is not responsible for the delivery of the product.« (Gloger 2010, 13) Das bedeutet im Umkehrschluss, dass die Verantwortlichkeit für das Produkt immer beim Team liegt.

3.4.1.3 Product Owner Die dritte wichtige Rolle innerhalb des traditionellen Scrumprozesses ist der Product Owner. Seine Aufgabe ist es, für das Produkt verantwortlich zu sein. Der ScrumMaster ist, wie bereits beschrieben, ausschließlich für das Team und den Prozess, also die ScrumAbläufe als solches verantwortlich. Dabei darf der ScrumMaster nicht in die Inhalte und die Qualität des Produkts eingreifen. Natürlich ist in einem solch agilen System wie Scrum seine Meinung bei den entsprechenden Meetings gefragt und gewünscht. Allerdings übernimmt der Product Owner die Verantwortung für das Produkt und nicht der ScrumMaster. »Der ScrumMaster und Product Owner sind zwei grundsätzlich verschiedene Rollen mit unterschiedlichen Verantwortungsbereichen. Der ScrumMaster ist für den Prozess und der Product Owner für das Ergebnis zuständig. Beide Rollen arbeiten zusammen, müssen sich

Scrum | Der Prozess

47

aber auch aneinander reiben und können aus diesem Grund nicht von ein und derselben Person repräsentiert werden.« (Wirdemann 2009, 43) Diese Verantwortung für das Produkt zeigt sich in mehreren Ebenen. Vor allem ist der Product Owner der Flaschenhals für alle Stakeholder, allen voran natürlich dem Customer selbst. Das bedeutet, dass alle inhaltlichen Anforderungen an das Produkt ausschließlich an den Product Owner gerichtet werden können. Der Customer kann nicht das Team selbst kontaktieren und ihm neue Ideen mitteilen oder Aufträge erteilen. Solche Anforderungen werden ausschließlich dem Product Owner mitgeteilt und zusammen mit ihm wird auch das Backlog, also die Sammlung an Anforderungen priorisiert und ständig auf dem Laufenden gehalten. Durch dieses Vorgehen kann sich das Team komplett auf seine Aufgaben als ProgrammierInnen, Artists, etc. konzentrieren, während die Aufgaben, welche das Team zu bearbeiten hat, von Product Owner und Customer inhaltlich kontrolliert und in eine sinnvolle Reihenfolge gebracht werden. Der Product Owner »bündelt die Interessen aller anderen Stakeholder. Das Team hat einen direkten Ansprechpartner, wenn es um Anforderungen geht, und das ist der Product Owner. Sein Wort zählt, und seine Entscheidungen werden akzeptiert.« (Wirdemann 2009, 43) Boris Gloger fasst die Rolle des Product Owners folgendermaßen zusammen: »Der Product Owner treibt das Projekt aus Sicht des Business voran. Er kommuniziert eine klare Vision des Produktes, legt die Eigenschaften des Produktes fest, gibt am Ende des Sprints seine Kommentare zu den Ergebnissen des Sprints ab und bewertet, ob das Team geliefert hat, was es versprach, oder nicht. Der Product Owner ist dafür verantwortlich, dass das Team immer an den für die Organisation wertvollsten Aspekten des Produktes arbeitet. Durch das kontinuierliche Priorisieren des Product Backlogs steigert er die Profitabilität des Projektes. Der Product Owner ist nicht Teil des eigentlichen Entwicklungsteams, sondern bildet gemeinsam mit dem Entwicklungsteam das übergreifende Scrum-Produkt-Entwicklungsteam. Er verfolgt die gleichen Ziele und ist ihnen genauso verpflichtet (‚committet’) wie das Entwicklungsteam. Der Product Owner geht nie ohne Product Backlog in ein Sprint Planning und setzt sich während eines Sprints für das Team ein.« (Gloger 2009, 76)

Scrum | Der Prozess

48

3.4.1.4 Customer Die Rolle des Customers ist einfach erklärt: »Der Customer (Kunde) ist der Auftraggeber. Er bezahlt die Produktentwicklung. Er ist es, der das Produkt am Ende des Projektes haben möchte, um seine internen oder externen Anwender zufrieden zu stellen.« (Gloger 2009, 99) Trotz dieser eigentlich selbstverständlichen Definition ist es wichtig, die Rolle des Kunden klar zu definieren. Wiederrum handelt es sich um eine Rolle und nicht um eine Position oder Person. Das bedeutet, dass entweder eine Person oder auch ein Steering Commitee die Rolle übernehmen kann. Der Customer kann also auch eine Gruppe von Stakeholdern sein. »Der Product Owner repräsentiert die Stakeholder des Projektes.« (Wirdemann 2009, 45)

Im traditionellen Scrum konnte der Product Owner auch der Customer sein. Es ist aber für den Scrumprozess von Vorteil, wenn die Rolle des Product Owners von der des Customers getrennt wird. Der Product Owner ist für den ROI (Return on Investment) verantwortlich, also den Profit. Der Customer zahlt das Produkt und gibt dem Product Owner seine Anforderungen an das Selbe weiter. Der Customer »wünscht eine neue Anwendung, die seine Probleme in einem bestimmten Bereich lösen, und wir wollen sein Geld, um das Projekt durchführen zu können.« (Gloger 2009, 100)

3.4.1.5 End User »Der User benutzt das Produkt: Er wendet es an. Er ist nicht immer auch der Kunde. D.h. er bezahlt die Produktentwicklung nicht. Der User ist als Rolle zuständig dafür, die Anforderungen zu kennen oder sie bewerten zu können.« (Gloger 2009, 101) Der End User darf nicht mir dem Customer bzw. dem Kunden verwechselt werden. Teilweise kann es sich um ein und die selbe Personengruppe handeln. Allerdings ist das im Bereich der Gameentwicklung meistens nicht der Fall. Der Customer ist der Finanzier bzw. Geldgeber und der End User ist die Rolle der AnwenderIn. Um ein konkretes Beispiel zu nennen, könnte in der Gameindustrie der Publizier als Finanzier dienen und ein Studio mit der Entwicklung eines Games beauftragen, während der End User in diesem Fall mit Sicherheit bei den AnwenderInnen dieses Games also den Gamern zu finden ist.

Scrum | Der Prozess

49

Dabei ist es wichtig zu verstehen, dass der End User andere Anforderungen an das Produkt hat, als der Customer. Der Customer will ein Produkt entwickeln lassen mit dem er am Ende in der Regel Geld verdient, oder ein anderes höheres Ziel verfolgt. Den End User betrifft dieser Aspekt nicht. Er will das Produkt nutzen und stellt daher eher Anforderungen an Funktionalität, bzw. Verwendbarkeit oder - im Gamebereich - natürlich auch Design. Es ist daher wichtig für das ganze Scrum-Gefüge, das heißt, alle sonst vorhandenen Rollen, auch auf den Input des End Users zu hören. Aus diesem Grund wird er in regelmäßigen Abständen in das Sprint Planung 1 und die Sprint Review Meetings eingeladen und nach seiner Meinung gefragt. »Der User trägt also keine Verantwortung in dem Sinne, wie es die übrigen Rollen tun. Aber das Team muss den User immer im Blick behalten. Es erzeugt das Produkt weder für den Product Owner noch für den Customer. Sie erschaffen das Produkt einzig für den User. Wer seinen User bei der Produktentwicklung nicht im Blick hat, wird nicht in der Lage sein, die Funktionalität so zu entwickeln, dass sie vom User angenommen wird. Folglich sollte ein Scrum-Team mit dem User zusammenarbeiten. Es muss Wege finden, den User zu beteiligen.« (Gloger 2009, 101)

3.4.1.6 Manager Grundsätzlich gilt: Der ScrumMaster ist nicht der Manager. Die Rolle des ScrumMasters ersetzt nicht das Management einer Firma. Beide müssen für das Gelingen des Prozesses und somit des Produktes, koexistieren. Es ist wichtig zu verstehen, dass Scrum in keinem Fall das Management abschafft. Das ist definitiv nicht der Zweck dieses Prozesses. Es geht vielmehr um den Wandel von einem »befehlenden« Management zu einem »schützenden«. Bisher wurde durch das Management »angeschafft« was zu erledigen ist. Somit auch der Weg und die Art der Umsetzung. Durch den Einsatz von immer mehr MitarbeiterInnen, die als ExpertInnen angestellt werden, macht dies aber keinen Sinn mehr. Warum sollte ein Manager mit wenig Wissen in Programmierung einer ProgrammiererIn befehlen was er/sie wie und wann zu machen hat? Warum sollte man für viel Geld fähige MitarbeiterInnen, ExpertInnen auf ihrem Gebiet, einstellen und gut bezahlen und dann ihre Expertise nicht nutzen. Daher verlagert sich die Aufgabe des Managements bei Scrum dahingehend, dass es sich um den ungestörten Arbeitsablauf für das Team kümmert. Das bedeutet, auch dem Team den Freiraum und die Möglichkeiten zu geben, seine Expertise voll und ganz anwenden zu können.

Scrum | Der Prozess

50

Das Management »muss dafür sorgen, dass ein Team seine Mission erledigen kann. Ein Team braucht einen Raum, ein Gebäude, einen Kunden, eine Aufgabe, das Ziel, Ressourcen, Arbeitsmittel, einen Kontext.«

(Gloger 2009, 103)

Der beschriebene Wandel führt zu anderen Anforderungen an das Management: »Die Aufgabe des Managers in Scrum ist es, mit dem SrumMaster gemeinsam an den Impediments zu arbeiten, auf seiner Ebene die richtigen Maßnahmen einzuleiten, die richtigen Gespräche zu führen, den Weg zu ebnen, Konflikte zu lösen und vieles mehr. Der Manager ist dabei entscheidend. Im Gegensatz zum SrumMaster ist er ermächtigt, die Probleme zu lösen. Der ScrumMaster kann sie nur aufzeigen und dafür sorgen, dass sie gelöst werden. Er findet im Manager seinen Ansprechpartner. Wenn der Manager seine Mitarbeiter nicht als Ausführer von Anweisungen sieht, sondern mit dem Team gemeinsam arbeitet und sich als Beschleuniger seines Teams sieht, wird er zu völlig neuen Erkenntnissen über sein Team und dessen Möglichkeiten kommen.« (Gloger 2009, 104)

3.4.2 Artefakte Scrum ist ein simpler Prozess. Außer den bereits beschriebenen Rollen gibt es nur noch eine klare, sich immer wiederholende Meetingstruktur. Diese Struktur wird im nächsten Kapitel behandelt. Um diesen Meetingverlauf sinnvoll zu betreiben und mit Inhalten zu füllen, gibt es noch eine Reihe an Tools, die für den Scrumprozess wichtig sind. Dazu zählen die beiden wichtigsten Listen: Das Product Backlog und das Impediments Backlog. Das Product Backlog wird innerhalb der dafür vorgesehenen Meetings (Sprint Planning 1 und 2) in überschaubare Teile zerlegt. Dabei entstehen das Selected Product Backlog und das Sprint Backlog. Um den Fortschritt innerhalb eines ein- bis vier Wochen dauernden iterativen Zyklus, also eines Sprints, immer mitverfolgen zu können, gibt es ein Task Board und ein Burn Down Chart. Das Ergebnis eines Sprints wird als Potentially Shippable Product Increment bezeichnet.

3.4.2.1 Product Backlog Das Product Backlog beinhaltet alle zu erledigenden Eigenschaften und Merkmale des Produkts. Es wird vom Customer zusammen mit dem Product Owner erstellt und

Scrum | Der Prozess

51

priorisiert, das bedeutet in die Reihenfolge gebracht, in der die Eigenschaften erstellt werden sollen. Der Product Owner ist für die Pflege dieses »Living Documents« zuständig. Dabei soll das Team, und natürlich auch der End User immer wieder zusätzlichen Input liefern. In allen Meetings die der Scrumprozess vorschreibt, können durch Gespräche und Diskussionen zusätzliche Inhalte und Anforderungen geschaffen, oder bereits vorhandene verändert werden. Die Anforderungen an das Produkt werden in Form von UserStories formuliert. UserStories sind Eigenschaften bzw. Funktionen im Endprodukt und keine einzelnen Tasks, Anforderungen oder Aufgaben für die Teammitglieder. Diese UserStories beschreiben eine Funktion, welche der End User im Produkt verwenden kann. Wie diese Funktion in die Realität umgesetzt werden soll, wird vom Team in den dafür vorgesehenen Meetings (Sprint Planning 1 und 2) bestimmt und mittels einzelner Tasks umgesetzt. Das Product Backlog ist das zentralste und damit wichtigste Dokument des Scrumprozesses. »Das Product Backlog ist eine Liste aller im Projekt bekannten User Stories. Jedes Scrum-Projekt hat genau ein Product Backlog. Es ist die einzige und zentrale Instanz, die sämtliche funktionalen Anforderungen des Systems enthält.« (Wirdemann 2009, 98) Die Priorisierung des Backlogs ist ein zentrales Element des iterativen, agilen Prozesses. Durch eine schnelle Umpriorisierung des Backlogs kann der Customer immer von Sprint-Start zu Sprint-Start seine/ihre Wünsche an das Produkt ändern bzw. anpassen. Damit bleibt der Customer immer Herr der Lage. »Alle Einträge im Product Backlog sind priorisiert. Der Product Owner entscheidet darüber, wonach und wie die Anforderungen priorisiert werden. Üblicherweise wird das Product Backlog nach Nutzen, Risiko und Kosten priorisiert, [...] Das Team unterstützt den Product Owner insbesondere bei der Identifizierung und Berücksichtigung technischer Risiken.« (Pichler 2008, 28)

»Das Product Backlog verändert sich über die gesamte Projektlaufzeit: Neue Anforderungen werden aufgenommen, existierende Anforderungen modifiziert und verfeinert oder gestrichen. Außerdem kann sich die Priorität der Anforderungen ändern. Nicht nur die Software, auch das Product Backlog wächst somit iterativ-inkrementiell: Gestartet wird mit einem grobgranularen Backlog, das von Sprint zu Sprint weiter detailliert und verfeinert wird. Das Product Backlog entspricht somit nicht einer traditionellen Anforderungsspezifikation oder dem Pflichtenheft: Die Anforderungen sind zu Beginn eines Scrum-Projekts weniger detailliert und vollständig beschrieben verglichen mit traditionellen Anforderungsdokumenten.« (Pichler 2008, 28)

Scrum | Der Prozess

52

Der letzte wichtige Punkt für ein funktionierendes Backlog sind die abgeschätzten Userstories. Das bedeutet, dass alle Userstories für sich, einer Schätzung unterzogen werden. Dies erledigt das Team. Dabei wird nicht die Zeit geschätzt, welche für die Story verwendet werden muss, sondern der Aufwand. Dafür werden in der Regel Story Points verwendet. Diese können als ein relativer Maßstab für den Aufwand der Userstory gesehen werden. Die Story Points haben nur relevanz innerhalb eines Teams. Ein anderes Team könnte mit diesen relativen Größen nicht arbeiten. Die Story Points werden allen Userstories innerhalb des Estimation Meetings vom Team mittels Planning Poker zugeteilt.

3.4.2.2 Selected Product Backlog »The sorted list of Product Backlog Items the Scrum-Team wants to build till the end of a sprint.« (Gloger 2010, 15) Das Selected Product Backlog ist die Auswahl an Userstories, die vom Team für den folgenden Sprint als abarbeitbar akzeptiert wurde. Innerhalb des Sprint Plannings 1 werden aus dem priorisierten und geschätzten Product Backlog der Reihe nach die obersten Userstories in das Selected Product Backlog übernommen. Dies wird so lange gemacht, bis das Team sich selbstständig gegen das nächste Item ausspricht. Damit werden die ausgewählten Userstories, zu Items, die bis zum Ende des folgenden Sprints erledigt werden müssen. Es ist wichtig, dass das Team selbstständig entscheidet, da es sich somit auch selbstständig für diese Aufgaben committed hat. Dieses Commitment bedeutet in Scrum, dass sich das Team selbst dazu verpflichtet hat, selbst gewählte Items bis zum Ende des Sprints fertig zu stellen.

3.4.2.3 Taskboard Das Taskboard ist neben dem Product Backlog das zweite wichtige Tool in Srum. Es hängt an einem frei zugänglichen Platz, das bedeutet, nicht im Büro der Chef/In, oder des ScrumMasters. Der Inhalt des Selected Product Backlogs wird komplett auf dem Board dargestellt. Die ausgewählten Userstories des aktuellen Sprints werden dort für alle sichtbar aufgehängt. Innerhalb des Sprint Plannings 1 werden die ausgewählten Userstories in, in einem Tag erledigbare, Tasks zerlegt. Diese Tasks hängen nun auch auf dem Taskboard. Daher auch der Name dieses Tools. Das Board ist in vier vertikale Spalten

Scrum | Der Prozess

53

eingeteilt: »Userstories«, »Tasks to Do«, »Work in Progress« und »Done«. Die Userstories hängen selbstverständlich in der Spalte »Userstories«. Die aus den Userstories im Sprint Planning 2 generierten Tasks hängen in »Tasks to Do«. Jedes Teammitglied wählt einen oder mehrere Tasks im Daily Sprint aus und committed sich, diese bis zum nächsten Daily Scrum zu erledigen. Wenn diese Tasks erledigt sind, werden sie vom Teammitglied selbst auf »Done« gehängt. Natürlich können in einem agilen Prozess wie Scrum auch während des Sprints noch Tasks generiert werden, die nötig sind, um die Userstory zu erledigen, oder auch falsche oder überflüssige Tasks entfernt werden. Die Entscheidung über die richtigen Tasks bleibt allein dem Team vorbehalten. Manchmal bleiben Tasks hängen und werden nicht an einem Tag erledigt. Sie bekommen dann einen grünen Punkt pro überzogenen Tag. Dies soll nur ein Hinweis darauf sein, dass die Aufgabe nicht vorankommt. Die Gründe dafür werden in der Regel im Daily Scrum besprochen. Der Task könnte z.B. zu groß sein und müsste daher in mehrere kleinere Tasks zerlegt werden oder es gibt ein Impediments, z.B. gibt es benötigte Assets oder Code-Teile noch nicht. In diesem Fall muss im Daily Scrum der Task aufgesplitted, oder zu den »Tasks to Do« zurückgehängt werden, bis die Impediments beseitigt worden sind. Das Taskboard wird niemals vom ScrumMaster geführt. Das Team selbst bewegt die Tasks und Userstories. Das Team hat sich zu diesen Aufgaben verpflichtet und organisiert auch selbstständig deren Abarbeitung. »Ein Taksboard hilft dem Team, seine Aufgaben übersichtlich anzuordnen und immer den Überblick zu behalten.« (Gloger 2009, 162)

3.4.2.4 Burn Down Chart »Das Messen des Sprint-Fortschritts erfolgt auf zweierlei Art — über das Taskboard und über ein Sprint-Burndown-Chart. Das Taskboard visualisiert die noch verbleibende Arbeit und zeigt auf, wo das Team im Sprint steht. Das Sprint-Burndown-Chart visualisiert den SprintFortschritt auf der Basis von Story Points.« (Wirdemann 2009, 164) Das Burn Down Chart zeigt dem Team den Fortschritt während eines Sprints und hilft eine Velocity für die Entwicklung des Produkts zu errechnen. Die Userstories werden immer wieder aufs Neue im Estimation Meeting abgeschätzt und mit Story Points mittels Planning Poker versehen. Jede Userstory die im Selected Product Backlog landet, ist bereits geschätzt und hat Story Points. Wenn alle Story Points zusammengezählt werden, ist offensichtlich, wie viele Points das Team sich selbst für diesen Sprint ausgewählt hat. Diese Points sind dann innerhalb des Sprints abzuarbeiten. Um den Fortschritt

Scrum | Der Prozess

54

dieser Abarbeitung visuell und transparent gegenüber allen Rollen darzustellen, wird er mittels eines Burn Down Charts aufgezeigt. Dabei werden immer am Ende des Daily Scrums die Story Points der erledigten Tasks und Userstories zusammengezählt und von der Zahl, der noch zu erledigenden Points abgezogen. Wenn dies in einem Zeitraster geschieht, erhält man eine ständig absteigende Kurve. Diese Kurve sollte optimalerweise am Ende des Sprints bei Null ankommen, damit wären alle Userstories des Sprints abgearbeitet. Falls dies wiederholt nicht geschieht, sollte sich das Team beim Sprint Planning 1 in Zukunft für weniger Userstories committen. Nach ca. 4-6 Sprints wird sich das Team auf eine ungefähr gleich große Anzahl an Story Points pro Sprint einpegeln. Dieser Durchschnittswert wird als Velocity bezeichnet und dient dem ScrumMaster dazu, bessere Prognosen für das Releaseplanning des Produkts zu erstellen. Außerdem dient es dem Product Owner, den Customer besser bei der Priorisierung der Userstories zu unterstützen. Kernfunktionen und Anforderungen rücken dabei mehr in den Vordergrund und »Nice-to-Have«-Anforderungen werden hinten angestellt, oder für eine zukünftige Version oder ein Update vorgemerkt. Das hilft ein Produkt so funktionsfähig wie möglich auszuliefern und nicht während der Entwicklungsphase den Fokus auf die falschen Aspekte zu lenken. »Der Bericht ermöglicht es, den Fortschritt innerhalb eines Sprint zu verstehen. So können wir beurteilen, wie wahrscheinlich es ist, dass alle Anforderungen in ein Produktinkrement umgewandelt werden können. Wir vergleichen dabei den Fortschritt der letzten Tage mit dem idealen Fortschritt. Der Bericht ermöglicht dem Team, seine Selbstorganisation zu optimieren.« (Pichler 2008, 118)

3.4.2.5 Potentially Shippable Product Increment Zum Ende eines jeden Sprints hat das Team ein Potentially Shippable Product Increment entwickelt. »At the end of the Sprint the Scrum-Team delivers a Potentially Shippable Product Increment. A piece of the product that you would not need to work on again. If development stops right now, it is in a shape that could be used as it is.« (Gloger 2010, 15) Hier stellt sich eine der wichtigsten Grundideen von Scrum deutlich dar; Am Ende eines jeden Sprints sind die gewünschten Merkmale des Produkts, welche in einer Userstory beschrieben wurden, vollständig umgesetzt und funktionsfähig. Es gibt keine unübersichtlichen Zwischenstände von Funktionen, die nicht getestet werden können. Alle Merkmale können im Sprint Review von allen beteiligten Rollen ausgiebig geprüft

Scrum | Der Prozess

55

werden. Daher können von Sprint zu Sprint neue Merkmale hinzukommen, aber das bisher geschaffene Produkt funktioniert und der Customer könnte zu jedem Sprint Ende die Entwicklung abbrechen und hätte seine wichtigsten (am höchsten priorisierten) Funktionen im Produkt. Dies stellt nochmals die Wichtigkeit einer wohl durchdachten Priorisierung dar.

3.4.2.6 Impediments Backlog Impediments sind Hindernisse, welche das Team am Arbeiten hindern. Das Impediments Backlog ist eine, für alle beteiligten Rollen frei zugängliche Liste dieser Impediments. Im Gegensatz zum bisherigen Umgang mit Fehlern und Problemen werden diese öffentlich dargestellt, um sie allen ins Bewusstsein zu rufen. »Menschen, die mit Scrum arbeiten, wissen jedoch, dass nur das offene und direkte Ansprechen von Problemen, Missständen, Unzufriedenheiten und Konflikten dazu führt, dass diese schnell und produktiv gelöst werden.« (Gloger 2009, 210) Der Impediments Backlog ist das Ergebnis eines nicht funktionierenden Risikomanagements. Durch die ständige Kontrolle und Suche von Impediments bleiben diese in einem kontrollierbaren Rahmen. Denn nur bekannte Risiken können verhindert werden. Wenn Risiken nicht bekannt sind, führen sie zu einer Krise. »Ein Risiko ist ein Problem, das erst noch auftreten muss, und ein Problem ist ein Risiko, das bereits aufgetreten ist.«

(DeMarco 2003, 11)

Bei Impediments handelt es sich also bereits um Probleme, nicht

mehr um Risikomanagement, sondern um Krisenmanagement. »Das Gegenteil von Risikomanagement heißt Krisenmanagement. Bei Krisenmanagement geht es darum, eine Lösung für das Problem zu finden, nachdem es aufgetreten ist.« (DeMarco 2003, 12) Das Impediments Backlog ist ein systematisches Krisenmanagement. Alle Probleme, Hindernisse und Impediments, welche sich für das Team ergeben und es am arbeiten hindern, sind für den Scrum-Prozess problematisch. Scrum setzt darauf, dass das Team ungestört und selbstständig arbeiten kann, um das bestmögliche Produkt zu entwickeln. Impediments hindern das wertvolle Team an seiner Arbeit. Daher ist der Begriff Krisenmanagement durchaus gerechtfertigt. Allerdings lässt es die ständige Suche und Kontrolle von Impediments nie so weit kommen, dass das Team massiv oder langfristig durch diese Impediments behindert wird. Das Impediments Backlog wird vom ScrumMaster betreut. Damit wird wiederum seine Rolle als »Hirtenhund« vor

Scrum | Der Prozess

56

Augen geführt. Eine weitere gute Bezeichnung für das Impediments Backlog ist »Wall of Shame«, da alle Hindernisse die der ScrumMaster nicht erfolgreich beseitigen konnte, für alle sichtbar, ausgehängt werden und er sich symbolisch für seine nicht erledigte Aufgabe schämen müsste.

3.4.3 Meetings Der Scrumprozess basiert auf einer sehr simplen Abfolge von Meetings. Diese Struktur wird vom ScrumMaster überwacht und ist strikt einzuhalten. Es gibt eine iterative Reihe von Meetings für den direkten Sprintlauf und ein Meeting das bei Bedarf abgehalten werden muss. Der Ablauf besteht aus Sprint Planning 1, Sprint Planning 2, Daily Scrum, Sprint Review und Sprint Retrospective und beginnt dann sofort wieder von Neuem mit Sprint Planning 1. Das nach Bedarf angesetzte Meeting ist das Estimation Meeting.

3.4.3.1 Time-Boxed Alle Scrum Meetings sind Time-Boxed. Das bedeutet, sie haben eine feste Zeitvorgabe und halten diese auch ein. Es gibt keine Zeitüberschreitungen. »Das Entscheidende am Timeboxing ist, dass das Ende einer Timebox in Stein gemeißelt und damit nicht verschiebbar ist. Stattdessen ist der Umfang, das heißt die in einer Timebox zu erledigende Arbeit oder die abzuliefernde Funktionalität variabel.« (Wirdemann 2009, 33) Damit wird auch das übergeordnete Prinzip von Scrum widergespiegelt. Ein Sprint dauert eine fest gesetzte Zeit und kann nicht früher abgebrochen oder verlängert werden. Nur der Inhalt, also die Menge und Art der Userstories ist vom Team festgesetzt. Damit kann das Team selbst steuern was es innerhalb dieses Sprints erledigt und ob es damit auch pünktlich fertig wird. Die Pünktlichkeit ist bei Scrum von oberster Priorität. Bei dem Daily Scrum handelt es sich z.B. um ein Meeting mit einer maximalen Dauer von 10 Minuten. Falls ein Teammitglied um nur 5 Minuten zu spät erscheint, hat es bereits 50% des Meetings verpasst. Jedes Teammitglied hat zwar die Freiheit, seine Arbeitsweise und den Weg seiner Arbeit selbst zu bestimmen, jedoch enthält dies auch Verantwortung. Pünktlich zu den Meetings zu erscheinen und eine gewisse Disziplin mitzubringen, ist ein Teil dieser Verantwortung.

Scrum | Der Prozess

57

3.4.3.2 Estimation Meeting Dieses Meeting wird nach Bedarf angesetzt. Der Product Owner erscheint zu diesem Meeting mit dem aktuell richtig priorisierten Product Backlog. Teilnehmer des Meetings sind das Team, der ScrumMaster, der Product Owner und der End User. Die Time-Box sind 90 Minuten. In dieser Zeit werden die Userstories des Product Backlogs der Reihenfolge nach estimated, also abgeschätzt. Dazu wird in der Regel eine Schätzungsmethode verwendet, die Planning Poker genannt wird. Dabei erhält jedes Teammitglied einen Satz spezieller Spielkarten, welche jeweils mit einer Zahl der unreinen Fibonacci-Reihe nach Cohn bedruckt ist: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 und »?«. (Vgl. Gloger 2009, 141) Bei jeder Userstory wird der ScrumMaster das Team fragen, wie viele Story Points von den jeweiligen Teammitgliedern gegeben werden. Wenn sich alle entschieden haben, werden die Karten gemeinschaftlich umgedreht. Dabei kann im Idealfall ein einheitliches Ergebnis entstehen. In der Regel allerdings werden Teammitglieder, die ExpertInnen in verschiedenen Details des Produkts sind, unterschiedliche Werte für den Aufwand schätzen. Dies ist positiv, da es die Teammitglieder zur Diskussion anregt und sie dabei ihre jeweiligen Expertisen zum Ausdruck bringen. Grundsätzlich wird immer nur der Aufwand und nie die Dauer geschätzt. Dazu wurden die Story Points als neutrale und vor allem relative Einheit erfunden. Die geschätzten Werte im Backlog gelten nur für das jeweilige Team und würden in einer anderen Teamkonstellation unbrauchbar sein. Der Prozess des Planning Pokers wird pro Userstory so lange wiederholt, bis ein einheitliches Ergebnis in das Backlog eingetragen werden kann. »Ziel des Pokerns ist, dass das Team sich auf einen gemeinsamen Wert pro Story einigt. Es ist nicht ungewöhnlich, dass die Punktezahlen in der ersten Schätzrunde relativ weit gestreut sind. Unterschiedliche Experten sehen unterschiedliche Dinge, und genau um das Ausgraben dieser Informationen geht es. Der Teilnehmer mit der niedrigsten und der Teilnehmer mit der höchsten Punktzahl erläutert seine Schätzung.« (Wirdemann 2009, 77) Der ScrumMaster hat dabei nur eine organisierende Rolle. Er achtet wie immer auf das Einhalten der Scrum Regeln. Der End User kann immer wieder Input geben und Userstories zur Diskussion stellen. Der Product Owner steht dem Team für Fragen über die jeweiligen Userstories zur Verfügung. Diese Fragen und die Klärung der Selben sind ein essentieller Bestandteil aller Scrum Meetings. Alle Scrum Meetings sollen zu Diskussionen und zur Erläuterung ungeklärter Fragen dienen, um dem Team das

Scrum | Der Prozess

58

bestmögliche Verständnis über das Produkt und dessen Vision zu ermöglichen. Nur eine vollständig akzeptierte und einheitlich verstandene Vision eines Produkts wird zu einer adäquat bestmöglichen Umsetzung dieses Produkts führen.

3.4.3.3 Sprint »Wie der Begriff Sprint andeutet, sind die Arbeitszyklen in Scrum kurz.« (Pichler 2008, 81) Als Sprint wird ein Durchgang des Scrumprozesses und damit alle Meetings und die Entwicklungszeit verstanden. Die Länge eines Sprints wird am Anfang des Projekts festgelegt und danach nicht mehr geändert. Veränderungen würden die Sicherheit und die Regelmäßigkeit des Prozesses gefährden und die Planbarkeit mittels Velocity unmöglich machen. In der Regel ist die Sprintdauer zwischen einer und vier Wochen. »Wir ScrumTrainer empfehlen, dass ein Sprint 30 Kalendertage lang sein sollte. Allerdings hat sich in der Praxis bewährt, aus diesen 30 Kalendertagen 28 Tage zu machen und damit auf einen konstanten 4-Wochen-Rhythmus zu wechseln. Die Länge der Sprints sollte immer konstant sein – nur wenn die ‘Timebox’ immer gleich lang ist, kann man die Kapazität eines Teams annähernd korrekt bestimmen. Entscheidend ist: Ein Sprint wird nicht verlängert. Es gibt keinen Grund, weshalb ein Sprint verlängert werden sollte. Die Begrenzung, die die Timebox des Sprints erzeugt, ist wesentlich für die Generierung der Struktur, die das Team selbstständig erzeugt. Lassen wir das Team aus der Begrenzung der Timbox heraus, steigt dadurch nicht etwa die Produktivität, nein, sie wird sinken. Das Ende eines Sprints ist wie eine ‘Deadline’. Nur durch die harte Realität, dass zu diesem Zeitpunkt eine Abnahme fällig ist, entsteht genügend Druck, der die Organisation und das Team dazu zwingt, die Entwicklungsprozesse so zu verändern, dass ein Produkt entsteht.« (Gloger 2009, 195) Innerhalb eines Sprints werden folgende Meetings abgehalten: Sprint Planning 1, Sprint Planning 2, je nach Sprintlänge mehrere Daily Scrums, Sprint Review und abschließend Sprint Retrospective. Alle Meetings müssen für den Scrumprozess abgehalten werden und haben essentielle Funktionen. Der Sprint an sich ist aber auch der Zeitraum zwischen diesen Meetings, also die Entwicklungszeit als solches. Der Inhalt und die Ziele eine Sprints sind nach dem Sprint Planning 1 nicht mehr veränderbar. Allerdings kann ein Sprint komplett abgebrochen werden. Dies hat nichts mit scheitern zu tun, sondern mit sinnvollem Handeln.

Scrum | Der Prozess

59

»Der Sprint kann vom Team beendet und später neu aufgesetzt werden, wann immer die Teammitglieder meinen, sie könnten ihr Ziel nicht mehr erreichen. Natürlich kann ihn auch der Product Owner beenden wenn er der Meinung ist, das das Ziel nicht mehr sinnvoll ist.« (Gloger 2009, 192)

Das Ergebnis eines Sprints ist immer ein Potentially Shippable Product Increment, also ein fertiger Teil eines Produkts. Somit wird das Produkt von Sprintende bis Sprintende immer um einen weiteren lauffähigen Teil entwickelt. »Am Ende eines Sprint muss der Product Owner die entstandene Software begutachten können. Damit dies möglich ist, muss jeder Sprint ein Produktinkrement erzeugen und vor etlichen Veränderungen geschützt sein. Zusätzlich ist die Zeit, die Scrum-Besprechungen beanspruchen dürfen, begrenzt. Sprints wandeln Anforderungen aus dem Product Backlog in lauffähige, getestete und dokumentierte Software um. Jeder Sprint schafft so einen greifbaren Mehrwert.« (Pichler 2008, 83)

3.4.3.4 Sprint Planning 1 Im Sprint Planning 1 geht vor allem um die Frage: Was? »Metaphor for this meeting: Analysis. The goal of this meeting is to understand in detail what the End User wants. This meeting will enable the product development team to get a clear picture of what is needed by the End User. At the end of this meeting the Team will be able to decide what they are able to deliver.« (Gloger 2010, 5) Konkret bedeutet es, dass es um das Verständnis und die Auswahl der, zu bearbeitenden, Userstories aus dem Product Backlog geht. Das Ergebnis des Sprint Planning 1 ist das Selected Product Backlog. Das Team entscheidet sich, was es in diesem Sprint schaffen kann und verpflichtet sich zur Umsetzung. Dabei muss daran gedacht werden, dass es wie im übergeordneten Projekt funktioniert. Die Ziele müssen S.M.A.R.T. (Spezifisch, Messbar, Ausführbar, Realistisch, Terminiert) sein. Der Product Owner hat also die Verpflichtung zum Sprint Planning 1 mit einem priorisierten und auf seine Ziele überprüften Product Backlog zu erscheinen. Um dem Team genau erklären zu können, um was es bei den einzelnen Userstories geht, muss der Product Owner sich gut vorbereiten. Im Sprint Planning 1 muss er dann eine gemeinsame Vision des Produkts bzw. des Potentially Shippable Product Increment schaffen können.

Scrum | Der Prozess

60

»Im Sprint Planning werden aus dem Plan und dem Kontext, in dem sich das Team befindet, realistische Ziele und Aktionen für die nächsten vier Wochen festgelegt. [...] Der Product Owner erläutert sein Ziel für den Sprint, präsentiert das Product Backlog und erläutert sehr konkret, was er sich unter den einzelnen Backlog Items vorstellt. Dann übernimmt das Team und fragt den Product Owner genauestens aus. Alle notwendigen Personen sind anwesend, damit aus Backlog Items Anforderungen, Testfälle und klare Akzeptanzkriterien werden.« (Gloger 2009, 157)

Kurz vor dem Ende des Meetings werden alle bis auf das Team und den ScrumMaster aus dem Raum gebeten. Nun geht der ScrumMaster alle Userstories in der Reihenfolge der Priorisierung durch und fragt bei jeder Story das Team, ob dieser Task auch innerhalb des nächsten Sprints erledigen werden kann. Bei der ersten Userstory, bei der auch nur ein Teammitglied Zweifel über die Erledigung dieses Commitments hat, wird gestoppt und damit ist das Selected Product Backlog zusammengestellt. Wiederrum wird an dieser Stelle die Wichtigkeit und auch die Verantwortung des Teams deutlich.

3.4.3.5 Sprint Planning 2 Im Sprint Planning 2 geht es vor allem um die Frage: Wie? Mit dem sozusagen frisch ausgewählten Selected Product Backlog wird nach einer kurzen Pause noch am selben Tag, direkt das Sprint Planning 2 abgehalten. Nun werden ausschließlich die ausgewählten Userstories für die Umsetzung durchgedacht. »Metaphor for this meeting: Design. The product development team has the chance to create the design for the solution they want to implement. At the end of this meeting, the Team knows how to build the functionality they will develop in that Sprint.« (Gloger 2010, 7) Nachdem die Userstories im Sprint Planning 1 ausführlich besprochen wurden und alle Teammitglieder über das Ergebnis der jeweiligen Story für den End User bescheid wissen, das als Funktionalität vorhanden sein soll, wird nun ausführlich der Weg dorthin geklärt. An diesem Meeting nehmen ausschließlich das Team und der ScrumMaster teil. Wiederrum achtet der ScrumMaster auf die die Einhaltung der Scrum-Regeln und -Abläufe. Das Team hat alle Freiheit, die es braucht, um sich durch seine Expertise einen sinnvollen Weg zur benötigten Funktion zu erarbeiten und einen adäquaten Plan für die Umsetzung innerhalb des Sprints zurecht zu legen. Um die besten Lösungen zu

Scrum | Der Prozess

61

erarbeiten, kann das Team als Gruppe diskutieren, oder sich in kleinere Arbeitsgruppen teilen. Wichtig ist allerdings, am Schluss zu einem Konsens zu kommen. Nun ist es an der Zeit aus den Userstories kleinere Tasks heraus zu brechen, die nicht größer als eine Tagesaufgabe sein sollten. Die einzelnen Tasks werden auf das Taskboard geheftet und können im Laufe des Sprint einzeln abgearbeitet werden. »Dieses Meeting ist eine Arbeitssitzung in der das Team an Design, Spezifikation, Architektur und allen anderen Dingen arbeitet, die notwendig sind. Das Team erarbeitet hier seine Umsetzungsvorstellungen. Als Resultat dieses Meetings weiß jeder, wie man die gewählten Aufgaben gemeinsam bewältigen will. Es wird noch nicht festgelegt wer welche Aufgaben durchführt.« (Gloger 2009, 161) Für jeden Task bzw. jede Userstory wird eine »Definition of Done« bestimmt. Dies bedeutet, dass im Team besprochen werden muss wann eine Aufgabe als erledigt gilt. (Vgl. Gloger 2010, 10) Diese

Idee klingt banal, aber es zeigt sich immer wieder, dass einzelne

Teammitglieder ein anderes Verständnis über die Fertigstellung einer Aufgabe haben. Als einfaches Beispiel kann hier in etwa eine Annahme angeführt werden, ob eine bestimmte Funktion auch noch einem Test und einer Dokumentation bedarf oder nicht, um als abgeschlossen betrachtet zu werden. Dabei werden die Meinungen im Team auseinander gehen. In Scrum sind sowohl der Test, als auch die Dokumentation in die Zeitplanung des Sprints mit einzubeziehen.

3.4.3.6 Daily Scrum Das Daily Scrum ist das einzige Meeting welches sich innerhalb eines Sprints wiederholt. Jeden Tag zur selben Zeit und am selben Ort wird dieses Daily Stand Up Meeting vor dem Taskboard abgehalten. Stand Up Meeting im wörtlichen Sinne: Niemand setzt sich während dieses Meetings hin. (Vgl. Pichler 2008, 106) Dies schafft den nötigen Druck und auch die Spannung, um ein solch kurzes Meeting im Zeitrahmen zu realisieren. Die Time Box für das Daily Scrum beträgt maximal 15 Minuten. Es geht innerhalb dieser kurzen Zeit vor allem um einen schnellen Informationsaustausch zwischen den Teammitgliedern. Es gibt drei Fragen, die jedes Teammitglied kurz und bündig beantworten soll und dabei seine/ihre Antworten auf dem Taskboard widerspiegelt:

»1. Was habe ich seit dem letzten Meeting erreicht?



2. Was will ich bis zum nächsten Meeting erreichen?



3. Was steht mir dabei im Weg?

Scrum | Der Prozess

62

Diese Fragen müssen jeden Tag innerhalb von 15 Minuten von allen externen oder internen Teammitgliedern, die aktiv am Sprint beteiligt sind, beantwortet werden. Die Auseinandersetzung mit diesen drei Fragen genügt, um alle Teammitglieder über den aktuellen Stand der Entwicklung auf dem Laufenden zu halten. Die Beantwortung dieser drei Fragen ermöglicht die tägliche Synchronisation aller Beteiligten, denn so können Informationen schnell ausgetauscht, Abstimmungsprobleme gelöst und Impediments sofort erkannt und vom ScrumMaster bearbeitet werden« (Gloger 2009,167) Jedes Teammitglied nimmt dabei seine/ihre erledigten Tasks und hängt sie auf »Done«. Die nächsten Tasks bis zum nächsten Daily Scrum werden ausgewählt und auf »In Progress« gehängt. Falls Impediments oder Probleme bestehen, werden sie auf dem Impediment Backlog festgehalten. Zum Ende des Meetings werden noch die abgearbeiteten Storypoints im Burn Down Chart verzeichnet.

3.4.3.7 Sprint Review »The Scrum-Team shows the results of its work to the End User. The team member wants to have feedback. This feedback can be used to create or change Backlog Items.« (Gloger 2010, 19) Das Sprint Review ist grundsätzlich ein Mittel zur Kontrolle und damit auch ein Mittel zur Adaption. Hauptfunktion ist die Präsentation des Potentially Shippable Product Increment bzw. des derzeitigen Stand des Produkts. Dabei sind auf alle Fälle das Team, der ScrumMaster und der Product Owner anwesend. Es können aber nach Bedarf und Interesse auch der Manager, der Customer, der End User und etwaige, sonst involvierte Interessengruppen (Zulieferer, Outsourcingpartner, Publisher,...) eingeladen werden. (Vgl. Gloger 2009, 173) Im Review werden die, im letzten Sprint erledigten Userstories innerhalb des Produkts präsentiert, bzw. zum Test freigegeben. Es sind keine Präsentationen im Sinne von Powerpoint oder Ähnlichem gemeint, sondern ein direktes Testen des Produkts. Dazu muss ein Rechner mit dem derzeitigem Stand des Games vorhanden sein, und jede eingeladene Partei, darf die im letzten Sprint eingebauten Funktionen testen und was noch wichtiger ist, sinnvolle Kritik und Vorschläge abgeben. Diese werden vom ScrumMaster bzw. dem Product Owner gesammelt und danach in den Product Backlog eingebaut, um als eine zukünftige Userstory eingearbeitet zu werden. »Die Sitzung ist somit eine Anwendung von inspect and adapt.« (Pichler 2008, 107)

Scrum | Der Prozess

63

Bei den Begriffsklärungen im ersten Kapitel wurde auf den wichtigen Faktor des Vertrauens hingewiesen. Vertrauen sollte von der Führung bzw. vom Management immer von Anfang an gegeben und nur zu den abgesprochenen Terminen eingefordert werden. Das Risiko, das man mit einem Teammitglied eingeht, ist nicht vermeidbar und daher ist es sinnvoller, nicht von Anfang an auf dieses Risiko mit dauerndem Druck (eine Form von Angst des Managements) einzugehen, sondern dem Teammitglied überhaupt erst die Möglichkeit zu geben, sich zu beweisen und das, ihm/ihr gegebene Vertrauen als gerechtfertigt darzustellen. (Vgl. Sprenger 2007, 71) In Scrum ist das Sprint Review genau dafür vorgesehen. Hier kann und muss das gegebene Vertrauen in das Team eingefordert werden. An dieser Stelle muss das Team seine, im letzten Sprint erledigten, Userstories präsentieren und sie der Kritik der anderen beteiligten Parteien Preis geben. Wichtig ist dabei allerdings, dass dies in einem geregelten Rahmen geschieht und daher weniger schnell als unnötige Kritik aufgefasst wird, sondern sich das Team darauf vorbereiten und über ein sinnvolles Feedback und den Input sogar freuen kann. Damit geschieht eine Abnahme des Produkts in kleinem Rahmen. Oftmals wird durch zu lange Wartezeiten das Vertrauen des Customers belastet und es entsteht Angst, welche sich in Kontrolle durch Machtausübung niederschlägt. Dies führt nicht selten zu einem sehr schlechten Betriebs- und Arbeitsklima. Dieser Gefahr wird durch ein einfaches 90-minütiges Meeting entgegengewirkt. Der Customer und auch alle anderen beteiligten Parteien bekommen immer Stück für Stück Ergebnisse zu sehen und sind somit stets in die Entwicklung mit einbezogen. Dies schafft ein sehr transparentes und damit angenehmes Klima. Im eingeschränkten Bereich, also innerhalb des Teams geschieht dies ebenfalls jeden Tag beim Daily Scrum. Teammitglieder bekommen jeden Tag ein kleines Update über die Arbeit der jeweils anderen Beteiligten. Damit kommt niemals das Gefühl von Unsicherheit auf, welches man so gut aus anderen Projekten kennt, bei denen man erst nach langen Zeitspannen, oder im schlechtesten Fall erst am Ende herausfindet ob die anderen Beteiligten ihre Aufgaben gemacht haben oder nicht. Das Feedback ist also Input für den Product Backlog und gleichzeitig eine Möglichkeit, Spannungen, welche durch Ungewissheiten auftreten können, abzubauen. »Anhand der präsentierten Software können die Beteiligten und speziell der Kunde entscheiden, ob die Ergebnisse den Erwartungen entsprechen und welche Richtung für den nächsten Sprint einzuschlagen ist. Das Sprint-Review ist die Zeit für Kurskorrekturen.« (Wirdemann 2009, 31) Beim Sprint Review zeigt sich auch, wie genau die »Definition of Done« eingehalten wurde und ob es sinnvoll ist, diese beim nächsten Sprint genauer zu definieren und

Scrum | Der Prozess

64

einzuhalten. Falls z.B. die Aufgabe als solche erledigt wurde, aber weder ein Test noch eine Dokumentation vorgenommen wurden, wäre eine Userstory zwar abgehakt, aber könnte später zu zusätzlichem Aufwand führen. Die Überprüfung der »Definition of Done« ist daher eine elementare Aufgabe innerhalb des Sprint Review Meetings.

3.4.3.8 Sprint Retrospective »Das Team beendet den Sprint mit der Sprint-Retrospektive, einer Art Metadiskussion über den eigentlichen Entwicklungsprozess und die Zusammenarbeit des Teams während des Sprints. Das Ziel von Retrospektiven ist die kontinuierliche Verbesserung des Entwicklungsprozesses und damit der Produktivität des Teams.« (Wirdemann. 2009, 31) Die Sprint Retrospective schließt den Scrum-Zyklus ab und bietet dem Team die Möglichkeit, über das Geschehene zu reflektieren und die gewonnen Erkenntnisse für die Zukunft positiv einzusetzen. Außerdem werden hier Impediments gefunden und vom ScrumMaster zusammengeführt, um aus dem Weg geräumt zu werden. Grundsätzlich gilt: »Learning from the past for the future. Improving the productivity of the Team.« (Gloger 2009, 21) Bei der Sprint Retrospective sind nur das Team und der ScrumMaster beteiligt. Es geht darum, eigene Fehler und Probleme unter sich zu besprechen und Verbesserungen zu finden, welche für dieses konkrete Team funktionieren. Dabei sind Vorschläge und Lösungen, die nicht vom Team stammen, kontraproduktiv. Das Team hat allerdings immer das Recht, sich Hilfe von Außen zu holen und jeden einzuladen, den es für sinnvoll und hilfreich hält. Es gibt mehrere Techniken um eine Sprint Retrospective anzugehen. Allerdings ist bei allen Möglichkeiten eine einfache Regel zu beachten: »Die Anwesenden müssen ehrlich kommunizieren, sich aber gleichzeitig Respekt zollen. Anschuldigungen und Fingerzeigen sind kontraproduktiv und fehl am Platz. Hilfreich ist es hingegen, Person und Sache zu trennen. Ein Prinzip bei der Einführung schlanker Vorgehensweisen ist, dass Probleme und Missstände schonungslos aufgedeckt werden. Zugleich werden diese nicht einzelnen Mitarbeitern angelastet, sondern als Unzulänglichkeiten des Systems gewertet.« (Pichler 2008, 113)

Scrum | Der Prozess

65

Boris Gloger schlägt für die Umsetzung einer Sprint Retrospective folgende sechs Schritte vor: »1. Schaffe Sicherheit. Eine gute Retrospektive benötigt einen geschützten Raum, in dem sie durchgeführt wird. Alle Beteiligten müssen sich sicher sein, dass ihnen während und nach einer Retrospektive nichts geschehen kann. 2. Sammle Fakten. Frage: Was waren die wichtigen Ereignisse, die im Gedächtnis geblieben sind? 3. Finde funktionierende Prozesse. Frage: Was lief gut? Alle Beteiligten werden nach den guten Momenten während der letzten Iteration gefragt. 4. Finde nicht-funktionierende Prozesse. Frage: Was könnte verbessert werden? In diesem Schritt werden die Anwesenden nach den nicht funktionierenden Prozessen gefragt. 5. Leite Veränderungen ein. Frage: Wer hat die Kontrolle über die Veränderungsmöglichkeiten? In diesem Schritt wird eruiert, wer etwas tun kann oder tun muss, um die Veränderung zu bewirken. 6. Entscheide über die Wichtigkeit. Im sechsten Schritt werden die Quellen der Verbesserungsmöglichkeiten nach Wichtigkeit und Nutzen für das Team priorisiert.« (Gloger 2009, 179) Bei der Sprint Retrospective kommt aus Richtung des Managements immer wieder die kritische Frage auf, ob diese Art von »Gruppentherapie« nicht herausgeschmissene Zeit und somit herausgeschmissenes Geld bedeutet? Natürlich ist das Team in dieser Zeit nicht produktiv und arbeitet nicht direkt am Produkt. Allerdings sollte man sich genau an dieser Stelle fragen, was man haben will: Ein spannungsgeladenes Team mit allen Problemen und unausgesprochenen Konflikten, die sie im Arbeitsprozess behindern, oder ein Team welches seine Konflikte regelmäßig löst und sie somit aus der Welt schafft? Ein sortiertes, den Fokus auf das Produkt gerichtetes, Team, (anstatt auf interne Probleme und Konflikte) wird mit Sicherheit schneller und mit mehr Freude an der Arbeit sein und somit über längere Sicht produktiver und qualitativ besser arbeiten. Die 90 min. pro Sprint sind also mit Sicherheit gut investiert und stärken das Commitment des Teams.

4

SCRUM | DIE ERFOLGSMETHODE CONCLUSIO

Scrum | Die Erfolgsmethode - Conclusio

67

4.1 FÜHRUNG MACHT DAS TEAM Die Grundidee der Neuausrichtung des Managements und der Führung wird schon länger gefordert. Allerdings verweisen die FürsprecherInnen dieser Idee nicht darauf, die Funktion des/der ManagerIn als solche abzuschaffen. Sie wollen eine geistige NeuPositionierung erreichen. Gucher und Kana beschreiben die alten Modelle und Konstellationen, auf Grund derer Führungskräfte und ManagerInnen Angst vor neuen Ansätzen wie Scrum, und der damit einhergehenden Neugestaltung der Führungsaufgabe, haben. Da bei solchen modernen Modellen weniger direkte Arbeitsaufgaben von dem/der ManagerIn zugewiesen werden, als viel mehr das Team der WissensarbeiterInnen selbstständig entscheidet, welche Aufgaben wie und wann angegangen werden sollen, besteht oftmals die Befürchtung, die Führung als solche, ginge verloren, bzw. die Postion als Vorgesetzte/r komme ins Wanken. »Diese Konstellationen sind Alltag in Projekten. Ausschließlich in dem seltenen Fall, in dem ManagerInnen bereit sind, Verantwortung auf die WissensarbeiterInnen zu übertragen und WissensarbeiterInnen gewillt sind, die Verantwortung für die ihnen zur Verfügung stehenden Produktionsmittel zu übernehmen, wird eine innovative Produktion in Gang kommen. In den meisten anderen Fällen werden mehr Schwierigkeiten als Erfolge zu erwarten sein.« (Gucher / Kana 2006, 41)

Daher ist ein Umdenken des Führungspersonals für agile Methoden wie Scrum unbedingt erforderlich. DeMarco und Lister sehen die selbe Problematik und beschreiben ähnliche Lösungsansätze. »Management science is much more concerned with the boss's role as principal strategist and tactician of the work. You are taught to think of management als playing out one of those battle simulation board games. There are no personalities or individual talents to be reckoned with in such a game; you succeed or fail based on your decisions of when and where to deploy your faceless resources. [...] We will attempt to undo the damage of the manager-as-strategiest view, and replace it with an approach that encourages you to court success with this formula:

- get the right people



- make them happy so theay don't want to leave



- turn them loose

Scrum | Die Erfolgsmethode - Conclusio

68

Of course, you have to coordinate the efforts of even the best team so that all the individual contributions add up to an integrated whole. But that's the relatively mechanical part of management. For most efforts, success or failure is in the cards from the moment the team is formed and the initial directions set out. With talented people, the manager can almost coast from that point on.« (DeMarco / Lister 1999, 93) Natürlich darf an dieser Stelle der Punkt: »get the right people« nicht überlesen werden. Das Einstellen der richtigen MitarbeiterInnen ist eine der wichtigsten Aufgaben in der modernen Organisation. »In der Wissensgesellschaft lautet die wahrscheinlichste Annahme, auf der alle Organisationen ihre Tätigkeit aufbauen müssen, dass die Organisation sehr viel mehr auf den Wissensarbeiter angewiesen ist, als dieser auf sie. Die Organisation hat die Aufgabe, ihre Wissensjobs so zu vermarkten, dass sie eine ausreichende Zahl hervorragender Wissensarbeiter anlocken kann. In dieser zusehends von Interdependenz gekennzeichneten Beziehung muss der Wissensarbeiter lernen, was die Organisation benötigt, und die Organisation muss herausfinden, welche Erfordernisse und Erwartungen der Wissensarbeiter hat.« (Drucker 2001, 360) Ein Game-Studio funktioniert nicht wie große Fabriken in den Zeiten der Industrialisierung. WissenarbeiterInnen führen ihre Betriebsmittel mit sich: Ihr Wissen. Ein/e ArbeiterIn in der Fabrikhalle war auf die Betriebsmittel der Fabrik angewiesen. Gerätschaften und Werkzeuge gehörten der Fabrik und nicht dem/der ArbeiterIn. Der/die moderne WissensarbeiterIn führt sein/ihr Wissen mit sich und es gehört ihm/ihr. Er/sie muss es nicht einsetzen wenn er/sie nicht will, bzw. der/die Wissensarbeiter/in kann über Qualität und Umfang entscheiden. Also ist die erste Aufgabe der Führungskraft darauf zu achten, dass die richtigen WissensarbeiterInnen mit den richtigen Betriebsmitteln und der bestmöglichen Einstellung angeworben werden. »[...] this means that getting the right people in the first place is all-important. Fortunately, you don't have to depend entirely on the luck of the draw. You may get to play a significant part in the hiring of new people or the selection of new team members from wihtin the company. If so, your skill at these tasks will determine to a large extent your eventual success.« (DeMarco/ Lister 1999, 96) Damit liegt es bereits zu Beginn eines Projekts in den Händen des Führungspersonals, wie das Scrum-Team beschaffen sein wird. Dies ist bereits der erste direkte Einfluss der genommen werden kann, um ein gutes Scrum-Team von WissensarbeiterInnen zusammenzustellen.

Scrum | Die Erfolgsmethode - Conclusio

69

Die bisher beschriebenen Methoden in Scrum bieten dem Management und der Führung die Möglichkeit, sich in neuen Rollen einzufinden, welche ihnen in keinster Weise ihre Position als Vorgesetzte streitig machen. Allerdings werden sich ihre Aufgaben ändern und vor allem ihre geistige Haltung zum Team wird in Frage gestellt und sollte daher ebenfalls angepasst werden. Natürlich sollte bei der Einführung von Scrum mittels einer Stakeholderanalyse vorab geklärt und verifiziert werden, welche beteiligten Personen, die jeweiligen Scrum Rollen einnehmen sollten. Dies kann von Fall zu Fall unterschiedlich ausfallen. Allerdings hält sich die Rollenverteilung von Scrum trotzdem an bisher bestehende Muster. Die Führungskraft wird sich oftmals in der Position des Product Owners wiederfinden. Damit wird ihre bisherige Aufgabe weitergeführt: Sie ist zusammen mit dem Customer für die große Vision, die hinter dem Produkt stehen wird, verantwortlich. Dabei entspricht ihre Aufgabe weiterhin der bisherigen Definition von Führung, also der VisionärIn. Allerdings ist es für die Funktion das Scrumprozesses wichtig, dass hier auch Grenzen gezogen werden. Obwohl die Führungskraft immer noch der/die Vorgesetzte des Teams ist, (muss je nach Stakeholderanalyse und aufgebauten Team nicht zwingend die Führungskraft übernehmen, die Product Owner Idee baut allerdings durchaus darauf auf ), muss sie sich an das Regelwerk von Scrum halten. Das bedeutet im Konkreten, dass es nicht mehr einfach möglich ist, Aufgaben dazwischen zu schieben, oder direkte Arbeitsanweisungen zu geben. Die Aufgaben können (zusammen mit dem Customer) neu priorisiert werden. Arbeitsanweisungen sind auf Grund der WissensarbeiterInnenRolle jedoch nicht mehr möglich. Sie werden anders kanalisiert. Falls es Wünsche durch die Führung gibt, werden diese in das Product Backlog aufgenommen und falls sie sofort erledigt werden sollen, müssen sie als Postion 1 priorisiert werden. Arbeitsanweisungen im Sinne einer Vorgehensweise bei der Umsetzung des Games können jederzeit im Sprint Planning 1 bei der detaillierten Besprechung der Userstories gemacht werden. Die Rolle des Scrum-Teams beinhaltet allerdings auch das Recht, sich für eine andere Methode zu entscheiden, oder zumindest eigene Meinungen einzubringen. Die Entscheidung der Umsetzung liegt jedoch letztendlich beim Team. Nausner begründet dies durch die Professionalität und verweist damit indirekt auf die Expertise der WissenarbeiterIn. »Professionalität bildet sich oft in Standards aus, sodass man weiß, was man zu tun hat (ohne viel fragen zu müssen), wenn die Aufgabenstellung klar umrissen ist.« (Nausner 2006, 69) Klar verfasste Userstories innerhalb des Product Backlogs und die zusätzliche Diskussion, welche Scrum nahzu ausdrücklich innerhalb des Sprint Planning 1 verlangt, helfen dabei, ein klares Bild der Aufgabe oder - in einem größeren Maßstab betrachtet - der Vision des Games zu bekommen. Dies ist wiederum eine Möglichkeit der

Scrum | Die Erfolgsmethode - Conclusio

70

Führung, dem Team dabei zu helfen, ihre Expertise auszuleben und somit ein besseres Game zu produzieren. Damit zeichnet sich ein partizipativer Führungsstil ab. Sowohl Blanchard und Miller, als auch Greenleaf beschreiben dazu den »Servant Leadership« also die dienende Führung. (Vgl. Blanchard/ Miller 2004, o.S.; Greenleaf 2003, o.S.) Gloger fasst diese Idee zusammen und meint »[...] die Kernaussage besteht darin, dass die Führungskraft nicht besser weiß, was zu tun ist, sondern ihre Mitarbeiter befähigt, die richtigen Handlungen selbst durchzuführen.« (Gloger 2009, 105) Hierbei ist auf die Wortwahl zu achten. »Befähigt« sollte hier so ausgelegt werden, dass Management und Führung dem/der WissensarbeiterIn auch die Möglichkeit geben, seine/ihre Betriebsmittel richtig zum Einsatz zu bringen. Dabei ist ein Framework wie Scrum, aus bereits beschriebenen Gründen, definitiv vorteilhaft. Ein artverwandter Denkansatz im Management wird als Empowerment bezeichnet. »Vor allem in den westlichen Ländern muss der Mitarbeiter in die Leitung der Unternehmensgemeinschaft einbezogen werden. Was heute als ,Empowerment‘ bezeichnet wird, hat große Ähnlichkeit mit den Konzepten, die ich vor einem halben Jahrhundert beschrieb.« (Drucker 2005, 364) Nausner schildert dies folgendermaßen: »Beim Empowerment geht es nicht nur um die Förderung von Autonomie und Selbstverantwortung, sondern um die Befähigung zur Eigeninitiative. MitarbeiterInnen sollen selbstbestimmt agieren und nach eigenem Ermessen die Schnittstellen zu anderen Aufgabenbereichen gestalten. [...] Führung bedeutet im Konzept des Empowerments immer auch Selbstführung. Jeder Akteur / jede Akteurin übernimmt z.B. Steuerungsaufgaben, die sonst in den Händen von Vorgesetzten liegen. D.h. Führung und Ausführung fallen im Empowerment zusammen – in einer Person oder in einer Gruppe gleichgestellter AkteurInnen. Empowerment mutet den Betroffenen dadurch mehr Verantwortung zu, was wiederum die Notwendigkeit zur Professionalisierung erhöht. Empowerment wird als alternative Form der Unternehmenssteuerung gesehen, die besonders Motivation und Kreativität freisetzt und damit wichtige Voraussetzungen für die Projektarbeit schafft.« (Nausner 2006, 178) Die vom Scrumprozess geforderte Führungsart wird hier nochmals in anderen Worten umschrieben. Das Ergebnis des Empowerments wird ebenfalls geschildert. Motivation und Kreativität werden freigesetzt. Damit zeigt sich wiederum, dass die Führung eines Game-Studios durch Scrum die Möglichkeit besitzt, das Team in den Mittelpunkt zu stellen und zu fördern, um motiviertere WissensarbeiterInnen ein kreativeres Produkt erstellen zu lassen. Dazu wird eine passende Form des Managements gesucht.

Scrum | Die Erfolgsmethode - Conclusio

71

»Die wesentliche Funktion des Managements besteht darin, Wissen produktiv zu machen. Mit anderen Worten: Management ist eine soziale Funktion. Und in seiner Praxis ist das Management tatsächlich eine ‘freie Kunst’.« (Drucker 2001, 361) Dieses Management wird ebenfalls im Scrumprozess eingefordert. Das Wissen der WissensarbeiterInnen des Scrum-Teams wird durch die Verantwortung bzw. durch das Empowerment in Scrum gefördert und frei gemacht. Der/die ManagerIn kann sich durch die Verwendung von Scrum diesen Effekt zu nutze machen und ein produktives, kreatives Team entstehen lassen. Diese Herangehensweise ist natürlich auf den ersten Blick riskant. Der Product Owner und der ScrumMaster geben Aufgaben, welche zuvor noch in der Zuständigkeit der Führungsebene gelegen sind, an das Scrum-Team ab. Dies benötigt natürlich viel Vertrauen, aber wie bereits beschrieben wurde, entstehen keine Risiken beim Schenken von Vertrauen, sondern sie sind durch das Projekt als solches bereits vorhanden. Dies bedeutet natürlich auch, dass man als ScrumMaster und Product Owner Fehler akzeptieren lernen muss. Der Scrumprozess bietet mit seinem Review und der Retrospective immer nach einem Sprint die Möglichkeit, Fehler zu lokalisieren und zu erkennen. Daher können diese zwar entstehen, aber werden auf Grund des iterativen Scrumprozesses leicht entdeckt. Somit kann sofort im Sprint Planning 1 und 2 auf die entstandenen Fehler eingegangen werden. Durch diese schnelle Fehlererkennung kommt es zu weniger Misstrauen dem/der MitarbeiterIn gegenüber und es kann trotzdem weiterhin Vertrauen geschenkt werden. »Führungspersönlichkeiten erzeugen fehlerfreundliche Kulturen. [...] Eine fehlertolerante und verurteilungsfreie Kultur bedeutet nicht, nachlässige Arbeit zu tolerieren. Oder Verantwortung kleinzuschreiben. Im Gegenteil. Prinzip Verantwortung: Die Mitarbeiter sind so engagiert, dass sie alles riskieren ... Und große Fehler machen, um ihre Ziele zu erreichen.« (Peters 2008, 36)

Durch den Scrumprozesses werden natürlich keine Fehler verhindert, aber der Umgang mit ihnen wird transparenter und einfacher gestaltet. Somit fördert der ScrumMaster sein Team und stärkt es bei dem Versuch, mutig zu sein, um ein exzellentes Game zu schaffen.

Scrum | Die Erfolgsmethode - Conclusio

72

Zusammenfassend beschreibt Drucker fasst alle Funktionen des Scrumprozesses, welche förderlich für das Team sind, in seiner Definition von modernen ManagerInnen: »Sie alle führen Menschen mit unterschiedlichen Kenntnissen zusammen, um gemeinsam Ergebnisse zu erzielen. Sie alle haben die Aufgabe, die Stärken der Menschen für Leistungen zu nutzen und den Schwächen der Menschen ihre Bedeutung zu nehmen. Sie alle müssen klären, was in ihrer Organisation als ‘Ergebnis’ zu betrachten ist, um ausgehend davon die Ziele festzulegen. Alle sind sie dafür verantwortlich, die ‘Geschäftstheorie’ zu formulieren, das heißt die Annahmen, auf denen die Leistungen und die Aktivitäten der Organisation beruhen, sowie die Annahmen, von denen die Organisation bei der Entscheidung über ihr Vorgehen ausgeht. Alle müssen sie die Werte, die Belohnungssysteme und die Strafen ihrer Organisation festlegen, womit sie auch über deren Geist und die Kultur entscheiden. In allen Organisationen müssen die Manager sowohl mit dem Management als Arbeit und als Disziplin, als auch mit der Organisation, deren Vorhaben und Werten, deren Umwelt und Märkten sowie deren Kernkompetenzen vertraut sein.« (Drucker 2001, 360) Der ScrumMaster übernimmt bei einer Gameproduktion eine organisatorische und vor allem schützende Rolle. Er ist am ehesten mit dem/der klassischen ManagerIn zu vergleichen. Allerdings erstellt er nicht mehr die Pläne selbstständig, sondern unterstützt das Team dabei, die Pläne selbst zu erstellen. Wie wir bereits wissen, hält der ScrumMaster den Scrumprozess aufrecht und schafft Impediments aus dem Weg. Damit stellt er die, vom agilen Manifest geforderte, arbeitsfördernde Umgebung für das Team sicher. Die Aufgabe des/der ManagerIn ist auch hier wiederum vom befehlenden Vorgesetzten zum dienenden Beschützer umgekrempelt worden. Scrum stellt damit sicher, dass sich das Team wohl fühlt und sich auf seine eigentliche Arbeit konzentrieren kann: Das produzieren eines Games. Somit ist die Führung wiederum für das Scrum-Team verantwortlich und fördert es genau, so wie es Drucker in seiner Management-Definiton verlangt hat. Es hilft den WissenarbeiterInnen ihre Stärken in Leistung umzusetzen und versucht, ihre Schwächen und Probleme klein zu halten, um sich besser auf die Produktion des Games konzentrieren zu können.

Scrum | Die Erfolgsmethode - Conclusio

73

4.2 DAS TEAM MACHT DAS GAME Es liegt in der Hand des Managements und der Führungsebene, mittels Scrum und den, ihm innewohnenden Ideen, ein gutes Arbeitsklima für die WissensarbeiterInnen und somit das Team zu erzeugen. Die richtige Führung mit Hilfe von Scrum kann also ein gutes Team hervorbringen. Außerdem werden stets im Sprint Planning 1 gemeinsame Ziele und eine Vision an das Scrum-Team vermittelt. Warum ist diese Vermittlung so wichtig? DeMarco und Lister drücken es folgendermaßen aus: Teams »[...] don´t attain goals; people on the teams attain goals. Virtually all of the component tasks required to meet the objective are performed by the individuals who make up the team. Most of this work is done by individuals working alone. There is very little true teamwork required in most of our work. But teams are still important, for they serve as a device to get everyone pulling in the same direction.« (DeMarco/ Lister 1999, 126) Peters betont, dass Teams so heterogen wie möglich sein sollten, da die Diversity in Teams zu mehr Kreativität führt. »Kreativität entspringt ungewöhnlichen Zusammenstellungen. Die wiederum entstehen am ehesten, wenn wir Altersgruppen, Kulturen und Fachgebiete kräftig mischen.«

(Peters 2008, 146)

Solch kreative Hochleistungsteams werden von

Scrum gefördert. Diversität wird bei Scrum nicht als Hindernis betrachtet, es lebt geradezu vom spezialisierten Fachwissen und der Andersartigkeit der Teammitglieder. Teams in Gameprojekten sind nicht nur durch die extremen Spezialisierungen der WissensarbeiterInnen geprägt – ProgrammiererInnen GrafikerInnen, MusikerInnen, GameDesignerInnen und viele Fachgebiete mehr, arbeiten hier Hand in Hand – sie stellen durch den globalisierten Arbeitsmarkt im Game-Business auch bunte Mischungen von Geschlecht, Nationalität und geistiger Haltung dar. Doch egal wie groß die Diversität eines Teams ist, Scrum bietet ein großes Ziel: Die Vision. Es beinhaltet spezielle Meetings, um diese Vision immer wieder zu vermitteln und aufrecht zu halten: Sprint Planning 1 und 2, Sprint Review oder auch das Estimation Meeting. Dadurch trägt Scrum zu einem besser funktionierenden Game bei. Das gemeinsame Ziel und der, den WissensarbeiterInnen Inne wohnende Wunsch, ihre Expertise dazu zu verwenden, diese Ziele zu erreichen und somit der Vision Gestalt zu geben, lässt ein Team zusammenwachsen und sich verstehen. DeMarco und Lister nennen solche Teams »Jelled Teams« – sich verstehende Teams.

Scrum | Die Erfolgsmethode - Conclusio

74

»Once a team begins to jell, the probability of success goes up dramatically. The team can become almost unstoppable, a juggernaut for success. Managing these juggeraut teams is a real pleasure. You spend most of your time just getting obstacles out of their way, clearing the path so that bystanders don´t get trampled underfoot: ,Here they come, folks. Stand back and hold onto your hats.‘ They don´t need to be managed in the traditional sense, and they certainly don´t need to be motivated. They´ve got momentum.« (DeMarco/ Lister 1999, 123) Wenn ein Team zusammenwächst und an einem gemeinsamen Strang zieht, stellt es sich mittels Scrum selbst die Weichen für die Wege der Umsetzung der Aufgaben. Ein gut funktionierendes Team wird sich selbst gewisse Herausforderungen auferlegen, da es nicht nur Arbeiten will bzw. muss, sondern auch die Vision möglichst gut verwirklichen möchte. Diese Herausforderungen spornen wiederum zu gemeinsamen – also als Team erbrachten – Höchstleistungen an. »Good work experiences have always got a fair measure of challenge about them. [...] What´s in the foreground of most of our prized work memories is team interaction. When a group of people fuse into a meaningful whole, the entire character of the work changes. The challenge of the work is important, but not in and of itself; it is important because it gives us something to focus on together. In the best work groups, the ones in which people have the most fun and perform at their upper limits, team interactions are everything. They are the reason that people stick it out, put their all into the work, overcome enormous obstacles.« (DeMarco/ Lister 1999, 121) Das Eingehen auf Diverstiät und die Förderung durch parizipative Führung, lässt den WissensarbeiterInnen und somit dem Team die Möglichkeit, individuell und somit innovativ zu handeln. »Nur individuell handelnde WissensarbeiterInnen ermöglichen tatsächlich individuelle Produkte. Wenn alle machen, ,wie es immer gemacht wurde‘, so wird auch dasselbe (wie immer) herauskommen. Die Markterfordernisse finden also durchaus eine Entsprechung in den Organisationen selbst.«

(Gucher/ Kana 2006, 65)

Scrum fördert

durch das Sprint Planning 2, die selbstorganistorische Planung der Umsetzung der Userstories mittels Tasks, dieses individuelle Handeln. Einem bunt gemischten Team wird dabei Vertrauen geschenkt und die Möglichkeit gegeben, ihren eigenen, kreativen und vor allem professionellen Weg zu gehen. WissensarbeiterInnen können ihre volle Expertise in diesem Meeting einbringen und die Diversitäten des Teams werden in einer Diskussion zu einem neuen und hoffentlich innovativen Weg der Problembewältigung führen. Damit hat das Game die Möglichkeit, besser zu werden, als wenn es nur von einer Person geplant werden würde. Der immense Umfang an Input, welcher durch die

Scrum | Die Erfolgsmethode - Conclusio

75

Time-Box und den ScrumMaster aber immer wieder gebündelt wird, wirken sich positiv auf das Produkt, also das Game aus. Peters drückt dies zusammengefasst so aus: »Vielfalt ist von strategischer Bedeutung für jeden zukünftigen wirtschaftlichen Erfolg, ob auf der Ebene einzelner Unternehmen oder ganzer Nationen.« (Peters 2008, 147) Die Zusammenarbeit der WissensarbeiterInnen unter Scrum führt somit zu großen Innovationen, welche am Markt genutzt werden können und der Organisation, also dem Gamestudio Gewinne einbringen wird. Um diese kreativen Potenziale zu nutzen, bedarf es steter Arbeit des ScrumMasters am Klima des Teams. Scrum arbeitet durch seine regulierenden Funktionen diesem Effekt sozusagen zu. »Wenn wir diese Herausforderung meistern wollen, müssen wir verstehen, was die Basis des Erfolges unter komplexen Vorgaben ausmacht: eine kooperative, soziale Interaktion zwischen allen Beteiligten, die sie befähigt, gemeinsam immer neue Lösungen für Probleme zu entwickeln.« (Gucher 2011, 3) Natürlich wird bei dieser Vielfalt an Input und der allgemeinen Heterogenität des Teams immer wieder die Frage der Professionalität gestellt. Scrum-Teams für Games entsprechen nicht immer dem üblichen Bild eines/einer Büroangestellten. Die Andersartigkeit wird hochgehalten und sogar zelebriert. Scrum lässt sich darauf ein und zieht, wie bereits beschrieben Positives daraus. Um das Team zu unterstützen, dürfen dafür aber keine »Grauen Mäuse« im Management sitzen (Vgl. Noll/ Bachmann 2007, 36ff) Teams werden in Scrum vor allem durch offene und verständnisvolle Manager profitieren und somit ein besseres Game erzeugen. »The insiders in question – typically second- and third-level managers with shaky selfconfidence – are uncomfortable with any kind of behavior that is different from average. They need to impose safely homogenized mores on those beneath them to demonstrate that they are in a charge. The term unprofessional is often used to characterize surprising and threatening behavior. Anything that upsets the weak manager is almost by definition unprofessional. So popcorn is unprofessional. Long hair is unprofessional if it grows out of a male head, but perfectly okay if it grows out of a female head. Posters of any kind are unprofessional. Comfortable shoes are unprofessional. Dancing around your desk when something good happens is unprofessional. Giggling and laughing is unprofessional. (It‘s all right to smile, but not too often.) Conversely, professional means unsuprising. You will be considered professional to the extent you look, act, and think like everyone else, a perfect drone. Of course, this perverted sense of professionalism is pathological. In a healthier organizational culture, people are thought professional to the extent they are knowledgeable and competent.« (DeMarco/ Lister 1999, 98f)

Scrum | Die Erfolgsmethode - Conclusio

76

Dadurch, dass bei Scrum eben nicht Professionalität mit Unauffällig gleichgestellt wird, werden die Teams besser und können bessere Games produzieren. »Bessere Games«, bedeutet hier allerdings eine gesteigerte Effektivität und nicht eine gesteigerte Effizienz. »Effizienz bedeutet, alles gleich machen zu wollen, dafür aber schneller (gleicher also) im Verhältnis zu anderen, Effektivität bedeutet, alles anders machen zu wollen, dafür aber mit anderen gemeinsam. Der Lustgewinn bei Effektivität ist also die gemeinsame Produktion, nicht das Gegeneinander der Effizienz.« (Gucher/ Kana 2006, 87) Scrum fördert diese Sicht der Dinge durch das ständige Plädoyer an die TimeBox der Meetings und die Unumstößlichkeit des Sprints. Dabei wird, wie bereits erwähnt, gefordert die Länge der Meetings nie zu überschreiten und die Inhalte des Sprint Backlogs niemals während des Sprints zu ändern oder ihn zu verlängern. Es schult die WissensarbeiterInnen in Effektivität und lässt das Effizienzstreben außen vor. Dies basiert auf der einfachen Tatsache, dass WissensarbeiterInnen nicht mehr arbeiten können, als sie arbeiten können. Dieser einfache Gedanke setzt an der Idee an, dass es immer verschiedene Stellräder für eine Maschinerie gibt. Wenn die Menge des Outputs nicht erhöht werden kann, da die WissensarbeiterInnen nicht mehr machen können, sollten sie das was sie machen, dafür so gut und effektiv wie möglich machen. Scrum fördert dieses Verhalten und hilft somit, das Game besser werden zu lassen. »Niemand ist alleine produktiv, jeder muss kooperieren. Wir erfüllen Arbeitsaufgaben zumindest deshalb, weil sie ,zum Job gehören‘. Das ist der niedrigste Grad an (Grund-) Motivation, die von außen, also der Organisation, beeinflusst werden kann, und nicht von innen kommt.« (Gucher 2011, 9) Grundsätzlich ist die Erledigung der Arbeit eine Frage der Motivation. Wie bereits mehrfach geschildert, bietet Scrum den WissensarbeiterInnen diverse Möglichkeiten produktiv zu sein. Fast alle dieser Möglichkeiten zielen darauf ab, den/die WissenarbeiterIn seinen/ ihren inneren Trieb nach Erfüllung in seinem/ihrem Spezialgebiet nachzukommen. Einfach nur den eigenen Job zu machen, weil »es halt sein muss«, ist dabei nur der kleinste Antrieb. Durch die Verlagerung der Umsetzungsentscheidungen des Games, werden die WissensarbeiterInnen sehr stark in das Game eingebunden und haben die Möglichkeit, sich von ihrer inneren Motivation antreiben zu lassen. Dies geht sogar soweit, dass beim richtigen Einsatz von Scrum der innere Antrieb überwiegen kann und die Antriebe durch das Management als Begleiterscheinung durch den/die WissensarbeiterIn gewertet werden. »WissensarbeiterInnen brauchen nicht motiviert zu werden, sie sind es dann, wenn sie Leistung erbringen können. Die Motivation ist demnach arbeitsimmanent

Scrum | Die Erfolgsmethode - Conclusio

77

vorhanden (intirnsisch motiviert). Sie braucht nicht mehr von außen (dem Management) zugeführt werden.«

(Gucher/ Kana 2006, 61)

Oftmals wird versucht, ein Team oder die

WissensarbeiterInnen aus dem es besteht, ausschließlich durch extrinsische Motivation – also äußere Anreize – zu motivieren. Dabei werden z.B. Zielvorgaben erstellt, welche innerhalb eines gewissen Zeitrahmens erfüllt werden müssen. Diese Methode ist leider noch oft verbreitet und wird »Management by Objectives« genannt. Dabei werden die Leistungen des Teams auf eine, in seltenen Fällen zwei oder drei, messbare Größen reduziert. Oftmals tritt ein großes Problem auf. Denn diese falsche Motivation durch Zielvorgaben, »[...] überlagere die intrinsische Motivation der Mitarbeiter durch künstliche, extrinsische Motivationsanreize. Ein Verkäufer zum Beispiel, der von dem extrinsischen Motivationsanreiz angespornt ist, eine Verkaufsquote zu erfüllen, wird darüber den intrinsischen Motivationsanreiz vergessen, für zufriedene Kunden zu sorgen. Das Ergebnis ist wahrscheinlich ein erhöhter Verkauf kaum benötigter Güter an eine immer kleiner werdende Basis zunehmend desillusionierter Kunden.« (DeMarco 2001, 128) Es ist zwar wichtig, mehrere Anreize und Motivationen für den/die WissensarbeiterIn zu schaffen, aber der Scrumprozess fördert vor allem die intrinsische Motivation durch die Möglichkeit, sich und seine eigene Expertise ausleben zu können. Derart intinsisch motivierte Scrum-Teams sind extrem leistungsfähig und wollen ein gutes Game alleine aus dem Grund der anschließenden Befriedigung erstellen. Dies ist die höchste Form des Antriebs und wird durch den Scrumprozess in jedem Sprint und jedem Meeting wieder erneuert. Nausner hat quantitative Beweise und Studien dazu präsentiert. »Zahlreiche empirische Untersuchungen (Hill/Fehlbaum/Ulrich, 1994) zeigen eine positive Korrelation zwischen Partizipation und Leistung – allerdings abhängig von den aufgabenspezifischen Constraints (Bedingungen). Partizipation in Arbeitsgruppen zeitigt drei für die Projektarbeit elementare Vorteile:

Verbesserung der Kenntnisse und Fähigkeiten der Gruppenmitglieder



(fortlaufende Professionalisierung)



Konstante und selbstmotivierte Leistungsabgaben



Erhöhte Selbstkontrolle (verbesserte Möglichkeiten der Delegantion)«



(Nausner 2006, 181)

Zusammenfassend kann festgestellt werden, dass viele Methoden und Funktionen in Scrum das Team in den Mittelpunkt des Prozesses stellen. Damit kann die Führung versuchen, durch Scrum die intrinsische Motivation des Teams zu steigern, um es

Scrum | Die Erfolgsmethode - Conclusio

78

zu einer höheren Effektivität zu führen. Diese Effektivität sollte helfen, am Ende des Projekts ein qualitativ hochwertiges Game entwickelt und produziert zu haben. Damit wurde in dieser Arbeit ausführlich erläutert, warum und wie Scrum das Team in den Mittelpunkt der Gameentwicklung stellt und es wurde auch auf die Vielzahl der Vorteile eingegangen, die sich durch eine solche Herangehensweise und Management-Methodik ergeben.

Literatur

79

QUELLENVERZEICHNIS | LITERATUR Assmann, Aleida (2011): Einführung in die Kulturwissenschaft. Grundbegriffe, Themen, Fragestellungen. 3., neu bearb. Aufl. Berlin: Erich Schmidt Verlag GmbH. Blanchard, Ken/ Miller, Mark (2004): The Secret. What Great Leaders Know and Do. San Francisco: Berrett-Koehler Publishers. DeMarco, Tom (2001): Spielräume. Projektmanagement jenseits von Burn-out, Stress und Effizienzwahn. München: Carl Hanser Verlag. DeMarco, Tom (2003): Bärentango. Mit Risikomanagement Projekte zum Erfolg führen. München: Carl Hanser Verlag. DeMarco, Tom/ Lister, Timothy (1999): Peopleware. Productive Projects and Teams. 2. Aufl. New York: Dorset House Publishing Co. Drucker, Peter (2001): Was ist Management? Das Beste aus 50 Jahren. München: Econ Ullstein List Verlag GmbH & Co. EDGE. The future of interactive entertainment (2012): Laura Fryer. Ausg. April 2012. Bath: Future Publishing Limited. Gardenswartz, Lee/ Rowe, Anita, (2010): Managing Diversity: A Complete Desk Reference & Planning Guide, 3. Auflg., Alexandria: SHRM. Gay, Friedbert (2004): Das DISG Persönlichkeits-Profil. Persönliche Stärke ist kein Zufall. Remchingen: persolog GmbH Verlag für Managementsysteme. Glaser, Robert (1996): Changing the agency for learning. Acquiring expert performance. New Jersey: Mahwah. Gloger, Boris (2009): Scrum. Produkte zuverlässig und schnell entwickeln. 2. Aufl., München: Carl Hanser Verlag.

Literatur

80

Gloger, Boris (2010): Scrum Checklist 2010. Your Scrum Checklist. Wien: o.A. Greenleaf, Robert (2003): The Servant-Leader Within. A Transformative Path. Mahwah: Paulist Press. Gucher, Jeanny (2011): 4dimensions. Soziale Produktivität managen. Wien: o.A. Gucher, Jeanny/ Kana, Robert (2006): The Pentagonchallenge. Das Management des Ausnahmezustands. Wien: MANZsche Verlags- und Universitätsbuchhandlung GmbH. Hight, John/ Novak, Jeannie (2008): Game Development Essentials. Game Project Management. Clifton Park: Thomas Delmar Learning. Keith, Clinton (2010): Agile Game Development with Scrum. Boston: Pearson Education, Inc. Köppel, Petra (2007): Konflikte und Synergien in multikulturellen Teams. Wiesbaden: Deutscher Universitäts-Verlag. Krell, Gertraud/ Wächter, Hartmut (Hrsg.) (2006): Diversity Management. Impulse aus der Personalforschung. München: Rainer Hampp Verlag. Machiavelli, Niccoló (2004): Il Principe. Der Fürst. Stuttgart: Reclam. Malik, Friedmund (2005): Führen Leisten Leben.Wirksames Management für eine neue Zeit. München: Heyne. McCarthy, David/ Curran, Ste/ Byron, Simon (2005): The Art of Producing Games. Boston: Course PTR. Mor Barak, Michálle (2011): Managing Diversity. Toward a Globally Inclusive Workplace. Thousand Oaks: SAGE Publications, Inc. Nausner, Peter (2006): Projektmanagement. Die Entwicklung und Produktion des Neuen in form von Projekten. Wien: Facultas Verlags- und Buchhandels AG.

Literatur

81

Noll, Peter/ Bachmann, Hans Rudolf (2007): Der kleine Machiavelli. Handbuch der Macht für den alltäglichen Gebrauch. München: Piper Verlag GmbH. Patzak, Gerold/ Rattay, Günter (2004): Projektmanagement. 4., wesentlich überab. Aufl. Wien: Linde Verlag. Peters, Tom (2008): Führung. Offenbach: GABAL Verlag GmbH. Pichler, Roman (2008): Scrum. Agiles Projektmanagement erfolgreich einsetzen. Heidelberg: dpunkt.verlag GmbH. Schimmel-Schloo, Maritna/ Seiwert, Lothar/ Wagner, Hardy (Hrsg.) (2002): Persönlichkeits Modelle. Offenbach: Gabal Verlag GmbH. Schumacher, R./ Czerwinski, Mary (1992): Mental models and the acquisition of expert knowledge. New York: Springer-Verlag. Sprenger, Reinhard (2007): Vertrauen führt. Worauf es im Unternehmen wirklich ankommt. 3., durchgesehene Aufl. Frankfurt a. M.: Campus Verlag GmbH. Stuber, Michael (2004): Diversity. Das Potenzial von Vielfalt nutzen - den Erfolg durch Offenheit steigern. München: Wolters Kluwer Deutschland GmbH. Taylor, Frederick (2004): Die Grundsätze wissenschaftlicher Betriebsführung. Nachdruck der Ausg. München, Oldenbourg, 1913. Düsseldorf: VDM. Thom, Norbert (1980): Grundlagen des betrieblichen Innovationsmanagements, 2. Aufl., Königstein/Ts. Wirdemann, Ralf (2009): Scrum mit User Stories. München: Carl Hanser Verlag.

Literatur

82

QUELLENVERZEICHNIS | ONLINE inno Nord GmbH (2007): Innovationsförderung. www.gtz.info/information/Download/ Barthel/, abgerufen am 20.10.2011. Mai, Jochen (2011): Tuckmanns vier Phasen - Wie Teambildung gelingt. http:// karrierebibel.de/tuckmans-vier-phasen-wie-teambildung-gelingt/,

abgerufen

am

14.03.2012. Royce, Winston (1970): Managing the Development of large Softwaresystems. http:// www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf/,

abgerufen

am

16.04.2012. Scrum Community Wiki (2012): Firms Using Scrum. https://docs.google.com/ spreadsheet/ccc?key=0AgfBeuoRfUzNdDlMNG82SlhmUVRhOEk0REtrdmthNWc# gid=0, abgerufen am 24.04.2012. Scrum Kompakt (2012): Wasserfall-Modell. http://www.scrum-kompakt.de/grundlagendes-projektmanagements/wasserfall-modell/, abgerufen am 12.04.2012 ScrumAlliance (o.J.): Scrum is an innovative approach to getting work done. http:// www.scrumalliance.org/learn_about_scrum, abgerufen am 07.03.2012. The Numbers (2012): US Movie Market Summary 1995 to 2012. http://www.thenumbers.com/market/, abgerufen 24.04.2012. TWC (2009): Methoden der Innovationsbewertung. http://www.tcw.de/news/ methoden-der-innovationsbewertung-483, abgerufen am 13.02.2012. Video Game Sales Wiki (o.J.): Video game industry. Comparison with other forms of entertainment. http://vgsales.wikia.com/wiki/Video_game_industry, abgerufen am 24.04.2012. Ward Cunningham (2001): Manifest für agile Softwareentwicklung. http://www. agilemanifesto.org/iso/de/, abgerufen am 16.04.2012. Wikipedia (2012): Taylorismus. http://de.wikipedia.org/wiki/Taylorismus, abgerufen am 16.04.2012.

A

ANHANG

Anhang

A1

WERK | DON'T DROP! Als begleitendes Werk zu dieser Masterthesis wurde die Erstellung eines Serious Games für iPhone und Android mittels Scrum gemanagt. Der Titel des Games ist Don´t Drop! und es soll auf spielerische Art und Weise Bauarbeitern die Wichtigkeit von korrekter Höhensicherung am Bau vermittelt werden. Das Game wurde in mehreren Phasen ca. 10 Monate intensiv im Rahmen der FH Salzburg, als Projekt der Studiengänge MultiMedia Art und MultiMedia Technology, entwickelt. Ein Großteil der Projektzeit wurde das Team erfolgreich mit Scrum geführt. Don´t Drop! wurde als Best Practice Beispiel bei der Zukunftstudie work:design. Die Zukunft der Arbeit gestalten. des Zukunftsinstituts um Matthias Horx ausführlich beschrieben. Natürlich ist die Verwendung von Scrum nicht der einzige Grund, wesewegen das Spiel so erfolgreich wurde, aber es hat mit Sicherheit einen Beitrag dazu geleistet.

Team

Stefan Randelshofer | ScrumMaster



Ivana Müller | 3D-Artist



Doris Wimmer | 2D-Artist



Alexander Cerny | Programmierer



Philipp Huber | Programmierer



Martin Klappacher | Programmierer



Josef Schinwald | GameDesigner



Roland Haagen | Auftraggeber

Auftraggeber

Alpine Bau GmbH



Skylotec



Palfinger



Doka

Anhang

A2

Beschreibung des Games in iTunes In Don´t Drop! übernimmst du die Rolle eines Generalunternehmers. Du nimmst diverse Bauaufträge an und kümmerst dich um die Sicherheit deiner Bauarbeiter. Denn nur durch entsprechendes Sichern und die Wahl richtiger Ausrüstung sind Erfolg und Gewinne möglich. Du baust eine Fußball Arena ebenso, wie eine Staumauer oder eine riesige Brücke. Pass auf deine Arbeiter auf, denn sie sind dein Kapital. Jeder Absturz kostet dich richtig Geld. Je weniger Unfälle deine Arbeiter haben, desto schneller hast du dein Projekt fertig gebaut. Das Spiel hat viele abwechslungsreiche Levels und eine Vielzahl an Herausforderungen. Entwickelt wurde dieses Game durch den MediaCube (Studiengänge MultimediaArt und MultimediaTechnology der Fachhochschule Salzburg). Das Edutainment Spiel Don`t Drop! soll zur Steigerung der Awareness in Hinsicht auf Sicherheit am Bau beitragen und die Notwendigkeit eines konsequenten Sicherns bei der Arbeit aufzeigen.


Features

- 8 Level von großartigen, realen Gebäuden auf der ganzen Welt, mit wachsenden Baustadien
 - 6 moderne Sicherungstypen, mit unterschiedlichen Eigenschaften zum effektivem Einsatz am Bau




- Einen Stellenmarkt, zum Anheuern neuer Arbeitskräfte




- Level-System der Bauarbeiter vom Lehrling über Gesellen zum Meister,



mit entsprechend variierten Arbeitseigenschaften
 - Ragdollsystem zur realistischen Darstellung der Abstürze ungesicherter Bauarbeiter
 - Ausführliche Endabrechnung und Verletzungsanalyse der Unfälle