Beschreibung und Analyse von SCRUM

Aus Winfwiki

Wechseln zu: Navigation, Suche

Fallstudienarbeit

Hochschule: Hochschule für Oekonomie & Management
Standort: Düsseldorf
Studiengang: Bachelor Wirtschaftsinformatik
Veranstaltung: Fallstudie / Wissenschaftliches Arbeiten
Betreuer: Prof._Dr._Uwe_Kern
Typ: Fallstudienarbeit
Themengebiet: Agile Softwareentwicklung
Autor(en): Alexander Otto, Andreas Grunwald
Studienzeitmodell: Abendstudium
Semesterbezeichnung: SS11
Studiensemester: 2
Bearbeitungsstatus: begutachtet
Prüfungstermin:
Abgabetermin:


Inhaltsverzeichnis

1 Abkürzungsverzeichnis

Abkürzung Bedeutung
CSM
 Certified ScrumMaster
CSPO
 Certified Scrum Product Owner
DoD
 Definition of Done
IT
 Informationstechnik
OOPSLA
Object-Oriented Programming, Systems, Languages & Applications
PT
Personentage
PO
Product Owner
RoI
Return on Investment
XP
Extreme Programming

2 Abbildungsverzeichnis

Abb.-Nr. Abbildung
1
Ein Scrum Prozess im Überblick
2
Sprint Burndown Chart

3 Tabellenverzeichnis

Tab.-Nr. Tabelle
1
Beispielhaftes Product Backlog
2
INVEST-Kriterien für erfolgreiche User Stories
3
Story Points Staffelung

4 Einleitung

Die Produkt- und Softwareentwicklung ist ein schwieriges und herausforderndes Unterfangen. Kundenanforderungen und Bedürfnisse müssen analysiert, geplant und umgesetzt werden. Dies ist kein leichter Prozess. Anforderungen und Bedürfnisse unterliegen einem stetigen Wandel. Die Parameter, die dazu führen, sind nicht immer beeinfluss- oder steuerbar. Mögliche Gründe für geänderte Indikatoren sind weit gestreut. Von kleinen steuerbaren Korrekturmaßnahmen über eine erhebliche Korrektur der Marktausrichtung durch das höhere Management bis hin zu kulturellen oder gesetzlichen Änderungen ist alles möglich. Dazu kommt, dass die Zeit die Art der Projekte erheblich geändert hat. Komplexität und Risiko sind gestiegen. Zeitgleich hat sich die Anzahl mögliche Parameter und möglichen Fehlern erhöht. Diese Umstände machen es schwierig, ein Projekt erfolgreich durchzuführen.

Klassisches Projektmanagement geht nicht detailliert genug auf die aktuelle Situation ein. Die Projektdurchführung mittels Lasten- und Pflichtenheft und feststehenden Zeitplänen lässt nicht viel Raum für Flexibilität. Die zu Projektstart festgelegten Bedürfnisse und Anforderungen werden konzeptioniert und umgesetzt. Je größer der Umfang des Projektes, desto mehr Zeit vergeht zwischen der Manifestierung, Umsetzung und Fertigstellung der Funktionen. Resultat dieses Vorgangs ist ein Produkt, was auf die Bedürfnisse des Kunden zu Projektbeginn zugeschnitten ist. Ob diese noch die gleichen Anforderungen wie zum Abschluss der Umsetzung sind, hängt an den teilweise nicht beeinflussbaren Parametern. Der Eingriff des Kunden in den Projektalltag ist begrenzt. Korrekturen, die durch Änderungen der Parameter notwendig werden, sind in der Regel sehr kostspielig. Klassisches Projektmanagement ist durch die gestiegene Komplexität der Projekte nicht mehr Zeitgemäß.

Agile Managementmethoden sind auf die aktuellen Umstände zugeschnitten. Sie bieten enorme Flexibilität durch Berücksichtigung von Änderungen während der Projektlaufzeit und eine höhere Erfolgschance sowie Kundenzufriedenheit gegenüber klassischen Managementmethoden. Einer der Vorreiter agiler Prozesse ist Scrum. „Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software, die Kosten, die Funktionalität, die Zeit und die Qualität einbeziehend“[1]. Scrum erfreut sich großer Beliebtheit und fördert die Popularität agiler Methoden enorm.

Zielsetzung dieser Fallstudie ist es, dem Leser einen detaillierten Einblick in die Projektdurchführung mittels Scrum zu ermöglichen. Desweiteren wird eine objektive Analyse dieser agilen Methode anhand von definierten Bewertungskriterien durchgeführt und bereitgestellt.

Zum Anfang dieser Arbeit wird auf die Grundlagen des schlanken Managementprozesses eingegangen. Nachfolgend wird die korrekte Anwendung von Scrum anhand eines klassischen Projektes exemplarisch beschrieben. Die dort verwendeten Elemente werden in Kapitel 6 Artefakte nach Scrum detailliert beschrieben. Es wird auf die verschiedenen Arten der Projektbeteiligten, der Umgang mit Kundenanforderungen sowie der Art und Weise der eigentlichen Umsetzung eingegangen. Im ersten Teil des darauffolgenden Kapitels werden die für die Analyse benötigten Bewertungskriterien definiert. Anhand dieser Eigenschaften wird im zweiten Teil von Analyse von Scrum die Analyse durchgeführt. Abschließend wird die Analyse innerhalb einer Gesamtbetrachtung zusammengefasst und ein finales Fazit gezogen.

5 Grundlagen

In diesem Kapitel werden allgemeine Grundlagen zum Thema Scrum dargelegt. In der Vorstellung von Scrum geht es zunächst um den geschichtlichen Hintergrund und eine grobe Vorstellung der Abfolge nach Scrum. Das Kapitel Produktentwicklung nach Scrum geht auf den Entwicklungsprozess und die vorhandenen Zeremonien ein.

5.1 Vorstellung von Scrum

Der Begriff Scrum oder Scrummage (eine Abwandlung des Wortes Scrimmage), zu Deutsch Gedränge, stammt aus der Sportart Rugby und beschreibt den Vorgang des Spiels, in dem beide Mannschaften um den Besitz des Spielballs kämpfen, während dieser ins Spielfeld eingeworfen wird. Die erste Begriffsnennung von Scrum in Bezug auf die Produktentwicklung fand im Jahre 1986 durch Hirotaka Takeuchi und Ikujiro Nonaka in dem Artikel The New New Product Development Game statt[2]. Auf Basis dieser Ideen wurde Scrum von Jeff Sutherland und Ken Schwaber weiterentwickelt und erstmals auf der OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) Konferenz im Jahr 1996 vorgestellt[3].

Scrum ist kein traditionelles Softwareentwicklungsmodell, sondern ein agiles Management Framework[4]. Es ist ein iterativer und inkrementeller Prozess zur Entwicklung von (Software)-Produkten in einem sich schnell ändernden Umfeld. Es lässt sich auf alle Arten der Softwareentwicklung anwenden und ist besonders für komplexe Projekte geeignet. Komplexe Projekte sind dadurch charakterisiert, dass nicht exakt vorhersehbar ist, welchen Verlauf das Projekt nehmen wird und was in Zukunft alles passiert[5]. Wie die Sportart Rugby besitzt Scrum wenige Regeln. Diese müssen jedoch konsequent und diszipliniert eingehalten werden. Es wird ein Rahmen vorgegeben, in dem alle Aktivitäten einer Produktentwicklung ablaufen. Im Gegensatz zu klassischen Prozessmodellen stellt Scrum den Projektbeteiligten lediglich Hilfsmittel, Regeln und Zeremonien zur Verfügung um das geforderte Ziel optimal zu erreichen. Somit ist Scrum nicht technologie- und toolorientiert[4] und nicht auf die Softwareentwicklung begrenzt, wofür es jedoch ursprünglich entwickelt wurde [6].

Ein Projekt, welches mit Hilfe von Scrum durchgeführt wird, besteht aus immer wiederkehrenden, zeitlich gleichbleibenden Iterationen, in denen eine Untermenge aller Anforderungen umgesetzt werden. Diese werden in der Scrum-Terminologie als Sprints bezeichnet. Das Resultat eines jeden Sprints ist eine lauffähige, mit neuen oder veränderten Anforderungen bestückte Version des zu entwickelnden Produktes. Daraufhin werden die Ergebnisse durch das Team vorgestellt und mittels des Managements und des Kunden überprüft. Auf dieser neu geschaffenen Basis und eventuell veränderten Entscheidungsparametern durch Konkurrenz, Markt und Umwelt werden die ursprünglichen Anforderungen erneut angepasst und priorisiert. Damit ist das Projekt nahe an seiner Ausgangslage und ein weiterer Sprint, mit dem Ziel der Umsetzung gewisser Anforderungen, wird gestartet. Durch diese empirische Vorgehensweise verbessert sich das angestrebte Projekt kontinuierlich[7].

