Einführung des Scrum Frameworks für ein IT-Unternehmen aus Thailand

Master's Thesis , 2011 , 103 Pages , Grade: 1,3

Computer Science - Commercial Information Technology

Scrum gehört zu den agilen Projektmanagementmethoden und es bedarf eines Umdenkens seitens von Kunden und Management. Anders als bei klassischen Methoden, wird in Scrum auf selbstorganisierte Teams und flache Hierarchien
großen Wert gelegt. Die Masterarbeit konzentriert sich auf die Einführung von Scrum in ein thailändisches IT-Unternehmen. Hierbei wurden kulturelle, organisatorische und technische Aspekte mit Hilfe des Problemlösungszyklus analysiert und Ziele
definiert. Anschließend sind Lösungen nach Scrum und alternative Ansätze evaluiert worden. Für eine Bewertung wurden die drei Faktoren Kosten, Zeit und Risiko mit Punkten gewichtet um die Lösungen später im Maßnahmenkatalog vergleichen zu
können. Als Ergebnis kam heraus, dass die zuvor definierten Ziele mit minimalen Anforderungen aus dem Scrum Framework umgesetzt werden können. Zusätzlich ist ein maximaler Lösungsansatz in Betracht gezogen worden. Hierbei tragen alternative Lösungsansätze dazu bei, Scrum als Ganzes zu adaptieren und unterstützen die Umsetzung.

ABSTRACT [ENGLISH ]
Scrum is one of the agile project management methods and requires a rethinking of customers and management. Unlike classical methods, Scrum set great values on self-organized teams and flat hierarchies. This master thesis focuses on
implementing the Scrum Framework for an IT company in Thailand. On this occasion, cultural, organizational and technical aspects were analyzed using the problem solving cycle and objectives defined. Afterwards solutions to Scrum and alternative approaches have been evaluated. For an assessment, weighted points were categorized in three factors of cost, time and risk to compare the solutions later in the action plan. As a result, it was revealed that the previously defined goals can be implemented with the minimum requirements of the Scrum framework. In addition, a maximum approach has been considered. Regarding to this, alternative approaches help to adapt Scrum as a whole and support the implementation.

Inhaltsverzeichnis

ABBILDUNGSVERZEICHNIS

ABKÜRZUNGSVERZEICHNIS

TABELLENVERZEICHNIS

FORMELVERZEICHNIS

1 ZIEL DER MASTERARBEIT

2 IST SITUATION
2.1 TÄTIGKEIT DES UNTERNEHMENS
2.2 UNTERNEHMENS HINTERGRUND
2.2.1 Mitarbeiter Feedback
2.2.2 Management Feedback
2.3 PROJEKTPROZESS UND ORGANISATIONSSTRUKTUR
2.4 PROJEKTARTEN
2.5 ARBEITSKULTUR THAILAND
2.6 SCHWACHSTELLEN ANALYSE

3 SOLL ZUSTAND

4 DAS SCRUM FRAMEWORK
4.1 EINFÜHRUNG
4.2 SCRUM FLOW
4.3 SCRUM ROLLEN
4.3.1 Der Product Owner
4.3.2 Der Scrum Master
4.3.3 Das Scrum Team

5 ANSÄTZE NACH SCRUM UND ALTERNATIVE LÖSUNGSANSÄTZE
5.1 ZIEL KLASSE: PROZESS
5.1.1 Scrum Framework einführen
5.1.1.1 Schulung von Scrum
5.1.1.2 Kickoff Meeting
5.1.1.3 Das erste Scrum Projekt
5.1.1.4 Rollenverteilung
5.1.2 Maßnahmenkatalog: Scrum Framework einführen
5.2 ZIEL KLASSE: TEAM
5.2.1 Teambildung & Selbstorganisation
5.2.1.1 Ansatz nach Scrum: Selbstorganisation
5.2.1.2 Analyse zur Teambildung
5.2.1.3 Alternativer Lösungsansatz: Maßnahmen zur Teamanalyse nach Lencioni
5.2.1.4 Alternativer Lösungsansatz: Rahmenbedingungen schaffen
5.2.1.5 Alternativer Lösungsansatz: Gruppenaktivitäten
5.2.2 Maßnahmenkatalog: Teambildung & Selbstorganisation
5.2.3 Kontinuierliche Verbesserung der Entwicklung
5.2.3.1 Ansatz nach Scrum: Retrospektive
5.2.3.2 Alternativer Lösungsansatz: Schulungen durchführen
5.2.3.3 Alternativer Lösungsansatz: Coding Dojos
5.2.4 Maßnahmenkatalog: Kontinuierliche Verbesserung der Entwicklung
5.3 ZIEL KLASSE: PROJEKTE
5.3.1 Spezifikationen eindeutig und verständlich kommunizieren
5.3.1.1 Ansatz nach Scrum: User Stories
5.3.1.2 Alternativer Lösungsansatz: Unified Modelling Language (UML)
5.3.1.3 Alternativer Lösungsansatz: Wireframes & Mockups
5.3.1.4 Alternativer Lösungsansatz: Screenshots
5.3.1.5 Alternativer Lösungsansatz: Sitemaps
5.3.1.6 Maßnahmenkatalog: Spezifikationen eindeutig und verständlich kommunizieren
5.3.2 Methode für genauere Aufwandsschätzungen verwenden
5.3.2.1 Ansatz nach Scrum: Story Points mit Planning Poker
5.3.2.2 Alternativer Lösungsansatz: Einzelschätzung
5.3.2.3 Alternativer Lösungsansatz: Delphi-Methode
5.3.2.4 Alternativer Lösungsansatz: Best Practice
5.3.2.5 Alternativer Lösungsansatz: Dreipunktverfahren
5.3.2.6 Maßnahmenkatalog: Methode für genauere Aufwandsschätzung
5.3.3 Projektcontrolling einführen und verwenden
5.3.3.1 Ansatz nach Scrum: Burndown Chart
5.3.3.2 Alternativer Lösungsansatz: Earned Value Methode
5.3.3.3 Alternativer Lösungsansatz: Meilenstein-Trendanalyse
5.3.3.4 Alternativer Lösungsansatz: Gantt Diagramm
5.3.3.5 Maßnahmenkatalog: Projektcontrolling einführen und verwenden
5.3.4 Gesamtüberblick über einzelne und alle Projekte ermöglichen
5.3.4.1 Ansatz nach Scrum: Das Taskboard
5.3.4.2 Alternativer Lösungsansatz: Gesamtüberblick mit Excel Tabelle
5.3.4.3 Alternativer Lösungsansatz: Basecamp Erweiterung
5.3.4.4 Maßnahmenkatalog: Gesamtüberblick über einzelne und alle Projekte ermöglichen