Als eine agile Methode verkörpert Scrum die Werte des agilen Manifests[8], welches im Februar 2001 von 17 IT-Experten aus aller Welt unterzeichnet wurde. Das Manifest (somit auch Scrum) stellt in seinen Grundsätzen Individuen und Interaktionen über Prozesse und Werkzeuge, funktionierende Software über eine umfassende Dokumentation, Zusammenarbeit mit dem Kunden über Vertragsverhandlungen und reagieren auf Veränderung über das Befolgen eines Plans[8]. Wie durch die Grundsätze ersichtlich wird, legt das agile Manifest den Fokus stark auf die einzelnen Menschen, die an der Produktentwicklung beteiligt sind. Dadurch tragen diese Personen in der Regel mehr Verantwortung als in klassischen Prozessmodellen und werden stärker in die Gruppe integriert. Durch diese starke Betonung einzelner Personen soll eine große Produktivitätssteigerung erreicht werden. Eine erhebliche Steigerung der Kundenzufriedenheit findet ebenfalls statt. Dies wird unter anderem dadurch ermöglicht, dass der Kunde von Anfang an mit in die Produktentwicklung einbezogen wird und ihm bereits zu frühen Zeitpunkten erste Prototypen des geforderten Produkts vorgestellt werden. Dem Kunden sowie dem Team wird die Möglichkeit geschaffen, frühzeitig auf Veränderungen zu reagieren und ursprüngliche Anforderungen auf die neuen Gegebenheiten anzupassen. Dieser iterative und inkrementelle Prozess fördert die Flexibilität einer Produktentwicklung und ist wesentlicher Bestandteil der agilen Softwareentwicklung.

5.2 Produktentwicklung nach Scrum

In Anlehnung an: Scrum Alliance (2011), http://www.scrumalliance.org/pages/what_is_scrum (02.06.2011, 10:12)Abb. 1: Ein Scrum Prozess im Überblick
In Anlehnung an: Scrum Alliance (2011), http://www.scrumalliance.org/pages/what_is_scrum (02.06.2011, 10:12)
Abb. 1: Ein Scrum Prozess im Überblick

Zu Projektstart werden alle, durch den Kunden wiedergegebenen Features, gesammelt und in einer Liste, priorisierend geordnet, zusammengefasst. Diese Liste wird als Product Backlog bezeichnet. Einträge innerhalb eines Backlogs werden als Items bezeichnet. Wenn das Product Backlog initial gefüllt wurde, wird im nachfolgenden Sprint Planning Meeting zusammen mit Product Owner und Entwicklungs-Team festgelegt, welche Items aus dem Product Backlog mit ins Sprint Backlog übernommen werden. Der Inhalt des Sprint Backlogs gibt an, was innerhalb des nächsten Sprints umgesetzt werden soll.

Die Länge eines Sprints kann von Projekt zu Projekt variieren und wird zu Beginn des ersten Sprints festgelegt. Die festgelegte Dauer gilt für alle nachfolgenden Sprints innerhalb eines Projektes. In diesem Zeitraum werden die im Sprint Backlog gesammelten Anforderungen, die sogenannten User Stories, einzeln durch das Team bearbeitet. Eine User Story gilt als bearbeitet, sobald diese alle Anforderung einer vorher festgelegten Kriterienliste einer abgeschlossenen User Story, im Scrum Terminus als DoD (Definition of Done) bezeichnet, erfüllt[9].

Während eines Sprints findet täglich zu einer festen Uhrzeit eine wichtige Scrum Zeremonie statt, das Daily Scrum. In diesem maximal 15 Minuten andauernden Meeting synchronisiert sich das Team und die Manager gegenseitig über den aktuellen Sprint-Status. Nach einem abgeschlossenen Sprint folgt das Sprint Review Meeting. Dort werden die im Sprint umgesetzten User Stories durch das Team präsentiert und durch den Product Owner und Kunden abgenommen. Der Sprint wird durch die Sprint-Retrospektive vollständig abgeschlossen. In diesem Meeting wird über die Zusammenarbeit innerhalb des Teams reflektiert, um daraus Verbesserungen für die nächste Entwicklungs-Iteration ableiten zu können.

Wenn zu diesem Zeitpunkt das Product Backlog weitere Items beinhaltet, wird der Prozess mit dem Beginn eines Sprint Planning Meeting wiederholt. Mit diesem Verfahren wird das Product Backlog sequenziell abgearbeitet und der Kunde erhält nach jedem Sprint ein stets ausführbares und potenziell auslieferungsfähiges Produkt nach seinen aktuellsten Anforderungen. Abb. 1 stellt den beschriebenen Prozess visuell dar.

6 Artefakte nach Scrum

In der agilen Softwareentwicklung gilt auslieferbarer Code als das einzige Artefakt, auf das nicht verzichtet werden kann. Da face to face Kommunikation als die effizienteste und effektivste Form der Kommunikation gilt, spielt dies in Scrum ein große Rolle. In diesem Kapitel werden die verschiedenen Rollen des Scrum Frameworks beschrieben. Diese sind besonders wichtig um das Regelwerk von Scrum, welches in Kapitel 7.2.3 beschrieben wird, einhalten zu können. Desweiteren wird im Kapitel 6.2 auf die Anforderungen eingegangen, welche zu einer effektiven Kommunikation nach Scrum gehören.

6.1 Rollen

Das Scrum Framework berücksichtigt drei verschiedene Arten von Projektbeteiligten. Jeder dieser Rolle hat strikt definierte Kompetenzbereiche sowie Verantwortlichkeiten. Die Einhaltung und nicht Überschreitung der geregelten Aufgabenbereiche ist ein wichtiger Faktor für den erfolgreichen Einsatz von Scrum. Der Product Owner (s. Kapitel 6.1.1) ist für die erfolgreiche Abschirmung des Teams durch das höhere Management verantwortlich. Das Team (s. Kapitel 6.1.2) als ausführende und entwickelnde Kraft hat für ein funktionierendes Produkt Sorge zu tragen. Der Scrum Master (s. Kapitel 6.1.3) ist dafür zuständig, die Einhaltung des definierten Regelwerks zu wahren.

6.1.1 Product Owner

Die Rolle des Product Owner ist eine zentrale und sehr wichtige Aufgabe innerhalb des Scrum Prozess. Er bildet eine Brücke zwischen dem Management und der Softwareentwicklung und arbeitet sehr eng mit beiden Gruppen zusammen. Er analysiert die Domäne des Kunden und erkennt die Wünsche und Anforderungen des Auftraggebers. Der Product Owner ist für das Erreichen der Projektziele sowie den (wirtschaftlichen) Erfolg des Projektes, den RoI (Return on Investment), verantwortlich[10].

Einer seiner vielfältigen Aufgabenbereiche ist die initiale Befüllung sowie eine dauerhafte Pflege des Produkt Backlogs. Gemeinsam mit den Stakeholdern arbeitet er an den initialen und sich veränderten Anforderungen des Projektes und bildet daraus geeignete User Stories. In dieser Kooperation werden die gebildeten Arbeitspakete priorisiert, um den größtmöglichen Mehrwert für das Geschäftsmodell des Kunden bilden zu können[11]. Auf dieser Basis erfolgt zu einem späteren Zeitpunkt die nach Priorität geordnete Umsetzung.

Der Product Owner ist einer der wenigen Personen, die an allen Scrum-Besprechungen teilnehmen. Seine Rolle entscheidet, welche Anforderungen Teil der nächsten Version sein sollen und wann diese ausgeliefert werden soll. Zusätzlich ist er die Person, die das Resultat eines Sprints final absegnet. Im Sprint-Review-Meeting übernimmt er die Prüfung sowie Abnahme der einzelnen User Stories und des Gesamt-Ergebnisses[12]. Der Auftraggeber muss ein gutes Vertrauensverhältnis zum Product Owner besitzen, da dieser befugt sein muss, um eigenmächtig Entscheidungen treffen zu können. Dies ist ein wichtiges Merkmal im gesamten Scrum-Prozess. Bei langwierigen oder verspäteten Entscheidungen kann es trotz der agilen Vorgehensweise zu Verzögerungen im Ablauf kommen, wodurch möglicherweise wichtige Termine nicht eingehalten werden können.

Im direkten Vergleich existiert im klassischen Projektmanagement keine Person, die mit dem Product Owner gleichzusetzen wäre. Die Aufgaben eines traditionellen Projektmanagers werden durch eine diese Rolle abgedeckt. Aufgrund seiner weiteren Aufgabenbereiche und der hohen Verantwortung wird die Rolle in verschiedenen Unternehmen, zum Beispiel Yahoo, als single wringable neck bezeichnet. Dieser Ausdruck macht die alleinige Verantwortung, trotz seiner schroffen Art, deutlich[12].

6.1.2 Team

Das Team ist die wichtigste Rolle in Bezug auf die Produktentwicklung. Seine Hauptaufgabe ist die Produktion des (Software-)Produkts. Um dieses Ziel mit einer möglichst hohen Professionalität sowie Produktivität verwirklichen zu können, ist es wichtig, dass das Team interdisziplinär zusammen gesetzt wird. Dies schafft die Möglichkeit viele verschiedene Ansichten bei einer Lösung einer spezifischen Aufgabe berücksichtigen zu können[13]. In der Literatur wird die optimale Größe eines Scrum-Teams zwischen fünf und neun Personen angegeben. Durch die fachübergreifende Zusammensetzung arbeiten Designer, Tester, Datenbankspezialisten und Programmierer zusammen an der Vision des Auftraggebers.

Ein wichtiger Punkt im Scrum-Prozess ist die Art und Weise der Organisation des Teams. Es trifft eigenständig Entscheidungen und organisiert sich untereinander vollständig selbst[13]. Dies bewirkt eine hierarchielose Zusammenarbeit, die keinen Teamleiter oder Manager benötigt. Dennoch erfordert es viel Vertrauen seitens des Managements. Eine solche Selbstorganisation benötigt viel Disziplin und ist ein Lernprozess, der in der Regel über zwei Sprints andauert. Oft ist dabei die Anwendung des Tuckman-Phasenmodells hilfreich[14].

Gemeinsam entscheidet das Team welche Items aus dem Product Backlog ins Sprint Backlog übernommen werden. Auf dieses Ziel verpflichtet sich das Team freiwillig[15]. Wie auch der Product Owner besitzt das Team eine hohe Verantwortung. Das Entwicklungsteam wird einzig und allein am Sprintziel gemessen und ist für den Erfolg und das Ergebnis jedes einzelnen Sprints verantwortlich[16]. Je länger das Team die Möglichkeit besitzt zusammen zu arbeiten, umso eher steigt die Teamdynamik und Einarbeitungsaufwände werden reduziert. Dies hat eine Steigerung der Produktivität je Sprint (Velocity) sowie eine Stärkung des Teamgefühls zur Folge. Roman Pichler empfiehlt als erfahrener Scrum Coach, dass die einzelnen Teammitglieder Vollzeit und über die vollständige Projektdauer im Team arbeiten[17].

6.1.3 Scrum Master

Der Scrum Master hilft dabei, das Projekt mittels der Scrum-Methodik durchzuführen. Seine Hauptaufgabe ist es den Scrum-Prozess korrekt im Team und im Projekt zu etablieren. Er fördert neue Denk- und Verhaltensweisen, die direkte Zusammenarbeit von Product Owner und Entwicklungsteam, achtet auf strikte Einhaltung der Regeln und Prinzipien und sorgt für die optimalen Arbeitsbedingungen innerhalb des Teams. Dazu gehören das Abschirmen von negativen Einflüssen sowie die Beseitigung aller Hindernisse zur Produktentwicklung.

Diese Art von Hindernissen wird auch als Impediments bezeichnet. Der Scrum Master besitzt dafür sein eigenes Impediments Backlog, was nur von ihm gepflegt wird[18]. Die dort enthaltenen Items werden, wie in einem Backlog üblich, nach geordneter Priorität angegangen und beseitigt.

Er agiert somit als eine Art Coach. Der Scrum Master ist gegenüber dem Team nicht weisungsbefugt und besitzt ebenfalls keine Autorität in Bezug auf die Arbeitsorganisation im Team. Er besitzt Einfluss um auf Probleme hinzuweisen und dadurch die Transparenz dieser zu stärken. Er arbeitet als Führungsfigur, deren Aufgabe ist es voll und ganz dem Team zu dienen. Aus diesem Grund wird die Stelle des Scrum Masters oft als Servant Leader bezeichnet[19].

6.2 Anforderungen

In diesem Kapitel werden die Anforderungen nach Scrum erläutert, welche zur Kommunikation zwischen den Teammitgliedern, Product Owner, Scrum-Master und Kunden von Nöten sind.

6.2.1 Product Backlog

Das Product Backlog ist das zentrale Element des Produktentwicklungsprozesses. Es ist "[...] die priorisierte Liste mit allen für das Produkt gewünschten Funktionalitäten"[20]. Unter Funktionalitäten fallen in dem Sinne des Product Backlogs nicht nur geänderte Anforderungen oder Features, sondern auch Fehler in der Software (sogenannten Bugs) oder organisatorische Tätigkeiten, wie die Erstellung und Inbetriebnahme einer neuen Test- und Entwicklungsumgebung. Alle Einträge werden nicht als klassische Anforderungen, sondern als User Stories formuliert und hinzugefügt.

Alle Stories werden zu Anfang des Projekts grob formuliert. Im Laufe des Projektes werden relevante Stories immer weiter verfeinert und detaillierter beschrieben. Dies ist ein elementarer Unterschied zu den traditionellen Anforderungsdokumenten. In diesen werden alle Anforderungen zu Anfang detailliert formuliert, unabhängig von ihrer Relevanz zu einem späteren Zeitpunkt des Projektverlaufs[21].

Das Product Backlog verändert sich während und mit dem Projekt. Es wird dauerhaft angepasst, indem User Stories hinzugefügt, modifiziert oder entfernt werden. Es wird einzig und allein vom zuständigen Product Owner gepflegt. Er übernimmt die Pflege und Priorisierung der einzelnen User Stories. Die Priorisierung erfolgt nach den Kriterien von Kosten, Nutzen und Risiken. Um Kriterien richtig einschätzen zu können, werden die einzelnen Stories mit dem Kunden (Kriterium: Nutzen) sowie mit dem Team (Kriterien: Kosten, Risiken) besprochen.

Pro Projekt existiert immer nur ein Product Backlog. Dieses bietet die Basis für jedes Sprint-Planning. Das Backlog sollte öffentlich und für alle Stakeholder dauerhaft zugänglich sein. Dadurch kann sich das Team einen Überblick über die nächsten Schritte verschaffen. Desweiteren wird dadurch die Transparenz gestärkt. Tabelle 1 zeigt ein beispielhaftes Product Backlog.

Priorität Bereich Beschreibung Akzeptanzkriterien Aufwand
1
 Premiumzugang Der Benutzer soll seinen Account durch einen Premiumzugang erweitern können Kreditkartendaten müssen bei Absenden des Formulars auf Gültigkeit überprüft werden
8
2
 Newsletter Der Redakteur soll die Möglichkeit besitzen einen Newsletter an alle Premiumkunden zu versenden Newsletter muss in Microsoft Outlook 2010, Google-Mail und Web.de identisch aussehen
5
3
 Registrierung Der Link zur Registrierung soll durch ein Bild prominenter auf der Startseite dargestellt werden
1
4
 News Der Benutzer soll eine Pressemeldung kommentieren können Kommentare von Spamrobottern müssen geblockt werden
3
Tabelle 1: Beispielhaftes Product Backlog

Ersichtlich ist, dass eine Sortierung nach der Priorität vorgenommen wurde. Neben dem Bereich und der eigentlichen User Story (s. Spalte 'Beschreibung') werden noch die Akzeptanzkriterien definiert. Diese müssen erfüllt sein, um die User Story als erledigt markieren zu können. Zeitgleich erweitern sie die allgemeine DoD um spezielle Eigenschaften einzelner Anforderungen. Die Spalte Aufwand enthält eine Schätzung in Form von Story Points. Dies ist eine fiktive Einheit, die den Vorgang der Aufwandsschätzung erleichtern sowie den klassischen Druck von Zeitschätzungen für die Teammitglieder nehmen soll.

6.2.2 User Stories

User Stories dienen zur Unterstützung des Anforderungsmanagements. Das Konzept wurde 2001 von Ron Jeffries, einem Begründer der Extreme Programming Bewegung, eingeführt[22]. User Stories beschreiben Softwareanforderungen, welche in Alltagssprache formuliert, von Sprint zu Sprint angepasst und verfeinert werden. So wie auch die Backlogs sind sie ein zentrales und flexibles Element, welche die Entwicklung des Produktstory repräsentiert.

Ein wichtiger Faktor für User Stories sind die sog. INVEST-Kriterien. INVEST steht dabei für:

Element Beschreibung
Indipendent Eine Story ist unabhängig von anderen Stories
Negotiable User Stories sind kein geschriebenes Gesetz. Kunden und Entwickler besprechen und präzisieren sie gemeinsam
Valuable Die Stories sollten einen erkennbaren Mehrwert liefern
Estimatable Eine Story muss so überschaubar sein, dass das Team die Umsetzung der Anforderung einschätzen kann
Small Über den konkreten Umfang von User Stories muss letztlich das Team entscheiden. Stories können „zu groß“ und „zu klein“ sein. Als grobe Regel gilt: Die komplette Umsetzung einer Story soll mindestens einen halben Personentag und maximal zehn Personentage erfordern.
Testable Eine Testbarkeit muss zwingend gewährleistet sein um die Story abschließen zu können
Tabelle 2: INVEST-Kriterien für erfolgreiche User Stories