6 EVALUATION
6.1 MINIMALE LÖSUNG
6.1.1 Ziel Klasse: Prozess:
6.1.1.1 Scrum Framework einführen
6.1.2 Ziel Klasse: Team
6.1.2.1 Teambildung & Selbstorganisation
6.1.2.2 Kontinuierliche Verbesserung der Entwicklung
6.1.3 Ziel Klasse: Projekte
6.1.3.1 Spezifikationen eindeutig und verständlich kommunizieren
6.1.3.2 Methode für genauere Aufwandsschätzung
6.1.3.3 Projektcontrolling einführen und verwenden
6.1.3.4 Gesamtüberblick über einzelne und alle Projekte ermöglichen
6.1.4 Zusammenfassung Minimale Lösung
6.2 MAXIMALE LÖSUNG
6.2.1 Ziel Klasse: Prozess:
6.2.1.1 Scrum Framework einführen
6.2.2 Ziel Klasse: Team
6.2.2.1 Teambildung & Selbstorganisation
6.2.2.2 Kontinuierliche Verbesserung der Entwicklung
6.2.3 Ziel Klasse: Projekte
6.2.3.1 Spezifikationen eindeutig und verständlich kommunizieren
6.2.3.2 Methode für genauere Aufwandsschätzung
6.2.3.3 Projektcontrolling einführen und verwenden
6.2.3.4 Gesamtüberblick über einzelne und alle Projekte ermöglichen
6.2.4 Zusammenfassung Maximale Lösung
6.3 SCHLUSSFOLGERUNG

7 LITERATURVERZEICHNIS

University of Applied Sciences Munich Fakultät für Elektrotechnik und Informationstechnik

Kurzfassung

Scrum gehört zu den agilen Projektmanagementmethoden und es bedarf eines Umdenkens seitens von Kunden und Management. Anders als bei klassischen Methoden, wird in Scrum auf selbstorganisierte Teams und flache Hierarchien großen Wert gelegt. Die Masterarbeit konzentriert sich auf die Einführung von Scrum in ein thailändisches IT-Unternehmen. Hierbei wurden kulturelle, organisatorische und technische Aspekte mit Hilfe des Problemlösungszyklus analysiert und Ziele definiert. Anschließend sind Lösungen nach Scrum und alternative Ansätze evaluiert worden. Für eine Bewertung wurden die drei Faktoren Kosten, Zeit und Risiko mit Punkten gewichtet um die Lösungen später im Maßnahmenkatalog vergleichen zu können. Als Ergebnis kam heraus, dass die zuvor definierten Ziele mit minimalen Anforderungen aus dem Scrum Framework umgesetzt werden können. Zusätzlich ist ein maximaler Lösungsansatz in Betracht gezogen worden. Hierbei tragen alternative Lösungsansätze dazu bei, Scrum als Ganzes zu adaptieren und unterstützen die Umsetzung.

Abstract

Scrum is one of the agile project management methods and requires a rethinking of customers and management. Unlike classical methods, Scrum set great values on self-organized teams and flat hierarchies. This master thesis focuses on implementing the Scrum Framework for an IT company in Thailand. On this occasion, cultural, organizational and technical aspects were analyzed using the problem solving cycle and objectives defined. Afterwards solutions to Scrum and alternative approaches have been evaluated. For an assessment, weighted points were categorized in three factors of cost, time and risk to compare the solutions later in the action plan. As a result, it was revealed that the previously defined goals can be implemented with the minimum requirements of the Scrum framework. In addition, a maximum approach has been considered. Regarding to this, alternative approaches help to adapt Scrum as a whole and support the implementation.

Abbildungsverzeichnis

Abbildung 1: Organigramm

Abbildung 2: IST-Projektprozess (vereinfacht)

Abbildung 3: Ishikawa-Diagramm

Abbildung 4: Scrum Flow (Deemer, et al., 2009, S. 5)

Abbildung 5: Scrum mit Deming Cycle

Abbildung 6: Modell der Funktionsstörung eines Teams (Lencioni, 2002, S. 188) . 26

Abbildung 7: Retrospektiven Brücke (Davies und Sedley, Agile Coaching, 2009, S. 193)