Die User Stories werden innerhalb des Teams meistens auf Karteikarten festgehalten, um diese gemeinsam zu modifizieren. Die sogenannten Story Cards werden dann auf einem Whiteboard offen und für das gesamte Team sichtbar aufgehängt.

6.2.3 Aufwandsschätzungen

Um Aufwandsschätzungen durchzuführen, werden bei Scrum, entgegen der verbreiteten Einheit PT (Personentage) für Aufwandsschätzungen, die sogenannten Story Points eingeführt. Sie sind ein abstraktes und einfaches Mittel zur Definition des Aufwandes.

Punktewerte Semantik
0
 Kein Aufwand
1
 Sehr kleiner Aufwand
2
 Kleiner Aufwand: doppelt so groß wie ein sehr kleiner Aufwand
3
 Mittlerer Aufwand: so groß wie ein sehr kleiner und ein kleiner Aufwand zusammen
8
 Sehr großer Aufwand: so groß wie ein mittlerer Aufwand und großer Aufwand zusammen
13
 Riesiger Aufwand: so groß wie ein großer und sehr großer Aufwand zusammen
Tabelle 3: Story Points Staffelung

Die Punktereihe orientiert sich an der Fibonacci Folge, um zu verdeutlichen, dass mit steigendem Aufwand auch immer ein höheres Risiko bei der Umsetzung mitspielt. Das Team, welches die Schätzungen durchführt, kann leichter die Entscheidung zwischen fünf und acht Story Points also zwischen sechs oder sieben treffen.

Das Planning Poker ist die gängigste Methode solche Aufwandsschätzungen in so genannten Schätzklausuren durchzuführen[23]. Innerhalb dieser Meetings beschreibt der PO (Product Owner) die Anforderungen des Kunden an das Produkt und das Team schätzt gemeinsam die Story Points. Jedes Teammitglied erhält ein Set von Karten, dass auf einer Seite jeweils ein Story Point Wert stehen hat. Der Product Owner stellt die Anforderungen vor und bespricht mit dem Team gemeinschaftlich alle Unklarheiten. Im Anschluss legt jedes Teammitglied verdeckt die Karte mit dem Story Point Wert vor sich, den er für diese Anforderung definieren möchte. Nach gleichzeitigem Umdrehen werden die Werte herausgesucht, die am meisten voneinander abweichen. Die betreffenden Teammitglieder müssen nun ihre Wertung begründen. Im Anschluss kann entweder eine erneute Runde durchgeführt oder sich gemeinsam auf einen Wert geeinigt werden. Diese Vorgehensweise kann Probleme identifizieren und fördert die Zusammenarbeit im Team und die Beteiligung vermeintlich schwächerer Mitglieder. Der Scrum Master sorgt immer für einen geregelten Ablauf der Diskussionen.

6.3 Sprints

Die Kernelemente des Scrum Prozesses sind die Sprints. Mit Hilfe dieser immer wiederkehrenden Entwicklungszeiträume wird das Projekt iterativ und inkrementell entwickelt und ausgebaut[24]. Durch die von Anfang an definierte Länge bieten Sie die Möglichkeit Änderungen kostengünstig, flexibel und schnell in das zu fertigende Produkt einfließen zu lassen. Jeder Sprint hat im Optimalfall ein funktionstüchtiges Produktinkrement zur Folge, welches vom Kunden bereits gesichtet und getestet werden kann. Um dieses Ziel zu erreichen, besteht ein erfolgreich durchgeführter Sprint aus verschiedenen Teilen.

Im Sprint umzusetzende User Stories werden in der Sprint Planung (s. Kapitel 6.3.1) festgelegt. Während der bereits geplanten Iteration werden die Projektbeteiligten durch das Daily Scrum (s. Kapitel 6.3.2) auf den aktuellen Stand gebracht und können durch die Burndown Charts (s. Kapitel 6.3.5) den Sprintfortschritt ablesen. Abschließend werden die erzielten Ergebnisse im Sprint Review Meeting (s. Kapitel 6.3.3) vorgestellt und die Zusammenarbeit in der nachfolgenden Sprint Retroperspektive (s. Kapitel 6.3.4) analysiert.

6.3.1 Sprint Planung

Ein Sprint hat immer ein vorher definiertes Sprintziel, welches in der Sprint Planung ausgearbeitet wird. Aus diesem Ziel erschließt sich für das Team sowie dem Kunden einen klaren Mehrwert des Produktes und bringt somit das Gesamtziel auf den richtigen Weg. Auf Grund der Priorisierung im Product Backlock bringt der Product Owner die Anforderungen, welche im Sprint angegangen werden sollen, dem Team näher. Jede Anforderung wird im Team besprochen und entschieden, wie viele Funktionen dann eingeplant werden. Aus der Besprechung können sich auch Anpassungen an die aus dem Product Backlog ergebenen Story Points ergeben.

6.3.2 Daily Scrum

Das Daily Scrum ist ein Meeting, was an jedem Projekttag zu einer festen Uhrzeit (in der Regel morgens) und an einem festen Ort stattfindet. Ort und Zeit tragen dazu bei dieses Meeting als regelmäßige Zeremonie anzusehen und so zu behandeln. An dieser Besprechung nehmen Scrum Master, Product Owner und das Team teil. Es ist auf eine Dauer von 15 Minuten begrenzt und wird vom Scrum Master moderiert. Durch die begrenzte Zeitangabe stehen drei zentrale Fragen im Raum die von jedem Teammitglied beantwortet werden müssen:

  1. Was habe ich seit dem letzten Daily Scrum erreicht?
  2. Was plane ich bis zum nächsten Daily Scrum zu erreichen?
  3. Welche Hindernisse behindern mich um das angestrebte Ziel zu erreichen?

Um die angestrebten 15 Minuten nicht zu überschreiten, ist es maßgeblich, dass die Mitglieder die vorgegebenen Fragen kurz und knapp beantworten. Dazu ist eine Vorbereitung der einzelnen Teammitglieder von Nöten. Jedes Teammitglied sieht im täglichen Daily-Scrum, ob die vorherigen angestrebten Ziele erreicht wurden. Der Scrum Master hat für die Einhaltung des Zeitabschnitts Sorge zu tragen (Timeboxing). Das Meeting dient nicht dazu, Probleme zu besprechen und Lösungen zu finden, sondern diese aufzuzeigen. Diese Impediments werden vom Scrum Master erfasst und im Anschluss beseitigt.

Durch dieses wichtige Ritual wird die Transparenz im Projektteam gestärkt und es trägt einen großen Teil zur Selbstorganisation bei. Jeder Beteiligte wird somit über den aktuellen Status informiert und weiß, was noch zu tun ist. Das Daily Scrum wird desöfteren auch als Stand-Up-Meeting bezeichnet. Dies kommt daher, da viele Projektteams dieses Meeting im Stehen abhalten. Diese Vorgehensweise versucht, die Aufmerksamkeit der Teilnehmer auf das Meeting zu lenken.

6.3.3 Sprint Review

Das Print Review Meeting wird am letzten Tag des Sprints gehalten und zeigt allen Beteiligten, ob das Sprintziel erreicht wurde oder nicht. Es werden alle aus dem Sprint Backlog definierten Anforderungen abgearbeitet und jede Funktion getestet. Der Product Owner entscheidet nach den Tests, ob die Anforderungen zu 100% erfüllt sind. Falls Bugs vorkommen oder Funktionen nur minimal von den besprochenen Beschreibungen abweichen, gelten sie als nicht erfüllt. Scrum erlaubt keine Abweichungen und lässt nur fehlerfreie Anwendungen zu. Fehlerhafte Funktionen werden dem Product Backlog hinzugefügt und direkt im nächsten Sprint mit eingeplant.

6.3.4 Sprint Retrospektive

Die Retrospektive wird direkt im Anschluss an das Sprint Review Meeting durchgeführt und lässt das Team die Leistung reflektieren. Grundfragen, die besprochen werden, sind:

  • Was ist gut gelaufen?
  • Was ist schlecht gelaufen und sollte im nächsten Sprint verbessert werden?

Dieser Rückblick hilft, die Qualität zukünftiger Sprints enorm zu steigern. Der Austausch der Teammitglieder wird vom Scrum Master dokumentiert. Die gesammelten Erkenntnisse sind die Basis für die Beseitigung von Hindernissen innerhalb des Teams und des Projekts.

6.3.5 Burndown Charts

In Anlehnung an: Invisible city productions (2011), http://www.invisible-city.com/ (09.06.2011, 14:19)Abb. 2: Sprint Burndown Chart
In Anlehnung an: Invisible city productions (2011), http://www.invisible-city.com/ (09.06.2011, 14:19)
Abb. 2: Sprint Burndown Chart