Abbildung 8: Retrospektive mit Flipcharts

Abbildung 9: Retrospektive Zeitleiste

Abbildung 10: Retrospektiv Seismograf (Davies und Sedley, Agile Coaching, 2009, S. 197)

Abbildung 11: Klassendiagramm Beispiel (Balzert, UML Kompakt mit Checklisten, 2001, S. 19)

Abbildung 12: Beispiel Use Case Diagramm Web (Carr und Meehan, 2005)

Abbildung 13: Beispiel Sequenzdiagramm (Informatik Forum Simon GmbH, o. J. a.)

Abbildung 14: Beispiel Wireframe Software (Initiative Mittelstand, Huber Verlag für Neue Medien GmbH, o. J. a.)

Abbildung 15: Beispiel Spezifikation anhand von Screenshots

Abbildung 16: Beispiel Sitemap

Abbildung 17: Burndown Chart Velocity

Abbildung 18: Burndown Chart - Linear Trend

Abbildung 19: Beispiel Burndown mit MS Excel

Abbildung 20: Earned Value Methode in Anlehnung an Gubbels (vgl. Gubbels, 2009, S. 34)

Abbildung 21: Earned Value Methode mit Excel (vgl. Microsoft Corporation, o. J. a.)

Abbildung 22: Meilenstein-Trendanalyse nach Fleig (vgl. Dr. Fleig, 2007)

Abbildung 23: Beispiel AgileAgenda (vgl. Agile Agenda, o. J. b.)

Abbildung 24: Taskboard im Daily Meeting

Abbildung 25: Beispiel Taskboard

Abbildung 26: Beispiel Erweitertes Taskboard

Abbildung 27: Beispiel Basecamp unassigned tasks

Abbildung 28: Beispiel Projekt- und Taskübersicht in Excel

Abbildung 29: Roadmap Software - Projektübersicht

Abbildung 30: Roadmap Software - erweiterte Projektübersicht

Abbildung 31: Basecamp Viewer - Gesamtprojektübersicht

Abbildung 32: Basecamp Viewer - Meilenstein Ansicht

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Tabellenverzeichnis

Tabelle 1: Projektarten

Tabelle 2: Zielkatalog

Tabelle 3: Gewichtung Kosten

Tabelle 4: Gewichtung Zeit

Tabelle 5: Gewichtung Risiko

Tabelle 6: Maßnahmenkatalog - Scrum Framework einführen

Tabelle 7: Analysebogen nach Lencioni (vgl. Lencioni, 2002, S. 192 - 193)

Tabelle 8: Auswertungstabelle nach Lencioni (vgl. Lencioni, 2002, S. 194)

Tabelle 9: Maßnahmenkatalog - Teambildung & Selbstorganisation

Tabelle 10: Maßnahmenkatalog - Kontinuierliche Verbesserung der Entwicklung

Tabelle 11: Maßnahmenkatalog - Spezifikationen eindeutig und verständlich kommunizieren

Tabelle 12: Maßnahmenkatalog - Methode für genauere Aufwandsschätzung

Tabelle 13: Maßnahmenkatalog - Projektcontrolling einführen und verwenden

Tabelle 14: Maßnahmenkatalog - Gesamtüberblick über einzelne und alle Projekte ermöglichen

Tabelle 15: Minimale Lösung - Scrum Framework einführen

Tabelle 16: Minimale Lösung - Teambildung & Selbstorganisation

Tabelle 17: Minimale Lösung - Kontinuierliche Verbesserung der Entwicklung

Tabelle 18: Minimale Lösung - Spezifikationen eindeutig und verständlich kommunizieren

Tabelle 19: Minimale Lösung - Methode für genaue Aufwandsschätzung

Tabelle 20: Minimale Lösung - Projektcontrolling einführen und verwenden

Tabelle 21: Minimale Lösung - Gesamtüberblick über einzelne und alle Projekte ermöglichen

Tabelle 22: Zusammenfassung Minimale Lösung

Tabelle 23: Maximale Lösung - Scrum Framework einführen

Tabelle 24: Maximale Lösung - Teambildung & Selbstorganisation

Tabelle 25: Maximale Lösung - Kontinuierliche Verbesserung der Entwicklung

Tabelle 26: Maximale Lösung - Spezifikationen eindeutig und verständlich kommunizieren

Tabelle 27: Maximale Lösung - Methode für genaue Aufwandsschätzung

Tabelle 28: Maximale Lösung - Projektcontrolling einführen und verwenden

Tabelle 29: Maximale Lösung - Gesamtüberblick über einzelne und alle Projekte ermöglichen

Tabelle 30: Zusammenfassung Maximale Lösung

Formelverzeichnis

Formel 1: Dreipunktverfahren

Formel 2: geplanter Trend

1 Ziel der Masterarbeit

Im Rahmen eines siebenmonatigen Vollzeit-Angestelltenverhältnisses als Projektmanager in einem thailändischen IT Unternehmen, ist das Ziel dieser Masterarbeit, ein Konzept der Einführung des Scrum Frameworks mit Hilfe des Problemlösungszyklus nach der Systems Engineering Methode zu erarbeiten.

Hierbei wird auf Lösungsansätze nach Scrum eingegangen und es wird versucht mögliche Alternativen aufzuzeigen. Im Anschluss darauf sollen die verschiedenen Lösungsvarianten bewertet werden.

2 Ist Situation