Burndown Charts sind im Scrum Prozess ein wirkungsvolles Mittel, welches zur Visualisierung des Projektfortschritts genutzt wird. Es stellt den zeitlichen Projektverlauf anhand der zuvor definierten User Stories dar. Durch das gefüllte Product- sowie Sprint Backlog wird definiert, welche Aufgaben in welchen Zeiträumen erledigt werden.

Grundsätzlich existieren zwei Arten von grafischen Darstellungen: Sprint - und Release-Burndown Charts. Der Unterschied liegt in den verwendeten Daten. Ein Sprint-Burndown Chart nutzt als Basis die Daten aus dem Sprint-Backlog, wohingegen das Release-Burndown Chart die Daten des Product Backlogs verwendet. Auf einem solchen Chart wird die Anzahl an Story Points in Relation mit der Zeit gesetzt. Dies ergibt eine lineare Darstellung der bereits verbleibenden sowie bereits fertigen Aufwände. Die Summe der Story Points von erledigten User Stories innerhalb eines Sprints wird als Velocity bezeichnet. Anhand dieser Kennzahl wird die Entwicklungsgeschwindigkeit des Teams gemessen. Bei einer Verbesserung der Abläufe sowie der Teamarbeit steigt die Velocity. Durch eine solche Darstellung des Projekt- oder Sprintstatus ist leicht zu erkennen, ob die gesteckten Ziele planmäßig erreicht werden können.

Abb. 2 stellt ein Sprint-Burndown Chart dar. In diesem zehntägigen Sprint sollen 90 Story Points abgearbeitet werden. Die blaue Linie stellt einen optimalen / geplanten Verlauf des Sprints dar (idealer Burndown). Die rote Linie spiegelt den realen Verlauf der Arbeiten wieder. Durch die Verwendung beider Graphen innerhalb eines Diagramms sind Abweichungen sehr schnell zu erkennen. Diese können zum Beispiel durch noch nicht beseitigte Impedents entstehen. Ersichtlich ist, dass der Sprint-Start problemlos verlief. Das Team konnte schnell und effizient verschiedene User Stories als fertig markieren. Durch ein mögliches Impedent konnte der überdurchschnittliche Projektfortschritt zwischen Tag drei und fünf nicht gehalten werden. In diesem Zeitrahmen widmeten sich die Teammitglieder anderen noch nicht fertiggestellten User Stories. Durch die Beseitigung des Hindernisses konnten die entsprechenden User Stories als erledigt markiert werden, was eine erneute Unterschreitung des ideal-Burndowns an Tag acht zur Folge hatte. Das Resultat dieses erfolgreichen Sprints war ein weiteres lauffähiges Produktinkrement sowie eine Velocity von 90.

Der Unterschied in der Darstellung eines Release Burndown Charts ist die Angabe von Sprints anstatt von Tagen auf der X-Achse. Zugleich wird die Summe aller Story Points aus dem Product Backlog für die Y-Achse verwendet.

Burndown Charts spielen in Meetings, die während eines Scrum Projekts durchgeführt werden, eine wichtige Rolle. Probleme innerhalb eines Sprints, die im Sprint-Burndown-Chart ersichtlich sind, werden in der Sprint-Restrospektive diskutiert. Desweiteren ist der Product Owner für tagesaktuelle Charts verantwortlich. Diese werden in der Praxis oft innerhalb Daily Scrum verwendet. Sie geben allen Beteiligten einen schnellen Überblick über den Fortschritt und sind dadurch ein wichtiges Mittel für die Anwendung von Scrum.

7 Analyse von Scrum

In diesem Kapitel wird mit Hilfe bestimmter Bewertungskriterien eine Analyse zur Bewertung der Effektivität und Effizienz von Scrum als agilen Softwareentwicklungsprozess durchgeführt.

7.1 Bewertungskriterien

Die Bewertungskriterien werden in Kapitel 7.1.1 bis 7.1.7 definiert und erläutert, bevor in Kapitel 7.2 die Bewertung und Gesamtbetrachtung (s. Kapitel 7.3) dargelegt werden.

7.1.1 Personal

Das Personal spielt eine wichtige Rolle unabhängig vom Projektmanagementverfahren. Dargelegt wird, ob der Personalaufwand höher ist als bei klassischen Modellen und inwiefern die Bestimmung und Wahl der Teammitglieder von Belang ist. Desweiteren wird bewertet, inwiefern sich der Personalaufwand in Bezug auf Kundenzufriedenheit und Produktivität für ein positives Endergebnis rechtfertigen.

7.1.2 Kommunikationsaufwand

Kommunikationsaufwände spielen in der Softwareentwicklung sowie in Entwicklungsprozessen eine große Rolle. Um Missverständnisse, die unter Umständen zu einem hohen Kostenfaktor werden können, auszuschließen, muss effektiv und wiederkehrend mit den Projektbeteiligten kommuniziert werden.

Es wird untersucht, wie hoch der Kommunikationsaufwand bei einem angewandten Scrum Prozess ist und in welcher Form er stattfindet. Desweiteren wird analysiert, ob geregelte Kommunikationsabläufe vorhanden sind und ob der Aufwand in einer Kosten-Nutzen-Relation steht. Zusätzlich wird betrachtet, in welcher Form die Kommunikation Einfluss auf die Arbeit des Teams hat.

7.1.3 Regelwerk

Jede Methodik, die das Management komplexer Projekte unterstützt, stellt ein gewisses Regelwerk zur Verfügung. Dies geschieht unabhängig, davon ob es sich um ein Management-Framework, ein Management-Modell oder um einen komplett vorgegebenen Management-Prozess handelt. Das Regelwerk ist ein signifikanter Teil des verwendeten Verfahrens und die Einhaltung dessen bestimmt in der Regel über Erfolg oder Misserfolg des Projekts. Zugleich ist es einer der Hauptmerkmale, durch das sich verschiedene Managementmethoden unterscheiden.

In dieser Bewertung soll das Regelwerk von Scrum analysiert werden. Es wird untersucht, wie es definiert ist und was speziell bei der Anwendung zu beachten ist. Es wird auf die Frage eingegangen, ob es besondere Merkmale vorweisen kann undinwie weit es den einzelnen Projektbeteiligten den zu bewältigten Weg vorgibt. Zusätzlich wird die Größe sowie die Alltagstauglichkeit beurteilt.

7.1.4 Projektumgebung

Unabhängig vom Verfahrensmodell spielt die räumliche Projektumgebung, in der Produkte entwickelt werden, eine eher unterbewusste Rolle. Dennoch ist sie als sehr wichtig anzusehen, die Entwicklung erfolgreicher Produkte erfordert Kreativität und Innovation. Abhängig vom Verfahrensmodell ist es wichtig zu wissen, wie die Projektumgebung bezüglich des Personals strukturiert ist. Je nach Größe des Projekts ist es von hoher Wichtigkeit, effizient in einem internationalem Team arbeiten zu können.

In dieser Bewertung wird darauf eingegangen, welche Bedingungen von Arbeitgeberseite erfüllt sein sollten, um einen effizienten Arbeitsablauf zu gewährleisten. Desweiteren wird untersucht, in wie weit Scrum für dein Einsatz dezentraler Teams geeignet ist.

7.1.5 Kosten

Die Kosten gehören zu den wichtigsten Faktoren bei einer Produktentwicklung. Je höher diese Ausfallen, desto später wird der break even point erreicht. Der Kostenpunkt der verwendeten Managementmethode trägt dazu einen beachtlichen Teil bei. Prinzipiell wird dabei zwischen zwei verschiedenen Kostenarten unterschieden. Einführungskosten fallen einmalig an, wohingegen die Kosten zur alltäglichen Nutzung wiederkehrend ist. Desweiteren spielen die Kosten, die zur direkten Anforderungsumsetzung gehören, eine sehr große Rolle.

Es wird untersucht, welche Kosten die Einführung sowie die alltägliche Nutzung von Scrum erzeugen. Weiterhin wird die Art und Weise analysiert, in welcher Form die Kosten zur Produktentwicklung genutzt werden. Zusätzlich findet eine Bewertung der möglichen Regulierung und der vorhandenen Transparenz statt.

7.1.6 Erfolgschancen

Projekte werden wegen ihrer erhofften (wirtschaftlichen) Erfolge geplant und realisiert. Managementmethoden werden nach ihren Erfolgschancen bewertet, ausgewählt und angewandt. Jeder Management-Prozess beinhaltet andere Faktoren, die den Vorgang mit niedrigeren oder höheren Erfolgschancen ausstatten. Durch Projektmisserfolge entstehen nicht nur erhebliche finanzielle Verluste, auch die Motivation der Projektbeteiligten sinkt dadurch stetig. Agile Managementmethoden besitzen den Ruf, eine größere Erfolgschance als klassische Verfahren zu besitzen.

In dieser Bewertung soll analysiert werden, welche die entscheidenden Faktoren sind, und welche Bedingungen erfüllt sein müssen, um ein Scrum Projekt erfolgreich steuern und zum Abschluss bringen zu können. Anschließend wird untersucht, wie hoch die Erfolgschance von Projekten ist, die mittels Scrum durchgeführt werden im Vergleich zu klassischen Projektverfahren.

7.1.7 Kundenzufriedenheit

Neben dem wirtschaftlichen Wert und Erfolg eines Projekte spielt die andauernde und abschließende Kundenzufriedenheit eine große Rolle. In klassischen Vorgehensmodellen ist es oft der Fall, dass das Resultat des Projektes nicht die Erwartungen der Kunden zu dem Zeitpunkt der Fertigstellung entspricht. Dies wirkt sich nicht selten negativ auf die Kundenzufriedenheit aus. Gerade bei der Durchführung durch ein Dienstleistungsunternehmen spielt diese jedoch eine entscheidende Rolle. Dort ist die Kundenzufriedenheit ein wichtiges Kriterium bei der Auswahl der Partner für zukünftige Projekte.

In dieser Bewertung wird die Kundenzufriedenheit im Scrum Prozess untersucht. Es wird analysiert, inwieweit die Kundenzufriedenheit eine Rolle spielt und ob darauf eingegangen wird. Sie wird weitestgehend unabhängig vom Ausgang eines Projektes analysiert, da in der Regel Erfolg oder Misserfolg über die abschließende Kundenzufriedenheit bestimmen.

7.2 Bewertung

Im nachfolgenden Kapitel werden die definierten Bewertungskriterien in Bezug auf Scrum analysiert und bewertet.

7.2.1 Personal

Anders als bei anderen agilen Prozessmodellen, wie Crystal Clear oder XP (Extreme Programming) werden feste Rollen bei der Personalstruktur definiert. Es braucht einen Product Owner, einen Scrum Master und das Team. In klassischen Verfahrensmodellen werden lediglich ein Projektmanager und ein Team benötigt. Die Rolle des Scrum Masters ist einzig und allein für die Prozessimplementation von Scrum vor Ort. Somit besteht ein erhöhter Personalaufwand gegenüber traditionellen Projektmanagementmethoden.

Die Wahl der richtigen Personen für die entsprechenden Rollen ist auch in Scrum maßgeblich für den Ausgang des Projektes. Die Anzahl der Projektbeteiligten spielt ebenfalls eine große Rolle, je größer die Zahl desto mehr Managementaufwand entsteht. Ein ganz besonderes Augenmerk sollte hier die Größe des Teams besitzen. Ab einem gewissen Punkt (Team größer neun Personen) steigt die Kommunikation sowie die Verwaltung des Teams in Relation zu dem Ergebnis erheblich an. Wichtig ist, dass alle Teammitglieder freiwillig dabei sind. Sie sollten sich ihre Projekte selbst aussuchen können. Das setzt Vertrauen der Manager und Verantwortungsbewusstsein der Mitarbeiter voraus. Andererseits wird dadurch die Motivation der einzelnen Teammitglieder enorm gefördert. Dies resultiert in qualitativer Software und erhöhtem Ehrgeiz die vorgegebenen Ziele zu bewältigen.

Der stetige Dialog durch viele wiederkehrende Meetings erhöht die Flexibilität und gibt dem Kunden größtmögliches Feedback und Transparenz über sein neues Produkt. Auch die Produktivität steigert sich enorm, da sich das Team auch während des Prozesses immer mehr aufeinander und auf den Kunden einstellen kann.

Der erhöhte Personalaufwand durch die zusätzliche Person (Scrum Master) allein gilt als negativ zu bewerten. Dennoch wird dieser Kritikpunkt durch die Erfolgschancen, das qualitative Ergebnis sowie dem Fakt, dass der Scrum Master nur für die Einführung zu 100% wichtig ist, wieder ausgeglichen.

7.2.2 Kommunikationsaufwand

Der Kommunikationsaufwand ist im Gegensatz zu alternativen Prozessmodellen eher hoch. Die Kommunikation von Teammitgliedern, Poduct Owner und Scrum Master wird durch den Scrum-Prozess genau geregelt und vom Scrum-Master innerhalb des Projekts umgesetzt. Zu den Zeremonien, die einen großen Teil zur Kommunikation im Scrum Prozess beitragen, gehören das Daily Scrum, das Sprint Planning Meeting, das Sprint Review Meeting, die Sprint Retrospektive sowie die wiederkehrenden Workshops mit den Kunden zur Aktualisierung der Anforderungen.

Jedoch werden die Aufwände durch das Ergebnis gerechtfertigt. Durch die stetige Kommunikation kann das Team schneller Hindernisse erkennen und diskutieren. Durch regelmäßige und wiederkehrende Meetings wird der Projektablauf und der aktuelle Stand sofort sichtbar. Darin liegt auch der große Vorteil für den Kunden, da dieser auf das höchste Maß an Transparenz zurückgreifen kann. Der Kunde kann sich schon in einer frühen Phase der Entwicklung mit dem Produkt identifizieren oder schnell Änderungen durchbringen. Weiterhin fühlt sich das Team stärker für das Produkt verantwortlich und versucht die bestmögliche Produktivität sowie Qualität umzusetzen.

Als Kommunikationsform wird bei Scrum meist auf analoge Mittel zurückgegriffen. White Board und Karteikarten sind wichtige Werkzeuge. Anforderungen werden auf Karteikarten vermerkt und können somit schnell und einfach Veränderungen am Whiteboard sichtbar machen. Dies gilt jedoch nur für lokale Teams. Dezentrale Teams, wie sie bei Scrum nicht selten der Fall sind, organisieren sich in der Regel über ein Software-Produkt (z.B. Agilo for Scrum[25]), damit alle Teams mit den gleichen Informationen versorgt werden.

Trotz des hohen Kommunikationsaufwandes ist die Art und Weise wie mit der Informationsübermittlung umgegangen wird, positiv zu bewerten.

7.2.3 Regelwerk

Als agiles Management-Framework "[...] ist [Scrum] kein fertiger Prozess, sondern ein Rahmen, in den Entwicklungsteams ihre eigenen und bewährten Entwicklungspraktiken einbetten"[26]. Es beinhaltet keine Verfahrensweisen und fördert dadurch die Kreativität der Mitarbeiter. Wie schon im Kapitel Vorstellung von Scrum beschrieben, wurde das Regelwerk von der Größe her an die Sportart Rugby angelehnt und wurde dementsprechend mit wenigen Regeln bestückt. Dies alleine ist sehr positiv zu werten, da zum einen den Projektbeteiligten kein starrer Prozess, sondern ein flexibles Umfeld zur Verfügung gestellt wird. Zum anderen ist die geringe Anzahl an Regeln erfreulich. Eine kleine Anzahl von Regulierungen trägt zu einer schnelleren Verinnerlichung der einzelnen Anweisungen bei. Die Vergesslichkeit wird dadurch gemindert.

Als eine agile Methodik bezieht Scrum einen Teil des Regelwerks aus dem agilen Manifest[8]. Die dort verkörperten Werte tragen maßgeblich dazu bei, dass sich jeder Projektbeteiligte mit dem zu entwickelnden Lösung identifizieren kann und sich als ein Teil eines starken und produktiven Teams ansieht. Die damit verbundene Anerkennung bei erfolgreichen Sprints und erreichten Zielen stärkt die Motivation und das strebt nach weiteren Erfolgen. Der Ansatz des agilen Manifests sowie die Integration in Scrum stechen als positive Merkmale heraus.

Die Anwendung der Regeln des Scrum Prozess ist ein Lernprozess und gilt zu Anfang als sehr schwierig. Dabei müssen alle Beteiligten nicht nur die neuen Spielregeln erlernen, sondern auch alte Angewohnheiten ablegen[27]. Dies betrifft mehrere Bereiche. Die Zeremonien müssen bezüglich ihrer Uhrzeit und ihrer Länge (Timeboxing) eingehalten werden. Programmierer, die in der Regel einen Hang zum Perfektionismus besitzen, müssen das Erstellen von qualitativ minderwertiger Software erlernen, um Sprintziele nicht zu gefährden. Dieser Lernprozess kostet Zeit und Geduld. Dies ist ein negativer Punkt aus diesem Prozess, da die meisten Projekte knappe Deadlines besitzen. Meist kann die Lernzeit nicht in vollen Zügen ausgeschöpft werden und es unterlaufen Fehler, die bei ausreichender Zeit zu vermeiden gewesen wären. Wie wichtig jedoch das Regelwerk ist, wird durch die Rolle des Scrum Masters widergespiegelt. Eine Position, die dafür geschaffen wurde, um auf die Einhaltung des Regelwerks zu achten. Durch diese positiv eingestufte Rolle wird das Team im Hinblick auf das Regelwerk von Scrum durch eine in der Regel geschulte und zertifizierte Position unterstützt.