In diesem Kapitel wird auf die aktuelle Situation des Unternehmens eingegangen und beschreibt damit die Ausgangssituation für diese Masterarbeit und bildet die Basis für Lösungsansätze nach Scrum und anderen Lösungsalternativen.

Einleitend wird hier in Punkt zwei der Hintergrund des Unternehmens erwähnt, da der jetzige Zustand der Firma darauf aufbaut.

2.1 Tätigkeit des Unternehmens

Das IT Unternehmen mit dem Standort Bangkok in Thailand konzentriert sich auf die Erstellung und Gestaltung von Webseiten mit dem Content Management System (CMS) Typo3 und Hosting bzw. bereitstellen von Servern. Aufträge kommen hauptsächlich von Agenturen und Unternehmen aus der Schweiz und Deutschland. In Planung ist, thailändische Firmen ebenfalls zu bedienen.

2.2 Unternehmens Hintergrund

In der Vergangenheit gab es Schwierigkeiten und Hürden die sich zum Teil bis heute nachziehen. Im Folgenden werden diese erläutert.

2.2.1 Mitarbeiter Feedback

Der Projektmanager wurde nicht von den Mitarbeitern akzeptiert und respektiert. Nach einzelnen Mitarbeitergesprächen tauchten zunehmend die gleichen Gründe auf:

Mittelmäßige Programmierkenntnisse des Projektmanagers (vgl. Senior Developer 1, 2010).

Projektmanager wendet keine Projektmanagement Methoden an (vgl. Senior Developer 2, 2010).

Mitarbeiter werden in den Projektprozess nicht eingebunden (vgl. Senior Developer 2, 2010).

Arbeitspaket Schätzungen werden von dem Projektmanagement willkürlich gestellt (vgl. Senior Developer 1 2010).

Tätigkeiten von verschiedenen Projekten werden zwischen geschoben (vgl. Senior Developer 2, 2010).

Keine klaren Anforderungen und Spezifikationen vorhanden (vgl. Senior Developer 2, 2010).

2.2.2 Management Feedback

Hinsichtlich des Managements und der Geschäftsführung bestand nur geringes Vertrauen in Bezug auf die Selbstständigkeit der Entwickler. Folgende Punkte wurden aus ihrer Sicht bemängelt:

Kein Überblick über Mitarbeiterkapazitäten (vgl. Projektleiter, 2010).

Kein Überblick und keine Transparenz über laufende Projekte (vgl. CEO, 2010).

Mitarbeiter verschweigen Fehler und Probleme (vgl. Projektleiter, 2010).

Projekte werden zu spät geliefert (vgl. CEO, 2010).

Mitarbeiter denken nicht Selbstständig, Aufwandsschätzungen dauern zu lange und sind unrealistisch (vgl. Projektleiter, 2010).

2.3 Projektprozess und Organisationsstruktur

Da das Unternehmen vor kurzem von einem vorherigen Vertriebspartner aus der Schweiz zusammen mit einem externen Personaldienstleister aus Thailand übernommen wurde, ist der Projektprozess und die Organisationsstruktur derzeit ausbaufähig (siehe nachfolgende Grafiken):

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Organigramm

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: IST-Projektprozess (vereinfacht)

2.4 Projektarten

In den nachstehenden Punkten werden die verschiedenen Projekte nach Kategorie und deren Funktionen aufgelistet.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Projektarten

2.5 Arbeitskultur Thailand

Thailänder neigen dazu äußerst reserviert zu sein, mit der Folge, dass Außenstehende nicht vollständig die Reaktionen und Antworten der Thais verstehen. Selbst wenn Thailänder nicht derselben Meinung sind, lächeln sie höfflich. (vgl. Jacob, 2003, S. 120-121)

Bevor eine Arbeit oder Aufgabe begonnen werden kann, steht die Beziehung an erster Stelle für den Erfolg eines Vorhabens. Ohne diese Beziehung zu Beginn kann dies den Fortschritt zwischen den Beteiligten stark erschweren. Zudem haben Thailänder ein hohes hierarchisches Bewusstsein, welches sich auch auf die Gesellschaft ausdehnt. Daraus folgt, dass bei der Kommunikation stets die Rangfolge beachtet werden muss. (vgl. Hogue, 2006, S. 50) In Bezug auf Veränderungen, finden diese nur mühsam statt. Abweichungen bestehender Situationen können daher als Bedrohung der Gesellschaft bzw. Arbeitsgemeinschaft gesehen werden. Es ist deshalb substanziell, dass Veränderungen eine positive Auswirkung für alle Beteiligten aufweisen. (vgl. Kwintessential, o.J.a)

Untersuchungen haben ergeben, dass der Entscheidungsprozess in Thailand aufgrund der Organisationsstrukturen und der weittragenden Bürokratie deutlich länger dauert. Jede Anforderung muss immerzu an das Management zur Freigabe berichtet werden. (vgl. Kruchten, 2004, S. 59)

2.6 Schwachstellen Analyse

Das in Abbildung 3 dargestellte Fischgrät-Diagramm verschafft einen Überblick über die vorhandenen Schwierigkeiten im Unternehmen und wird im Anschluss weiter erläutert. Es besteht aus mehreren Faktoren, wie Menschen, Maschinen etc, die die Produktivität eines Unternehmens/ Prozesses beeinflussen. Im folgenden werden diese Faktoren näher beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Ishikawa-Diagramm

- Menschen