Die Alltagstauglichkeit ist abhängig von dem bereits funktionierenden Zusammenspiel des Teams. Mit der Zeit verbessern sich die Prozesse, das Team wird produktiver und es werden weniger Fehler gemacht. Die anfänglichen Fehler werden durch die spätere Produktionssteigerung wieder ausgeglichen. Somit ist eine Alltagstauglichkeit durchaus gegeben.

7.2.4 Projektumgebung

Um die Kommunikation zwischen den Beteiligten während des Projektverlaufs zu fördern, ist es sinnvoll das Team, den Product Owner und den Scrum Master räumlich nicht zu trennen. Einzelne Büros stellen ein Hindernis für den Kommunikationsfluss da. Ein großes Büro mit Schreibtischgruppen wäre eine fördernde Maßnahme und im Scrum Prozess von enormen Vorteil. Um die Projektumgebung optimal zu halten, sollten die einzelnen Personen ihren Verantwortungsbereichen nachkommen. Dazu zählt die stetige Anwesenheit des Product Owners sowie des Scrum Masters um Ablaufpläne von Prozessen nicht zu verzögern oder die tägliche Aktualisierung der Burndown Charts.

Scrum ist auch in Bezug auf dezentrale und sehr große Teams nutzbar. Bei Teams größer als neun Personen besteht die Möglichkeit, diese in mehrere Teams zu unterteilen, welche alle eigene Sprints durchführen. Bei großen internationalen Teams ist es möglich, sogenannte Scrum in Scrum-Prozesse aufzubauen. Dies ermöglicht eine Produktentwicklung über Kontinente hinweg. Dabei werden reguläre Scrum-Prozesse für einzelne Sub-Projekte durchgeführt. Die Product Owner der einzelnen Sub-Projekte tauschen sich regelmäßig über den Status aus. Dieses Vorgehen ist jedoch ein komplexer Managementvorgang und nicht einfach. Dennoch trägt diese Fähigkeit dazu bei, dass Scrum für alle Arten von Projekten geeignet ist.

7.2.5 Kosten

Kosten entstehen bei der Einführung von Scrum in ein Unternehmen oder ein Projektteam in mehreren verschiedenen Arten. Materielle Kosten fallen bei der initialen Anschaffung von Literatur, Karteikarten und Whiteboards an. Diese Art stellt allerdings kleinere Kosten dar. Eine weitere Kostenart, welche nicht sofort ersichtlich wird, ist die Einarbeitungszeit. Ein Team muss sich an das neue Verfahren gewöhnen. Dies kostet zu Anfang Zeit, da bei nicht Einführung von Scrum zu diesem Zeitpunkt schon mit der Produktentwicklung begonnen werden kann (Opportunitätskosten). Mitarbeiterschulungen sind dort hilfreich, erzeugen jedoch abhängig von der Größe des Teams, hohe Kosten. Weiterhin ist es möglich den Scrum Master zu einem CSM (Certified ScrumMaster) sowie den Product Owner zu einem CSPO (Certified Scrum Product Owner) zertifizieren zu lassen[28]. Die Kosten zur alltäglichen Nutzung von Scrum sind nicht höher als bei anderen Verfahrensmodellen.

Die bei der Produktentwicklung entstehenden Kosten werden durch den Einsatz von priorisierten Backlogs optimal genutzt. Anhand der stetig aktualisierten Listen werden die Anforderungen mit dem meisten Mehrwert am ehesten umgesetzt. Eine Regulierung dieser Kosten ist ebenfalls zu jederzeit möglich. Das Team ist dafür verantwortlich, nach jedem Sprint ein lauffähiges Produkt zur Verfügung zu stellen. Somit besteht die Möglichkeit nach jedem Sprint mit einem nutzbaren Resultat die Kosten zu regulieren. Desweiteren werden dadurch die Kosten für den Kunden sehr transparent gehalten. Es ist jederzeit ersichtlich, welche Kosten für welche Anforderung verwendet wurden.

Alles in allem ist die Kostenstruktur von Scrum sehr gut geregelt. Initiale Kosten können niedrig gehalten werden, alltägliche Kosten entstehen bei dem Einsatz anderer Modelle in gleicher Höhe und Aufwendungen, die zur direkten Produktentwicklung genutzt werden, sind transparent abrufbar.

7.2.6 Erfolgschancen

Die entscheidenden Faktoren, die erfüllt sein müssen um ein Projekt mit Scrum erfolgreich durchführen zu können, teilen sich in zwei Bereiche. Es ist durchweg wichtig, das kleine vorhandene Regelwerk strikt einzuhalten. Die vorgegebenen Methoden und Paradigmen von Scrum sind so aufgebaut, das es nach einer gewissen Einführungszeit mit Freude eingesetzt wird. Es wird nicht bloß angewandt, es wird gelebt. Jeder Projektbeteiligte weiß genau, zu welchem Zeitpunkt an welchem Ort die nächste Besprechen stattfindet, wie und wo das Projekt gerade steht oder wer welche Aufgabe umsetzt. Hierarchielose Strukturen tragen zusätzlich dazu bei, sich weniger über die getroffenen Entscheidungen aufzuregen, da im Scrum Prozess daran teilgenommen wird. Der zweite wichtige Faktor ist die optimale Besetzung des Teams. Das Team muss kompetent sowie den gestellten Aufgaben gewachsen sein. Es muss durch seine interdisziplinäre Struktur die optimalsten Lösungswege finden und implementieren. Das Teamwork muss gut sein und sich stetig verbessern. Dies sind Grundlagen für erfolgreiche Projekte mit Scrum.

Eine Online-Umfrage der Otto-von-Guericke-Universität Magdeburg hat ergeben, dass 32% der Projekte, die mit agilen Praktiken durchgeführt wurden, nicht erfolgreich waren. Ein Großteil der fehlgeschlagenen Projekte ist auf ein Team mit mehr als acht Mitgliedern zurückzuführen[29]. Dies zeichnet indirekt eine Überschreitung der definierten Teamgröße aus. Eine andere Studie der Firma oose Innovative Informatik GmbH zeigt ähnliche Ergebnisse. Sie zeigt, dass 67% aller agilen Projekte erfolgreich waren. Wohingegen die klassische Vorgehensweise nur zu 40% erfolgreicher Projekte führte[30].

Ein weiterer Punkt, der die Erfolgschancen von Scrum-Projekten erhöht, ist die Anwendung von kurzen und wiederholbaren Entwicklungsiterationen. Durch Sprints wird eine frühere Marktreife des Produktes erzielt. Dies belegt auch eine Studie der Firma VersionOne aus dem Jahre 2008. Diese besagt, dass 41.3% der Befragten die Time to market Ihres Produktes verbessern und 23,6% der Studienteilnehmer erheblich verbessern konnten[31].

Alles in allem sind die Erfolgschancen bei Projekten, die mittels der Scrum-Verfahrensweise durchgeführt werden, sehr gut und allgemein höher als bei klassischen Management Verfahren.

7.2.7 Kundenzufriedenheit

Die Kundenzufriedenheit spielt in der Scrum-Terminologie eine große Rolle. Durch die Anwendung des agilen Manisfests[8] wird diese dauerhaft gefördert. Der dritte Grundsatz des Manifests, Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung, beschreibt das, was in Scrum gelebt wird. Der Kunde wird sehr stark in den kompletten Entwicklungsprozess mit eingebunden, dadurch ist er dauerhaft auf dem aktuellsten Stand und trägt seinen Teil zum Ausbau des Produkts bei. Durch die Kernelemente von Scrum, die sogenannten Sprints, wird den Shareholdern recht früh eine erste und nutzbare Version des Produkts zur Verfügung gestellt. Dadurch werden erste Resultate in einem sehr kurzen Zeitraum erreicht, was sich in der Regel positiv auf die Kundenzufriedenheit auswirkt.

Schwerfällige und langwierige Prozesswege, wie sie teilweise in klassischen Prozessmodellen verwendet werden, finden in agilen Vorgehensmodellen keine Verwendung. Scrum wird sehr oft in Verbindung mit lean Management, den sogenannten schlanken Managementprozessen, gebracht. Die dadurch entstehende Flexibilität durch kurze Wege spiegelt sich ebenfalls in der Kundenzufriedenheit wieder.

Ralf Wirdemann beschreibt in seinem Buch, "[...] wie sich das sogenannte Kano-Modell für die Bewertung von Kundenzufriedenheit und damit auf die Priorisierung von User Stories anwenden lässt"[32]. Das Modell, beschreibt, wie sich Features unterschiedlicher Klassen auf die Kundenzufriedenheit bei der Produktentwicklung auswirken. In Wirdemanns Interpretation wird das Modell von Dr. Noriaki Kano auf User Stories innerhalb des Product Backlogs bezüglich der Priorisierung und Umsetzung angewandt. Durch die korrekte Anwendung wird instinktiv mögliche Unzufriedenheit des Kunden verhindert.