Wie bereits erwähnt, fühlen sich die Mitarbeiter nicht in die Unternehmensprozesse eingebunden (siehe 2.2.1 Mitarbeiter Feedback). Hoher Zeitdruck und unklare Anforderungen verringern zudem die Motivation der Mitarbeiter. Hinzu kommt, dass in Thailand das verwendete CMS Typo3 noch unbekannt ist und hier ein Mangel an qualifizierten Mitarbeitern vorliegt. Das fachliche Wissen der bestehenden Mitarbeiter bzgl. Typo3 basiert nur aus der Erfahrung vergangener Projekte. Dokumentationen sind selten aufzufinden und entwickelte Module sind unzureichend archiviert.

- Kultur

Die Kultur spielt bei der Einführung von Scrum eine wichtige Rolle. Wie bereits in Punkt 2.5 „Arbeitskultur Thailand“ angeführt, weist eine thailändische Unternehmensführung ein starkes Hierarchieverhalten aus. Des Weiteren lassen sich Pro bleme in der kommunikativen Interaktion innerhalb des Unternehmens erkennen. Aufgrund ungenügender Englischkenntnisse entstehen schnell Missverständnisse und unklare Aufgabenstellungen. Dies wiederum kann sich negativ auf Prozesse sowie deren Realisierung auswirken.

- Management

Das Mitarbeitervertrauen wurde bereits im Abschnitt 2.2.2 Management Feedback näher beschrieben. Durch ständigen Wechsel des Managements und der Geschäftsführung in kürzester Zeit, wirkt das Unternehmen intern instabil.

- Maschinen

Die verwendete Projektmanagement Software Basecamp besitzt weder Funktionalitäten für eine Ressourcen Planung, noch ein Gantt-Diagramm bzw. eine Projektfortschritts Kontrolle. Auch werden hier Abhängigkeiten zwischen Projekten, Arbeitspaketen und Ressourcen vermisst.

Derzeit bestehen keine optimalen Voraussetzungen für eine schnelle Internetverbindung, die den Transfer von Projektdaten zwischen Thailand und Europa sichern (vgl. Central Intelligence Agency, 2010). Aus diesem Grund dauern Übertragungen oder Downloads zwischen Kundenservern und den des Unternehmens entsprechend lange.

- Methoden & Prozesse

Gegenwärtig wird die Führungsmethode „Management by Deligation“ in Verbindung mit dem Push Prinzip gebracht. Arbeitspakete werden täglich zentral von der Projektleitung an die Mitarbeiter zugewiesen ohne vorher das Projekt besprochen zu haben. Dies führt zu Konflikten während der Entwicklungsphase, da Anforderungen von den Entwicklern teilweise oder gar nicht verstanden werden. Spezifikationen werden hauptsächlich auf Deutsch von Kunden geliefert und anschließend von der Projektleitung ins Englische übersetzt. Gleichzeitig erstellt die Projektleitung die Arbeitspakete und eine Aufwandsschätzung. Eine Rücksprache oder Klärung der Anforderungen mit den Entwicklern wird nicht durchgeführt. Drei wesentliche Risiken können in diesem Prozess auftauchen:

1. Arbeitspakete können vergessen werden.
2. Aufwandschätzungen können stark abweichen.
3. Arbeitspakete können nicht umgesetzt werden, da ihre Anforderungen unklar sind.

Um den Stand eines Projektes nachvollziehen zu können, sind Software und/oder Hilfsmittel nötig, die jedoch nicht immer vorhanden sind. Demzufolge findet auch kein Projektcontrolling statt.

3 Soll Zustand

Für die Zieldefinition wurden die zwei Faktoren „Menschen“ und „Methoden & Prozesse“ aus der Schachstellen Analyse in den Zielkatalog einbezogen, da sonst der Umfang dieser Arbeitet zu groß wäre. Es wird angenommen, dass diese Mittels Scrum optimierbar sind.

Zur Zielbeschreibung wurde die Technik von User Stories angewendet, welches in Scrum auch Verwendung findet. Dadurch kann eine Verknüpfung verschiedener Rollen zusammen mit Zielen und ihrem Zweck geschaffen werden.

Die Auswahl, die Einstufung und die Bewertung der Ziele wurden von mir (der Projektleitung) durchgeführt, da diese in meinen Kompetenzbereich fallen.

Abbildung in dieser Leseprobe nicht enthalten

4 Das Scrum Framework

Im folgenden Kapitel soll das Scrum Framework vorgestellt und einen Einblick in die Grundlagen dieser agilen Vorgehensweise gegeben.

4.1 Einführung

Die Terminologie des Vorgehensmodells Scrum basiert auf den Artikel „The new new product development game“ von Hirotaka Takeuchi und Ikujiro Nonaka. Dieser wurde, 1986 in der Harvard Business Review veröffentlicht. Darauf aufbauend wurde 1993 von Ken Schwaber und Dr. Jeff Sutherland dieses Modell klar definiert (vgl. Scrum Alliance, o. J. b).

In diesem Zusammenhang wurden im Jahr 2001 von verschiedenen Vertretern agiler Software-Entwicklungsmethoden 12 Prinzipien verabschiedet, die auch bei Scrum ihren Stellenwert wiederfindet (vgl. Beck, et al., 2001):

„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.“

4.2 Scrum Flow

In diesem Abschnitt wird das Scrum Ablaufmodell aus der Abbildung 4: Scrum Flow (Deemer, et al., 2009, S. 5) in Kürze zusammengefasst.

Die Arbeitsweise in Scrum ist iterativ und inkrementell. In der Literatur werden Iterationen (auch Sprints genannt) jeweils bis zu 4 Wochen empfohlen und sind nicht verlängerbar. Zu Beginn eines jeden Sprints werden die zuvor priorisierten Anforderungen (in Scrum Product Backlog Items genannt) von einem funktionsübergreifendem Team ausgewählt und gleichzeitig ein Versprechen abgegeben, wie viele der Anforderungen sie in der kommenden Iteration bewerkstelligen können (vgl. Deemer, et al., 2009, S. 4-5).

Der Autor Boris Gloger führt vor den Sprint Planning Meetings 1+2 (siehe Abbildung 4) ein Estimation Meeting ein, welches zum Schätzen der Anforderungen gilt (vgl. Gloger, 2008, S. 183 -184). Das Sprint Planning Meeting 1 gibt Antwort auf die Frage „Was“ soll gemacht werden. Sprint Planning Meeting 2 klärt die Frage „Wie“ etwas gemacht werden soll (vgl. Gloger, 2008, S. 193).

Während den Sprints werden die ausgewählten Anforderungen nicht verändert bzw. getauscht. In dieser Zeitspanne werden täglich Meetings (Daily Scrum) abgehalten um den Fortschritt zu kontrollieren und die nächsten Schritte für die Arbeit abzusprechen. Am Ende eines Sprints folgt das sogenannte Review. Dabei werden die Ergebnisse an die Stakeholder präsentiert, Feedback eingeholt und darauf Wert gelegt, vollständige und funktionsfähige Ergebnisse zu präsentieren. Ein wesentlicher Aspekt dieser agilen Methode findet sich schließlich in der Retrospektive wieder, die sich dem Review anschließt. Die Retrospektive dient der kontinuierlichen Verbesserung durch das Lernen aus der jeweiligen vergangenen Iteration, in dem Ereignisse untersucht und entsprechende Verbesserungen oder Anpassungen übernommen werden (vgl. Deemer, et al., 2009, S. 4-5).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Scrum Flow (Deemer, et al., 2009, S. 5)

Das Scrum Ablaufmodell spiegelt sich in dem Deming Cycle aus den 1950er Jahren von W. Edwards Deming wieder (vgl. Gloger, 2008, S. 48 - 49). Der Deming Ansatz „plan-do-check-act“ hat ebenfalls im Total Quality Management (TQM) Verwendung (vgl. Schönbächler und Pfister, 2011, S. 111).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Scrum mit Deming Cycle

4.3 Scrum Rollen

Anders als im klassischen Projektmanagement gibt es in Scrum keinen Projektmanager mehr. „Die Aufgaben des Projektmanagements sind hier auf drei Rollen aufgeteilt.“ (Fritsch und Dechko, 2010) Die Schlüsselrollen bilden in Scrum der Product Owner, Scrum Master und das Team.

4.3.1 Der Product Owner

Der Product Owner ist für das Resultat und den „[…] wirtschaftlichen Erfolg des Projekts verantwortlich.“ (Wirdemann, 2009, S. 43) Er vertritt die Interessen aller beteiligten Stakeholder des Projekts und priorisiert die Anforderungen (Product Backlog), damit die für den Kunden wichtigsten Aufgaben zuerst bearbeitet werden (vgl. Wirdemann, 2009, S. 43 - 44).

Das Product Backlog wird nur von dem Product Owner selbst erstellt und verändert. Er ist auch derjenige der die Anforderungen priorisiert in dem er die „wertvollsten“ Funktionalitäten bestimmt (vgl. Wirdemann, 2009, S. 43 - 44).

Das Team wird von einem Product Owner als einzelne Person betreut und steht als Ansprechpartner für alle Fragen jederzeit zur Verfügung. Da der Product Owner eng mit dem Kunden arbeitet, muss er „[…] die volle Autorität des Kunden besitzen.“ (Wirdemann, 2009, S. 43 - 44)

Für Aufwandsschätzungen, welches im Team unter der Anleitung und Moderation des Product Owners geschieht, ist er ebenfalls verantwortlich (vgl. Wirdemann, 2009, S. 43 - 44).

4.3.2 Der Scrum Master

Der Scrum Master ist der Vermittler zwischen Product Owner und dem Team. Daher besitzt er auch keine Autorität und Weisungsbefugnis zwischen den Beiden Rollen. In erster Linie sorgt er dafür, alle Hindernisse und Barrieren die das Sprint Ziel gefährden zu beseitigen. Somit trägt er dazu bei, die Produktivität des Teams zu steigern und unterstützt den Product Owner bei seiner Arbeit (vgl. Szalvay, Scrum Master Role, 2009, S. 99 - 100). Ebenfalls ist der Scrum Master für den Scrum Prozess verantwortlich und muss sicherstellen, dass die Regeln und Praktiken z. B. durch Schulungen von Scrum im Unternehmen eingehalten werden (vgl. Schwaber, 2007, S. 106).

4.3.3 Das Scrum Team

In Scrum wird eine Teamgröße von 7 - 12 Teilnehmern empfohlen und sind multidisziplinär. In einem Team sind nicht nur Entwickler, sondern können beispielsweise auch Designer, Architekten, Tester etc. beinhalten (vgl. Scrum Alliance, o. J. a). Um es klar zu definieren, „[…] Ein Scrum-Team besteht aus den Personen, die die Kenntnisse haben, um das Stück Produkt in seiner Gesamtheit zu liefern.“ (Gloger, 2008, S. 77)