Es ist ersichtlich, dass das Thema Kundenzufriedenheit eine entscheidende Rolle spielt. Dies ist als sehr positiv zu bewerten.

7.3 Gesamtbetrachtung

In der Gesamtbetrachtung dieser Bewertungen wird ersichtlich, dass sich bei Scrum auf allen untersuchten Punkten (Personal, Kommunikationsaufwand, Regelwerk, Projektumgebung, Kosten, Erfolgschancen und Kundenzufriedenheit) ein von Grund auf positives Resümee ziehen lässt. Die wenigen negativen Aspekte werden durch erzielte Resulte ausgeglichen.

Der erhöhte Personalaufwand wird durch das qualitative Ergebnis sowie der Produktivität ausgeglichen. Der erhöhte Kommunikationsaufwand fällt ebenfalls negativ auf. Jedoch wird dieser durch die hohe Anzahl an Meetings und der gesteigerten Transparenz und Kundenzufriedenheit innerhalb es Projekts ausgeglichen. Das Regelwerk ist bewusst sehr klein gehalten und auf grundlegende Paradigmen anstatt auf starre Prozessstrukturen ausgelegt. Eine spezielle Projektumgebung wird für die Verwendung von Scrum nicht benötigt. Einzig ein Großraumbüro oder ähnliches wäre für die Kommunikationsförderung sinnvoll. Die entstehenden Kosten durch die Einführung von Scrum halten sich im Rahmen. Für den Kunden werden Kosten bestimmbar und transparent dargelegt. Die Erfolgschancen wurden durch verschiedene Statistik bewiesen und sind somit höher als bei klassischen Anwendungsmodellen. Die Kundenzufriedenheit steigt durch vermehrte Integration des Auftraggebers.

8 Fazit

Diese Fallstudie zum Thema Beschreibung und Analyse von SCRUM zeigt deutlich, dass die Anwendung von Scrum in modernen Projekten durchaus gerechtfertigt ist. Durch die Flexibilität von Scrum ist die gestiegene Komplexität von Projekten abbildbar und umsetzbar. Die Grundsätze und Werte des agilen Manifests werden konsequent integriert. Alle Projektbeteiligten spüren die Wichtigkeit ihrer Person. Dies stärkt den gesamten Prozess.

Der Fokus von Scrum liegt klar bei den Themen Transparenz und Flexibilität. Diese werden für alle Beteiligten im Scrum-Prozess spürbar und daraus resultieren positive Ergebnisse und eine erhöhte Kundenzufriedenheit. Dennoch fordert die Anwendung von Scrum eine starke Unterstützung und Vertrauen des höheren Managements. Dies ist zugleich einer der wichtigsten Fallstricke bei der Integration von Scrum in ein bestehendes Team.

Der praktische und erprobte Einsatz von Scrum in großen Unternehmen wie Google, IBM oder Toyota unterstützt das Ergebnis dieser Fallstudie. Scrum ist ein ehrenwerter Kandidat, um die Verwendung agiler Softwareentwicklungsmodelle weiter zu fördern. Denn durch diese lassen sich komplexe Anforderungen in modernen Projekten problemlos abbilden. Die Verwendung agiler Managementmethoden wie Scrum wird in Zukunft weiter ansteigen.

9 Fußnoten

  1. ↑ "Scrum accepts that the development process is unpredictable. The product is the best possible software, factoring in cost, functionality, timing, and quality" übersetzt von Gloger (2009), Seite 17, nach Schwaber (1996)
  2. ↑ Vgl. Takeuchi und Nonaka (1986)
  3. ↑ Vgl. Schwaber (1996)
  4. ↑ 4,0 4,1 Vgl. Pichler (2008), Seite 1
  5. ↑ Vgl. Wirdemann (2009), Seite 26
  6. ↑ Vgl. Scrum Alliance (2011), http://www.scrumalliance.org/pages/what_is_scrum (02.06.2011, 11:10)
  7. ↑ Vgl. Pichler (2008), Seite 2
  8. ↑ 8,0 8,1 8,2 8,3 Vgl. Beck (2001)
  9. ↑ Vgl. Wirdemann (2009), Seite 155
  10. ↑ Vgl. Picher (2008), Seite 10
  11. ↑ Vgl. Wirdemann (2009), Seite 44
  12. ↑ 12,0 12,1 Vgl. Pichler (2008), Seite 11
  13. ↑ 13,0 13,1 Vgl. Dogs und Klimmer (2005), Seite 105
  14. ↑ Vgl. Tuckman (1965), Seite 384-399
  15. ↑ Vgl. Gloger (2009), Seite 65
  16. ↑ Vgl. Wirdemann (2009), Seite 37
  17. ↑ Vgl. Pichler (2008), Seite 16
  18. ↑ Vgl. Gloger (2009), Seite 87
  19. ↑ Vgl. Greenleaf (2002)
  20. ↑ Cohn (2010), Seite 183
  21. ↑ Vgl. Pichler (2008), Seite 28
  22. ↑ Vgl. Jeffries (2001)
  23. ↑ Vgl. Cohn (2006)
  24. ↑ Vgl. Wirdemann (2009), Seite 26
  25. ↑ agile42 GmbH (2011)
  26. ↑ Wirdemann (2009), Seite 27
  27. ↑ Pichler (2008), Seite 2
  28. ↑ Vgl. Scrum Alliance (2011), http://www.scrumalliance.org/pages/scrum_certification (05.06.2011, 19:18)
  29. ↑ Vgl. Günther, Huber und Lindenhahn (2008), Seite 13.
  30. ↑ Vgl. Vigenschow, Toth und Wittwer (2009), Seite 13
  31. ↑ Vgl. VersionOne (2008), Seite 8
  32. ↑ Wirdemann (2009), Seite 107

10 Literatur- und Quellenverzeichnis

Verweis Literatur / Quelle
agile42 GmbH (2011) agile42 GmbH: Agilor for Scrum, 2001, http://www.agile42.com/agilo/ (09.06.2011, 17:19)
Beck (2001) Beck, Kent: The Manifesto for Agile Software Development, Agile Alliance, 2001, http://www.agilealliance.org/the-alliance/the-agile-manifesto/ (31.05.2011, 21:23)
Cohn (2006) Cohn, Mike: Agile estimating and planning, Prentice Hall Professional Technical Reference, 2006
Cohn (2010) Cohn, Mike: User Stories: Für die agile Software-Entwicklung mit Scrum, XP u.a., mitp-Verlag, 2010
Dogs und Klimmer (2005) Dogs, Carsten; Klimmer, Time: Agile Software-Entwicklung kompakt, 1. Aufl., mitp-Verlag, 2005
Gloger (2009) Gloger, Boris: Scrum: Produkte zuverlässig und schnell entwickeln, Hanser Verlag, München 2002
Greenleaf (2002) Greenleaf, Robert K.: Servant Leadership: A Journey into the Nature of Legitimate Power and Greatness, 25th Anniversary Edition, Paulist Press, 2002
Günther, Huber und Lindenhahn (2008) Günther, S.; Huber E.; Lindenhahn, S.: Einfluss agiler Praktiken auf Teammerkmale und Erfolg von Softwareentwicklungsprojekten, Otto-von-Guericke-Universität Magdeburg, 2008
Jeffries (2001) Ron Jeffries: Essential XP:Card,Conversation,Confirmation, 2001, http://xprogramming.com/articles/expcardconversationconfirmation/ (08.06.2011, 14:50)
Pichler (2008) Pichler, Roman: Scrum - Agiles Projektmanagement erfolgreich einsetzen, 1. Aufl., dpunkt.verlag, 2008
Schwaber (1996) Schwaber, Ken: Controlled Chaos : Living on the Edge, 1996, http://www.jeffsutherland.org/oopsla96/schwaber.html (31.05.2011, 20:47)
Scrum Alliance (2011) Scrum Alliance: Non-Profit-Organisation zur Unterstützung von Scrum, http://www.scrumalliance.org/ (02.06.2011, 11:10)
Takeuchi und Nonaka (1986) Takeuchi, Hirotaka; Nonaka, Ikujiro: The New New Product Development Game, Harvard Business Review, 1986
Tuckman (1965) Tuckman, Bruce W.: Developmental sequences in small groups, Vol. 63, Psychological Bulletin, 1965
VersionOne (2008) VersionOne: 3rd Annual Survey: 2008 - “The State of Agile Development”, 2008, http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf (08.06.2011, 19:00)
Vigenschow, Toth und Wittwer (2008) Vigenschow, Uwe; Toth, Stefan; Wittwer, Markus: Projekt ist nicht gleich Projekt: Ergebnisse einer aktuellen Projektmanagement-Studie, Objektspektrum, 06/2009
Wirdemann (2009) Ralf Wirdemann: Scrum mit User Stories, Hanser Verlag, 2009
Von „http://winfwiki.wi-fom.de/index.php/Beschreibung_und_Analyse_von_SCRUM“
Persönliche Werkzeuge