Das Team darf während eines Sprints eigenständig entscheiden wie sie ihre Aufgaben bestmöglich lösen. Die Teammitglieder organisieren sich selbstständig und eigenverantwortlich, d.h. den einzelnen Personen wird nicht vorgeschrieben welche Tätigkeit sie ausführen müssen. Damit liegt die Verantwortung beim Team (vgl. Scrum Alliance, o. J. a).

5 Ansätze nach Scrum und alternative Lösungsansätze

Der Zweck dieses Kapitels besteht darin, die Umsetzung der Ziele aus dem Kapitel 3 mit Hilfe von Scrum zu beschreiben. Gleichzeitig wird versucht mögliche Alternativen aufzuzeigen. Beide Lösungsansätze werden in einem Maßnahmenkatalog pro Ziel erfasst und bewertet, um im nächsten Kapitel eine Evaluation vorzunehmen.

In dem Maßnahmenkatalog fließen die 3 Faktoren Kosten, Zeit und Risiken ein. Die Gewichtung der Faktoren erfolgt jeweils mit drei Punkten. Aufgrund der unterschiedlichen Prioritäten der Faktoren, wurde eine unterschiedliche Punkteverteilung gewählt. Je höher die Punktzahl, desto besser sind die Bedingungen für eine Umsetzung.

Ansätze nach Scrum und alternative Lösungsansätze 16

Bei den Kosten wurden intern mit der Geschäftsführung folgende Werte für die Gewichtung ermittelt:

Abbildung in dieser Leseprobe nicht enthalten

Der Faktor Zeit berücksichtigt den Umsetzungsaufwand in Zeit pro Mitarbeiter. Eine Zeiteinheit entspricht ein Manntag (8 Arbeitsstunden):

Abbildung in dieser Leseprobe nicht enthalten

Da das Risiko von den jeweiligen Zielen und Maßnahmen abhängt, wird bei der Gewichtung die Wahrscheinlichkeit des Misserfolges einer Maßnahme betrachtet:

Abbildung in dieser Leseprobe nicht enthalten

Ansätze nach Scrum und alternative Lösungsansätze 17

5.1 Ziel Klasse: Prozess

5.1.1 Scrum Framework einführen

Abbildung in dieser Leseprobe nicht enthalten

einführen, so dass ich eine unternehmensweite Grundlage in Bezug auf Methoden und Prozesse besitze.

Wie bereits in Punkt 4.3 erwähnt, gibt es in Scrum keine Projektmanager. Dies bedeutet einen Umbruch in der Unternehmensorganisation. Ken Schwaber, Mitbegründer von Scrum schreibt zu Beginn seines Buches „The Enterprise and Scrum“, dass sich Unternehmensgewohnheiten und die Unternehmenskultur ändern müssen, um von Scrum profitieren zu können. Darüber hinaus fügt er hinzu, dass bei Einführung von Scrum alle Beteiligten über diese agile Methode aufgeklärt bzw. geschult werden müssen (vgl. Schwaber 2007, S.1 - 3).

5.1.1.1 Schulung von Scrum

Will man Scrum im Unternehmen einführen, so gehören sowohl Schulungen als auch eine Aufklärung des Managements und der Mitarbeiter dazu. Primär gibt es hier interne sowie externe Hauptüberlegungen.

1. Intern:

a. Eine interne Lösung besteht darin, dass sich bspw. nur der Projektleiter oder dieser zusammen mit der Geschäftsführung das nötige Wissen aneignen und entsprechend weiter vermitteln.
b. Eine weitere interne Lösung ist, die verantwortlichen Personen (z B. Projektleiter und Geschäftsführer) an einer zertifizierten Schulung teilnehmen zu lassen. Nachdem diese das nötige Wissen erworben haben können sie die Mitarbeiter schulen. Hier muss erwähnt werden, dass in Asien derzeit bei der Scrum Alliance^[1] nur drei Scrum Trainer und ein Scrum Coach vorhanden sind, die Schulungen anbieten (vgl. Scrum Alliance, o.J.d). Vollständigkeitshalber soll hier erwähnt werden, dass in Thailand zwischen dem 27. - 28 Oktober 2011 ein Schulungstermin stattfindet. Die Kosten belaufen sich insgesamt auf umgerechnet 680 Euro pro Person (vgl. Scrum Alliance, o.J.e) (Stand 18.05.2011).

2. Extern:

Eine mögliche Alternative ist, einen externen Trainer oder einen Coach für die Schulung aller Mitarbeiter hinzu zu ziehen. Leider ist dieser Ansatz (noch) hypothetisch zu sehen, da es in Thailand hierfür weder Trainer noch Coachs gibt (vgl. Scrum Alliance, o.J.d). Laut Bas Vodde, Scrum Trainer aus Singapur, lohnt es sich nicht für 8 - 10 Mitarbeitern, Schulungen intern im Unternehmen durchzuführen (vgl. Vodde, 2011).

5.1.1.2 Kickoff Meeting

Bevor Scrum eingeführt wird, sollte zuvor ein Kickoff Meeting stattfinden. Dabei sollten mindestens die Projektleitung und die Geschäftsführung vertreten sein. In der Literatur wird vorgeschlagen, ein „[…]Enterprise Transition team[…]“ (Schwaber, 2007, S.9) zu gründen, welches den Wechsel zu Scrum organisiert und schließlich das Kickoff Meeting initiiert (vgl. Schwaber, 2007, S.11). Hinsichtlich der aktuellen Unternehmensgröße in Thailand wäre es ebenfalls denkbar alle Mitarbeiter einzubeziehen. Bei kleineren Unternehmen ist es in Erwägung zu ziehen, alle Mitarbeiter einzuladen. Insofern wird aus einer Beispiel Kickoff Meeting Agenda von Ken Schwaber nur die relevanten Punkte entnommen:

1. „Review Scrum“:

Sicherstellung, dass alle Meeting-Teilnehmer Scrum verstanden haben (vgl. Schwaber, 2007, S.11).

2. Entscheidung treffen:

Der Beschluss ob Scrum eingeführt werden soll oder nicht (vgl. Schwaber 2007, S. 11).

3. Das erste Scrum Projekt:

Auswahl eines Projektes, welches mittels Scrum umgesetzt werden soll (vgl. Schwaber, 2007, S.11). Für die Umsetzung zu diesem Punkt gibt es verschiedene Varianten, die im Anschluss in Abschnitt 5.1.1.3 besprochen werden.

4. Rollenverteilung:

In einem Unternehmen, das Scrum nie eingesetzt hat, müssen die entsprechenden Rollenzuordnungen festgelegt werden. Die unterschiedlichen Konstellationen werden anschließend in Abschnitt 5.1.1.4 erwähnt.

5. Planung des ersten „[…]Sprints Planning Meetings“:

Terminfestlegung, wann ein „[…]Sprint Planning Meeting[…]“ stattfinden soll (vgl. Schwaber, 2007, S.11).

5.1.1.3 Das erste Scrum Projekt

Wie bereits bei der Schulung von Scrum erwähnt, gibt es auch hier die Möglichkeiten, das erste Scrum Projekt nur mit internen Ressourcen oder zusätzlich externer Hilfe umzusetzen. Die Kosten für den Einsatz eines Trainers, würden sich bei einer 2-wöchigen Sprintbetreuung mindestens auf 20.000 Euro belaufen (vgl. Vodde, 2011).

Für die Einführung von Scrum sind zwei verschiedene Lösungsansätze vorhanden. Entweder beginnt man mit einem Pilotprojekt, welches mit Scrum umgesetzt werden soll oder man führt Scrum sofort für das ganze Unternehmen und alle Projekte ein. Der Autor Mike Cohn hat die Argument für Pilotprojekte und einer Gesamtumsetzung von Scrum wie folgt dargestellt (vgl. Cohn, Succeeding with Agile - Software development using Scrum, 2010, S. 44 - 46):

Ansätze nach Scrum und alternative Lösungsansätze 20

Argumente für den Start mit einem kleinen Pilot Projekt:

- Es ist kostengünstiger mit einem kleinen Projekt zu beginnen.
- Ein früherer Erfolg ist meistens garantiert.
- Es wird vermieden, große Risiken in Kauf zu nehmen.
- Es herrscht weniger Mitarbeiterbelastung (geringer Stressfaktor).
- Kleine Projekte werden nicht direkt von Mitarbeiter wahrgenommen und somit herrscht weniger wiederstand gegen Scrum

Argumente für eine sofortige Gesamtumsetzung:

- Eine Gesamtumsetzung kann den Widerstand gegen Scrum verringern, da es als endgültiger Beschluss von den Mitarbeitern gesehen wird.
- Es wird vermieden, dass Scrum Teams mit traditionell arbeitenden Teams in Konflikt geraten.
- Die Einführung in Scrum geschieht schneller bei einer Gesamtumsetzung.

5.1.1.4 Rollenverteilung

In dem thailändischen Unternehmen ist die Anzahl der Mitarbeiter für eine Teambildung bereits gegeben. Nun fehlen der Product Owner und der Scrum Master. Sicherlich gibt es die Möglichkeit den Projektleiter als Product Owner einzusetzen. Die Aufgaben sind im Abschnitt 4.3.1 auf Seite 14 bereits beschrieben. Den Scrum Master könnte man aus dem Mitarbeiterpool wählen, wobei sich hier die Frage stellt, wie stark die Arbeitsauslastung als Scrum Master ist und ob der Mitarbeiter seine alte Tätigkeit ablegen müsste. Abgesehen davon, müsste die Tätigkeit als Scrum Master auch gewollt sein. Zusätzlich bleibt offen, ob das Team den Mitarbeiter als Scrum Master akzeptiert. Ein Vorschlag wäre, einen neuen Mitarbeiter für die Rolle des Scrum Masters einzustellen.

Eine weitere Alternativlösung wäre, dass die Projektleitung als Scrum Master und Product Owner in einer Person agiert. Im Hinblick auf die unterschiedlichen Tätigkeiten und Verantwortung, kann man davon ausgehen, dass diese Person ständig im Konflikt zwischen den Aufgaben des Product Owners und denen des Scrum Master stehen würde.

[...]

---

^[1] Die Scrum Alliance ist eine aus nicht Profit gegründete Mitglieder Organisation, dessen Ziel es ist das Scrum Framework zu verbreiten und die Arbeitswelt zu verändern (Scrum Alliance o.J.c).

• College: Munich University of Applied Sciences
• Grade: 1,3
• Author: Erhan Dikkaya (Author)
• Publication Year: 2011
• Pages: 103
• Catalog Number: V180171
• ISBN (eBook): 9783668406551
• ISBN (Book): 9783668406568
• Language: German
• Tags: Scrum, Projektmanagement, Agile, Thailand, Thai, Kanban, Softwareentwicklung