Verzeichnisse   I

INHALT

2  EINFÜHRUNG  1

2.1  AUSGANGSSITUATION.  1

2.2  PROBLEMSTELLUNG  2

2.3  UNTERSUCHUNGSZIELE  3

2.4  UNTERSUCHUNGSVERFAHREN UND AUFBAU DER ARBEIT  4

3  AGILE SOFTWAREENTWICKLUNG  5

3.1  BEDARF NACH NEUEN LÖSUNGSANSÄTZEN IN DER SOFTWAREENTWICKLUNG  5

3.2  IDEE DES AGILEN VORGEHENS  6

3.3  SCRUM ALS KONKRETES AGILES MODELL  9

3.3.1  Selbstverständnis der Beteiligten  9

3.3.2  Schwerpunkt auf direkte Kommunikation  11

3.3.3  Werkzeuge zur Koordination und Transparenz  13

3.3.4  Typischer Ablauf während der Entwicklung  15

3.3.5  Scrum für große Projekte skalieren  16

3.4  VERBESSERUNGSBEDARF TROTZ SCRUM UND AGILITÄT  19

3.4.1  9 ou(oc9 il Pv v  20

3.4.2  9 ou(oc9 il µ Z(ºZ µvP  20

3.4.3  9 ou(oc9 il µ µvP  21

4  KOMPLEXITÄTSORIENTIERTES MANAGEMENT  22

4.1  BEZUGSRAHMEN SYSTEMTHEORIE UND KYBERNETIK  22

4.2  MANAGEMENTKYBERNETIK IN DER SOFTWAREENTWICKLUNG  23

4.3  SYSTEMASPEKTE IN DER KYBERNETIK  24

4.3.1  Systembegriff  24

4.3.2  Struktur, Verhalten und Selbstorganisation  27

4.3.3  Komplexität und Komplexitätsbewältigung  27

4.4  REGELASPEKTE IN DER KYBERNETIK  30

4.4.1  Steuerungsprozesse  30

4.4.2  Regelkreise  30

4.4.3  Homöostase und ultrastabile Systeme  31

4.4.4  Autopoietische Systeme  33

4.4.5  Lebensfähige Systeme  33

4.5  KYBERNETIK IN DER SOFTWAREENTWICKLUNG KRITISCH REFLEKTIERT  38

5  AGILES PROJEKTMANAGEMENT AUS SICHT DES LEBENSFÄHIGEN SYSTEMS  40

5.1  METHODIK DER ANALYSE  40

5.2  SYSTEMBILDUNG: EINORDNUNG IN REKURSIONSEBENEN  41

5.2.1  Rekursionsebene-1: Das betrachtete System  41

5.2.2  Rekursionsebene-2: Untergeordneten Systeme  42

5.2.3  Rekursionsebene-0: Übergeordnete Systeme  43

5.3  ELEMENTARE ORGANISATIONSEINHEIT: SCRU-MTEAM  44

5.3.1  Aufgaben der elementaren Organisationseinheit im Viable System Model  44

5.3.2  Ableitung von Anforderungen an agile Software-Entwicklung  45

5.3.3  Diagnose der Ist-Situation  46

5.3.4  Gestaltungshinweise und Einblicke in die Praxis  50

5.4  SYSTEM 1: VERBUND MEHRERER SCRU-MTEAMS  52

5.4.1  Aufgaben des System-1 im Viable System Model  52

5.4.2  Ableitung von Anforderungen an agile Software-Entwicklung  54

5.4.3  Diagnose der Ist-Situation  56

5.4.4  Gestaltungshinweise und Einblicke in die Praxis  58

5.5  SYSTE-M2 : MEHRERE SCRU-MTEAMS UND DEREN KOORDINATION  61

5.5.1  Aufgaben des System-2 im Viable System Model  61

5.5.2  Ableitung von Anforderungen an agile Software-Entwicklung  62

5.5.3  Diagnose der Ist-Situation  63

Verzeichnisse   II

5.5.4  Gestaltungshinweise und Einblicke in die Praxis  65

5.6  SYSTE-M3: SCRU-MTEAMS OPERATIV STEUERN  67

5.6.1  Aufgaben des System-3 im Viable System Model  67

5.6.2  Ableitung von Anforderungen an agile Software-Entwicklung  69

5.6.3  Diagnose der Ist-Situation  70

5.6.4  Gestaltungshinweise und Einblicke in die Praxis  75

5.7  SYSTEM 4: DAS PROJEKT LANGFRISTIG AUSRICHTEN  77

5.7.1  Aufgaben des System-4 im Viable System Model  77

5.7.2  Ableitung von Anforderungen an agile Software-Entwicklung  80

5.7.3  Diagnose der Ist-Situation  80

5.7.4  Gestaltungshinweise und Einblicke in die Praxis  84

5.8  SYSTEM 5: IDENTITÄT UND PROJEKTLEITLINIEN  85

5.8.1  Aufgaben des System-5 im Viable System Model  85

5.8.2  Ableitung von Anforderungen an agile Software-Entwicklung  88

5.8.3  Diagnose der Ist-Situation  89

5.8.4  Gestaltungshinweise und Einblicke in die Praxis  91

6  ERGEBNISSE UND AUSBLICK  93

6.1  UNTERSUCHUNGSVERLAUF UND -ERGEBNISSE  93

6.1.1  Untersuchungsergebnis zu: Erarbeitung von Problemfeldern agiler Scrum-Projekte  93

6.1.2  Untersuchungsergebnis zu: Modellabbildung und Interpretation  94

6.1.3  Untersuchungsergebnis zu: Ableitung von Gestaltungshinweisen  95

6.2  AUSBLICK AUF WEITEREN FORSCHUNGSBEDARF  97

7  GLOSSAR  98

8  ANHANG: GESTALTUNGSHINWEISE FÜR AGILE PROJEKTE  105

9  LITERATURVERZEICHNIS  VI

Verzeichnisse   III

TABELLEN   

Tabelle 1:  Elemente eines Regelkreises.  31

Tabelle 2:  Diagnoseergebnisse der elementaren Organisationseinheit  50

Tabelle 3:  Diagnoseergebnisse des System-1  58

Tabelle 4:  Diagnoseergebnisse des System-2  65

Tabelle 5:  Identifizieren von Synergiepotenzialen  71

Tabelle 6:  Laufende Beobachtung zur Früherkennung von Oszillationsquellen.  72

Tabelle 7:  Diagnoseergebnisse des System-3  75

Tabelle 8:  Beobachtung der Umwelt durch das agile Projekt  81

Tabelle 9:  Diagnoseergebnisse des System-4  84

Tabelle 10:  Diagnoseergebnisse des System-5  91

Tabelle 11:  Diskrepanzen zwischen Modellanforderungen und Agilität/Scrum  94

Tabelle 12:  Korrelation zwischen Untersuchung und Problemfeldern  95

Verzeichnisse   

ABBILDUNGEN   

Abbildung  1: Aufbau der Arbeit  

Abbildung  2: Burndown-Chart eines 10-Tage Sprints.  

Abbildung  3: Beispiel für ein Impediment-Log.  

Abbildung  4: Scrum-Zyklusmodell  

Abbildung  5: Skalierung mit Scrum-of-Scrums  

Abbildung  6: Rekursive Scrum-of-Scrums  

Abbildung  7: Task-Board für das Product-Owner-Daily-Scrum  

Abbildung  8: Einordnung der Begriffe aus der Systemtheorie  

Abbildung  9: Festlegung von Systemgrenzen in Abhängigkeit vom Betrachter  

Abbildung  10: Veränderung dynamischer Systeme über die Zeit.  

Abbildung  11: Verhalten als Ergebnis äußerer Einflüsse und interner Zustände  

Abbildung  12: Einordnung der Begriffe Komplexität und Kompliziertheit  

Abbildung  13: Prinzip eines Regelkreises  

Abbildung  14: Viable System Model  

Abbildung  15: Elementare Organisationseinheit eines System-1  

Abbildung  16: Systemgrenzen eines großen Scrum-Projekts  

Abbildung  17: Systemgrenzen des Projektteams  

Abbildung  18: Einordnung des betrachteten Systems in die Rekursionsebenen  

Abbildung  19: Elementare Organisationseinheit eines System-1  

Abbildung  20: Elementare Organisationseinheit im Scrum-Projekt  

Abbildung  21: Rolle "Product-Owner" in ihrer ursprünglichen Bedeutung  

Abbildung  22: Rolle "Product-Owner" nach neueren Interpretationen  

Abbildung  23: Elementare Organisationseinheiten und deren Beziehungen  

Abbildung  24: Kooperierende Teams während eines Sprints an einem Beispiel  

Abbildung  25: Mehrere Scrum-Teams in Zusammenarbeit  

Abbildung  26: Dienste in einem Projekt im Sinne des System-2  

Abbildung  27: Synergiepotenzial in der Überlappung von Aufgaben  

Abbildung  28: Operatives Management mit System-3 und System-3  

Abbildung  29: Verschiedene Sichtweisen des System-3 auf System-1  

Abbildung  30: Strategisches Management mit System-4  

Abbildung  31: Zukunftsszenarien mit einem Modell simulieren  

Abbildung  32: Normatives Management mit System-5  

Abbildung  33: Krisenerkennung mit Hilfe eines Alarmsignals  

Abbildung  34: Projektlandkarte mit Gestaltungshinweisen  

Verzeichnisse V

Abkürzungsverzeichnis

d.h. ......... das heißt

engl. ........ englisch lat. .......... lateinisch vgl. .......... vergleiche VSM ......... Viable System Model

Einführung 1

2 Einführung

2.1 Ausgangssituation

Moderne Software ist komplex ¹ . Die bisherige Vorgehensweise, Softwareentwicklung streng linear in sequenzielle Phasen zu unterteilen, wird den Herausforderungen der Gegenwart nicht mehr gerecht (vgl. Gloger, 2008b, S. 30). Die hohe Anzahl an gescheiterten Softwareprojekten, vor allem an solchen, die bezüglich Funktionsumfang, Zeit oder Kosten die gesteckten Ziele nicht erreichten, legt sogar die Vermutung nahe, dass das Gelingen eines umfangreichen Softwareprojekts mehr vom Glück als vom methodischen Vorgehen abhängt (vgl. Becker/Huber, 2006, S. 5) ² . Das zu erstellende Softwareprodukt und dessen Prozessumfeld ist in der Regel schlicht zu vielfältig, um vorab eine detaillierte Planung, ein vollständiges Konzept und eine Abschätzung aller Eventualitäten abgeben zu können.

Diese Einsicht wird zunehmend akzeptiert und hat zu einem neuen Ansatz im Projektmanagement und in der Softwareentwicklung geführt. Verstärkt verbreiten sich die sogenannten agilen Vorgehen, allen voran Scrum als prominentester Vertreter (vgl. Abrahamsson et al., 2008, S. 11). Statt vorab exakt zu planen steht in Scrum das ÄCommitment³ GHV (QWZLFNOHUWHDPV LP Mittelpunkt (vgl. Schwaber, 2007, S. 137). Das Team verspricht, sein Bestmöglichstes zu geben, um einen vom Team selbst festgelegten Funktionsumfang in einem gegebenen Zeitfenster zu realisieren. Entscheidend dabei ist: Das Team organisiert sich selbst (vgl. Schwaber, 2007, S. 7). Es besitzt alle Freiheiten, trägt aber auch die Verantwortung, alles für das Erreichen des gesteckten Ziels zu tun. Scrum verspricht zusätzlich trotz der einfachen Regeln eine gute Skalierbarkeit in großen Projekten (vgl. Larman, 2004, S. 111). Große Projekte führen zur Bildung mehrerer Unterteams, die voneinander unabhängig und doch gemeinsam am Produkt arbeiten. Dies erfordert Koordination und Kommunikation, die Scrum mit wenigen verbindlichen Mechanismen abdeckt (vgl. Kapitel 3.3.5). Hält man diese ein, so kann man theoretisch damit nicht nur in Teams, sondern auch in ganzen Bereichen, ja sogar in der gesamten Unternehmensorganisation wesentliche Effizienzsteigerungen gegenüber dem traditionellen planungsorientierten Ansatz erreichen (vgl. Gloger, 2008b, S. 347ff.). Im Unterschied zur traditionellen Projektabwicklung akzeptieren agile Methoden die Tatsache, dass der Softwareentwicklungsprozess nicht vollständig beherrschbar ist (vgl. Gloger, 2008b, S. 42ff). Erst während der Softwareentwicklung manifestieren sich

¹ Der Begriff der Komplexität wird in Kapitel 4.3.3 eingeführt. Hier reicht das intuitive

Begriffsverständnis.

² Die Studie kommt zu dem Ergebnis, dass 45,2% der IT-Projekte erfolgreich

abgeschlossen werden. 29,4% erreichen ihre Ziele mit Zeit- und Kostenüber-

schreitung. 35,4% erreichen Ziele partiell oder gar nicht. Ein weiteres Ergebnis der

Studie ist die Erkenntnis, dass mit zunehmender Projektgröße die Erfolgsquote

abnimmt. Bei Projekten mit mehr als 20 Personen liegt demnach die Erfolgswahr-

scheinlichkeit bei 18%.

Einführung 2

technische und fachliche Problemstellungen, auf die ein Projekt der jeweiligen Situation angemessen reagieren muss. Mit diesem Blick hin zu einer evolutionären Projektkultur werden Parallelen zur Kybernetik erkennbar. Die Kybernetik beschäftigt sich seit mehreren Jahrzehnten mit dem Phänomen der Komplexität und deren Beherrschbarkeit ³ . Stafford Beer, einer ihrer Pioniere, veröffentlichte 1959 ein Modell, das die Voraussetzungen für überlebensfähige komplexe Organisationen beschreibt (vgl. Beer, 1959)$OVÄModell des lebensfähigen Systems³ÄViable System Model³NXU]960ILQGHW es in den letzten Jahren verstärkt Beachtung. Es zeigt, welche strukturellen Elemente eine Organisation notwendigerweise aufweisen muss, um angemessen mit Störungen umzugehen und langfristig in einem komplexen Umfeld zu bestehen. Insbesondere die Managementkybernetik befasst sich intensiv mit der Interpretation dieses Modells (vgl. Schwaninger, 2006), (vgl. Hoverstadt, 2008), (vgl. Malik, 2008). Die Erkenntnisse daraus können durchaus auch bei der Frage der Organisation von Softwareentwicklungs- SURMHNWHQKHOIHQ3URMHNWHVLQGÄ2UJDQLVDWLRQHQDXI=HLW³(vgl. Ruf/Fittkau,2008, S. 187), wodurch aber der Aspekt der Lebensfähigkeit nicht obsolet wird, denn zumindest für die Zeitspanne der Projektdauer muss das Projekt lebensfähig sein, also mit Ereignissen aller Art angemessen umgehen können. Weiterhin haben Projekte das Bestreben, durchaus über das Projektende hinaus zu existieren ± konkret indem sie Folgeaufträge generieren.

2.2 Problemstellung

Softwareentwicklungsprojekte verfolgen mehrere Formalziele. Je nach deren Zielerreichung werden erfolgreiche und gescheiterte Projekte unterschieden. Folgende Formalziele können für die Softwareentwicklung genannt werden ⁴ : N Minimieren der Projektkosten N Minimieren der Projektdauer N Maximieren der Qualität N Maximieren der Menge an gelieferten Funktionen

Da dies in kleinen Projekten mit wenigen Personen bereits gut gelingt, große Projekte aber regelmäßig scheitern (vgl. Becker/Huber, 2006, S. 5), ist als Unterziel zusätzlich eine Skalierung auf verschiedene Projektgrößen zu nennen: N Skalierbarkeit von Projektteams steigern

Die agile Softwareentwicklung und Scrum als Vorgehensmodell unterstützen das Erreichen der Formalziele mit verschiedenen Mechanismen. Ziel der Agilität ist es, gerade im Vergleich zu traditioneller Softwareentwicklung bei der Erreichung dieser Ziele

³ 1948 legte Norbert Wiener mit Ä&\EHUQHWLFV RU &RQWURO DQG &RPPXQLFDWLRQ in the

$QLPDO DQG WKH 0DFKLQH´ 0,7 3UHVV GHQ Grundstein zur Kybernetik. Er

beschäftigte sich darin mit der Steuerung von Systemen.

⁴ Die FormalzielH OHLWHQ VLFK DXV GHP DOV Ä7HXIHOVTXDGUDW³ JHQDQQWHQ =XVDPPHQKDQJ

zwischen Anforderungen, Dauer, Kosten und Qualität ab (vgl. Sneed, 2005, S. 5f.).

Einführung 3

erhebliche Fortschritte zu machen. Kapitel 3 erarbeitet die Aspekte, mit denen dies im Detail geschieht. Angesichts der Komplexität der heutzutage zu erstellenden Softwareprodukte ist die Einfachheit der Regeln in Scrum, insbesondere in der Frage der Skalierung, überraschend. Ein Blick in die Praxis zeigt, dass die reine Lehre für große Projekte zwar ein guter Ratgeber, für sich alleine aber nicht ausreichend ist. Kritische Stimmen in Bezug auf die Skalierung sind in der Literatur verstärkt zu finden ± ein Indiz dafür, dass die anfänglichen Euphorie für agile Methoden einer gewisse Ernüchterung weicht (vgl. Schuh, 2005, S. 318f.), (vgl. Boehm/Turner, 2004, S. 147ff.). Der angestrebte Sollzustand, das Erreichen aller genannten Formalziele gemäß vorab vereinbarter Erreichungsgrade, gelingt offensichtlich auch mit agilem Vorgehen nicht uneingeschränkt. Kapitel 3.4 nennt die Problemfelder, die trotz des neuen Vorgehens eine erfolgreiche Projektabwicklung gefährden. Gerade die Skalierung in großen Projekten und die damit einhergehenden Herausforderungen in der Organisation scheinen auch mit dem neuen Ansatz der Softwareentwicklung nur unzureichend gelöst. Die vorliegende Arbeit legt ihren Schwerpunkt auf diese Problemstellung.

2.3 Untersuchungsziele

Das Untersuchungsobjekt ⁵ der vorliegenden Arbeit ist ein nicht triviales Scrum-Projekt. Ä1LFKWWULYLDO³EHGHXWHW in diesem Zusammenhang, der Projektablauf ist als Ganzes nicht im Detail vorhersehbar und die Projektabwicklung erfordert eine komplizierte Struktur, bestehend aus mehreren kooperierenden Teams ⁶ .

Die Untersuchungsziele lassen sich in drei Hauptziele gliedern. Erstes Ziel ist das Erarbeiten der Problemfelder, die nicht triviale Scrum-Projekte gegenwärtig beschäftigen. Das zweite Untersuchungsziel setzt sich auseinander mit einer analytischen Abbildung des Untersuchungsobjekts auf das Viable System Model mit dem Zweck, Abweichungen zu identifizieren und diese im Kontext der erarbeiteten Problemfelder zu interpretieren. Drittes Untersuchungsziel ist das Ableiten von Gestaltungshinweisen aus den Ergebnissen des zweiten Untersuchungsziels. Die Gestaltungshinweise dienen der Beeinflussung des Untersuchungsobjekts, um die Problemfelder während der Projektabwicklung künftig gezielt zu benennen. Nachfolgende Auflistung zeigt die Untersuchungsziele dieser Arbeit als hierarchische Gliederung.

1. Erarbeiten der Problemfelder gegenwärtiger agiler Scrum-Projekte 2. Abbilden eines nicht trivialen abstrakten Scrum-Projekts auf das Viable System Model

⁵ Die Begriffe Untersuchungsobjekt und Untersuchungsziel orientieren sich am Konzept

der Untersuchungssituation. Auf eine Einführung des theoretischen Rahmens wird an

dieser Stelle verzichtet und auf die entsprechende Literatur verwiesen (vgl. Ferstl,

1979).

⁶ Der Begriff Kompliziertheit wird zusammen mit dem Begriff Komplexität in Kapitel 4.3.3

eingeführt.

Einführung 4

3. Ableiten von Gestaltungshinweisen aus den Erkenntnissen der Modellabbildung

2.4 Untersuchungsverfahren und Aufbau der Arbeit

Das in der Ausarbeitung angewandte Untersuchungsverfahren gliedert sich in zwei große Bestandteile. Im ersten Schritt werden die Problemfelder gegenwärtiger agiler Scrum-Projekte anhand der Formalziele aus Kapitel 2.2 erarbeitet. Hier wird sichtbar, welche Probleme die agile Herangehensweise löst und welche davon nach der Einführung der agilen Entwicklung unverändert bestehen bleiben.

Im nächsten Schritt wird das Viable System Model hinzugezogen und das Untersuchungsobjekt darauf abgebildet. Da das Modell aus mehreren Teilsystemen besteht, findet die Abbildung schrittweise statt. Für jedes Teilsystem werden zunächst die Aufgaben im Kontext des VSM beschrieben und anschließend auf das Untersuchungsobjekt abgebildet. Aus der Abbildung heraus werden Anforderungen an die Softwareentwicklung formuliert und der Ist-Situation gegenübergestellt. Die Interpretation der Abweichungen mündet in die Formulierung von Gestaltungshinweisen, die anhand typischer Szenen aus Praxisprojekten veranschaulicht werden. Die Gestaltungshinweise selbst beinhalten konkrete Hilfestellungen und unterstützen so die tagtägliche Projektabwicklung. Der Vorteil des Untersuchungsverfahrens ist deren Systematik. Da nach Stafford Beer jedes lebensfähige System alle Modellelemente beinhalten muss ⁷ , wurden nach der vollzogenen Abbildung des Untersuchungsobjekts auf das Modell auch alle relevanten Aspekte beleuchtet.

Die folgende Abbildung (Abbildung 1) stellt den Aufbau der Arbeit schematisch dar. Zunächst findet im ersten Teil eine kritische Reflexion agiler Vorgehensmodelle mit Schwerpunkt Scrum statt. Daraus leiten sich konkrete Problemstellungen ab, die im späteren Verlauf der Arbeit im Zuge der Modellabbildung adressiert werden. Der zweite Teil der Arbeit führt in die kybernetischen Grundlagen ein. Aufbauend darauf wird eine typische Scrum-orientierte Projektstruktur systematisch auf das Viable System Model abgebildet und im Hinblick auf die Untersuchungsziele beleuchtet. Der abschließende Ausblick fasst die gewonnenen Erkenntnisse zusammen und zeigt Möglichkeiten für weitergehende Forschungsaktivitäten auf.

⁷ 0LWÄOHEHQVIlKLJ³LVWGDV(UKDOWHQGHUHLJHQHQ,GHQWLWlWJHPHLQW(Beer, 1979, S.113ff).

Einführung 5

Abbildung 1: Aufbau der Arbeit

3 Agile Softwareentwicklung

3.1 Bedarf nach neuen Lösungsansätzen in der

Softwareentwicklung

Softwareentwicklungsprojekte unterscheiden sich in vielen Facetten von traditionellen Projekten, wie sie beispielsweise tagtäglich in der Bauwirtschaft zu finden sind. Daraus ergeben sich nicht unerhebliche Auswirkungen auf die Art und Weise, wie Softwareprojekte erfolgreich an das Ziel gebracht werden können. Nachfolgend werden drei wesentliche Unterschiede skizziert (vgl. Schäppi et al., 2005, S. 524f.), (vgl. Gloger, 2008b, S. 44).

N Software ist ein immaterielles Produkt

Die Tatsache, dass Software ein nicht greifbares Produkt ist, ist unmittelbar im Projektverlauf spürbar. Der wahrgenommene Status des momentanen

Entwicklungsstandes ist immer mit einer erheblichen Unschärfe behaftet, da der Fertigstellungsgrad nicht objektiv gemessen werden kann.

N Die Umwelt der Softwareentwicklung ist hochdynamisch

Softwareentwicklung bewegt sich in einem innovativen technischen Umfeld, das sich laufend verändert. Gerade bei lang laufenden Projekten kann während des Projektverlaufs die Notwendigkeit entstehen, eingesetzte Technologien zu aktualisieren oder grundsätzlich zu überdenken. Auch funktionale Anforderungen detaillieren sich in der Regel erst zum Projektabschluss hin und manifestieren sich in Änderungen, die

Agile Softwareentwicklung 6

Projektkosten, -termine und ±ergebnisse beeinflussen. Das Projekt muss der hohen Dynamik in technischer und fachlicher Umwelt flexibel entgegentreten, um nicht zu scheitern ⁸ .

N Hoher Abstraktionsgrad, niedriger Normierungsgrad

Softwareentwicklung basiert auf einem hohen Grad an Abstraktion, gepaart mit einem niedrigen Grad an Normierung. Die Fähigkeit zur Abstraktion und die

Entwicklungsgeschwindigkeit einzelner Teammitglieder variieren stark, abhängig von deren Können, Qualifikation und Erfahrung. Im Teamaufbau und im Gestalten geeigneter Kontrollgrößen muss diesem Umstand angemessen Rechnung getragen werden. Zusätzlich sind die verfügbaren Lösungsmöglichkeiten in der Softwareentwicklung gefächert ⁹ . aufgrund fehlender Normierung breit Damit ist der

Softwareerstellungsprozess sehr individuell, geprägt von den Fähigkeiten und Vorlieben des Teams.

Die geschilderten Besonderheiten der Softwareentwicklung machen sehr gut deutlich, dass eine vollständige Vorabplanung eines Softwareentwicklungsprojekts immer mit erheblichen Unsicherheiten behaftet sein muss. Das aus anderen Branchen stammende Prinzip, ein Projekt sequenziell in die großen Phasen Analyse, Planung und Umsetzung zu unterteilen, funktioniert nur unzureichend (vgl. Vogel et al., 2009, S. 343f.). Aus diesem Leidensdruck entstanden neuere Ansätze, die speziell die Herausforderungen der Softwareentwicklung berücksichtigen und schnell auf Umweltänderungen reagieren können: Agile Vorgehensmodelle (vgl. Kuster et al., 2008, S. 32f).

3.2 Idee des agilen Vorgehens

'DV :RUW ÄDJLO³ KDW VHLQHQ 8UVSUXQJ LP Lateinischen ÄDJLOLV³ und bedeutet übersetzt Äbeweglich³ ÄJHZDQGW³ (vgl. Duden Online, 2009). Übertragen auf die Softwareentwicklung bezieht sich die Beweglichkeit darauf, geleitet von Prinzipien jederzeit angemessen und am Kundennutzen ausgerichtet zu handeln. Die Kernthesen der agilen Softwareentwicklung wurden 2001 von den Gründern der Agile-$OOLDQFHLPÄ0DQLIHVWRIRU $JLOH6RIWZDUH'HYHORSPHQW³wie folgt formuliert (Beck et al., 2001a) ¹⁰ :

Individuen und Interaktionen sind wichtiger als Prozesse und Tools

⁸ Die Forderung nach der Dynamik lässt sich direkt aus dem Gesetz der erforderlichen

Varietät ableiten (vgl. Kapitel 4.3.3).

⁹ Die Vielfalt der Lösungsmöglichkeiten drückt die hohe Varietät des zu lösenden

Problems aus, welche viel höher ist als die Varietät typischer Projekte aus der

Bauwirtschaft.

¹⁰ Die folgende deutsche Übersetzung ist angelehnt an (Hruschka/Rupp/Starke, 2009,

S.2).

Agile Softwareentwicklung 7

Funktionierende Software ist wichtiger als umfassende Dokumentation Zusammenarbeit mit Kunden ist wichtiger als Vertragsverhandlungen Reaktion auf Änderungen ist wichtiger als einem Plan zu folgen

Zur Erweiterung der Kernthesen formulierten die Verfasser des agilen Manifests zusätzlich 12 Prinzipien, die dem agilen Team als Leitlinien für das eigene Verhalten dienen.

Agile Softwareentwicklung 8

(Beck et al., Principles behind the Agile Manifesto, 2001b).

'HU %HJULII ÄaJLOHV 9RUJHKHQVPRGHOO³ GLHQW der Klassifizierung verschiedener konkreter Vorgehensmodelle. Unter einem Vorgehensmodell versteht man in der Softwareentwicklung eine Untergliederung des Entwicklungsprozesses in verschiedene, strukturierte Phasen, in denen standardisierte Methoden und Techniken eingesetzt werden (vgl. Heinrich, 2007, S. 63). Konkrete agile Vorgehensmodelle sind beispielsweise Scrum (vgl. Schwaber, 2007), Extreme Programming (vgl. Beck/Andres, 1999), Crystal (vgl. Cockburn, 2002), Feature Driven Development (vgl. Felsing/Palmer, 2002) oder Dynamic System Development (vgl. Stapleton, 1997). Die Fülle zeigt, wie vielfältig das Manifest und die Prinzipien ausgelegt werden können. Problematisch dabei ist, dass ÄDJLO³ PHKU XQG PHKU ]XP 7UHQGZRUW ZLUG -HGHV 7HDP VLHKW VLFK DOV DJLO ± und kann auch passende Beispiele liefern. Diskussionen, welche der agilen Vorgehensmodelle die effektivste und effizienteste ist, oder wie man die Modelle kombiniert, machen den Begriff GHUÄ$JLOLWlW³noch schwerer greifbar (vgl. Götzenauer, 2006, S.80), (vgl. Bomarius/Iida, 2004, S. 437ff.) ¹¹ .

Ein Blick auf die inhaltliche Ebene der Agilität zeigt, dass die agile Idee im Kern eine Abkehr vom planungszentrierten, stark auf Dokumente fokussierten Entwicklungsansatz vertritt. Der Kunde mit seinen Anforderungen ist nicht Synonym für Projektrisiken, der bestehende Pläne kontinuierlich gefährdet. Ganz im Gegenteil sind von ihm geforderte Änderungswünsche auch im fortgeschrittenen Projektverlauf noch willkommen und finden Berücksichtigung in der Entwicklung. Im Fokus steht der Wunsch, letztlich schrittweise ein Ergebnis mit maximalem Kundennutzen zu schaffen (vgl. Gloger, 2008b, S. 63). Der Kunde selbst wird dazu aktiv und nutzbringend eingebunden und in die Verantwortung genommen. Das Vorgehen befreit unmittelbar von einer Reihe von Formalismen und schafft Freiräume, um sich auf das zu entwickelnde System und die Umwelt zu konzentrieren. Der Zeitaufwand, der bisher in Spezifikation und Planung investiert wurde, wird erheblich reduziert. Eigenverantwortung, fortlaufende Transparenz unter den Beteiligten und Selbstorganisation sind die Konzepte, mit denen die Komplexität der Softwareentwicklung steuerbar werden soll. Gerade die Selbstorganisation ist der entscheidende Erfolgsfaktor der neuen Herangehensweise. Mit ihr wird der Prozess bezeichnet, bei dem ohne Steuerung von außen, also nur durch das Zusammenspiel der gleichberechtigten Projektmitarbeiter untereinander, die zur Erfüllung der Aufgabe notwendige Ordnung entsteht und erhalten wird (vgl. Weik/Lang, 2003, S. 245). Während man auf der einen Seite des Spektrums die Verfechter der Agilität mit ihrem Wunsch nach absoluter Selbstbestimmung sieht, findet man auf der anderen Seite auch Meinungen, dass agiles Vorgehen nichts anderes ist als eine Rückkehr zum

¹¹ Die Diskussion wird begleitet von Hinweisen, dass für fundierte Vergleiche noch nicht

ausreichend Praxiserfahrung in den neuen Methoden gesammelt wurde, z.B. in (vgl.

Bomarius/Iida, 2004, S. 439).

Agile Softwareentwicklung 9

unstrukturierten, chaotischen Entwickeln (vgl. Wolf/Roock, S. 12). Der neue Grad an Freiheit überfordert Teams und Kunden häufiger (vgl. Haider, 2007, S. 9). So ist zu beobachten, dass sich gerade der Kunde vorab weniger Gedanken zur Strukturierung seines Businesscase macht und dies bewusst erst während der Entwicklung nachholt. Passen IT und Business dann nicht mehr zusammen sind umfangreiche Änderungen an implementierten Funktionen notwendig ± ein Zeit- und Kostenverlust, der nur schwer wieder wettzumachen ist.

Für eine ausführliche Erläuterung des agilen Ansatzes sei der interessierte Leser auf die inzwischen zahlreich verfügbaren Publikationen verwiesen (vgl. Highsmith, 2004), (vgl. Schwaber, 2007), (vgl. Gloger, 2008b).

3.3 Scrum als konkretes agiles Modell

Neben XP ist Scrum eines der am weitest verbreiteten agilen Vorgehensmodelle (vgl. O'Conner et al. 2008, S. 190). Da im zweiten Teil der Arbeit eine Scrum-orientierte Projektstruktur auf das Viable System Model abgebildet wird, ist es für das Gesamtverständnis zweckmäßig, dieses agile Vorgehensmodell detaillierter vorzustellen. Scrum ist ein iterativer Prozess, der die Entwicklung der Software in feste, typischerweise 7DJHGDXHUQGH=HLWVFKHLEHQXQWHUWHLOW(LQH,WHUDWLRQZLUGLQ6FUXPÄSprint³JHQDQQW und endet mit der Fertigstellung einer lauffähigen Version des Produkts. Das Team übernimmt in jedem Sprint die gemeinsame Verantwortung für die Fertigstellung der selbstgewählten Umfänge. Zwischen zwei Sprints wird der Projektfortschritt vom Management und vom Kunden überprüft. Gegebenenfalls werden daraufhin neue Anforderungen an das Produkt formuliert, bestehende Anforderungen gestrichen oder bezüglich ihrer Priorität angepasst. Scrum betont sehr stark die Autonomie des Teams und seiner Mitglieder. Diese organisieren sich eigenverantwortlich, um die gesteckten Ziele zu erreichen. Dadurch entsteht Motivation und damit verbunden eine Produktivitätssteigerung. Wenige, aber unbedingt einzuhaltende Regeln garantieren ein hohes Maß an Wissensaustausch und Transparenz. Darauf basierend lässt sich der Entwicklungsprozess situativ steuern, wobei jegliche Form von Behinderung erfasst und unmittelbar adressiert wird (vgl. Schwaber, 2007, S. 6ff.).

3.3.1 Selbstverständnis der Beteiligten

In einem Softwareentwicklungsprojekt fallen über die Aufgabenzerlegung zahlreiche und vielfältige Einzelaktivitäten an. Um die Bearbeitung der Aktivitäten zu organisieren werden typischerweise Rollen mit zugehörigen Verantwortlichkeiten festgelegt. Eine Rolle bezeichnet dabei ein Bündel von Aufgaben und Kompetenzen, das zur Wahrnehmung der Aufgaben notwendig ist (vgl. Gernert, 2003, S. 138). In der Regel beschreibt dann ein Anforderungsprofil die Qualifikationen, die Personen besitzen müssen, um eine Rolle zu

Agile Softwareentwicklung 10

übernehmen. Beispielhafte Rollen aus der Softwareentwicklung sind Projektleiter, Softwarearchitekt, Testmanager oder Entwickler. Manche Vorgehensmodelle der Softwareentwicklung legen eine Vielzahl von Rollen fest, um Abläufe möglichst strukturiert zu halten. So definiert zum Beispiel der Rational Unified Process mehr als 30 Rollen (vgl. Kruchten, 2004, S. 273). Scrum geht hier einen anderen Weg. Es verzichtet auf praktisch alle der klassischen Rollen, insbesondere auch auf die des Projektleiters. Stattdessen werden nur drei festgelegt, deren Verantwortung sehr klar ausformuliert ist (vgl. Schwaber, 2007, S. 18ff.): N Product-Owner N Scrum-Master N Team

Der Product-Owner ist derjenige, der als Visionär das angestrebte Projektziel vermittelt. Er sorgt dafür, dass jeder Einzelne versteht, welchen Sinn das Projekt verfolgt und weshalb das Projekt wichtig ist. Der Product-Owner ist auch derjenige, der das finanzielle Ergebnis des Projekts verantwortet. Neben der Vision ist er auch für die konkrete Anforderungsliste verDQWZRUWOLFK 'LHVH ZLUG LQ 6FUXP Ä3URGXFW-%DFNORJ³ JHQDQQW XQG enthält eine nach Marktwert priorisierte Menge von Produktmerkmalen. Die Liste kann nach jedem Sprint sowohl inhaltlich als auch bezüglich der Reihenfolge der Einträge geändert werden. Am Ende jeder Iteration wird dem Product-Owner der Fortschritt an einem lauffähigen Produktinkrement präsentiert. Aus der Präsentation heraus können neue Einträge für das Product-Backlog entstehen. Explizit nicht im Aufgabenbereich des Product-Owners liegt, wie das Team die einzelnen Einträge des Product-Backlogs umsetzt.

Der Scrum-Master sorgt für die Einhaltung der Scrum-Werte und ±Techniken. Er vertritt das Projekt gegenüber dem Management und schützt das Team vor jeglichen äußeren Störungen. Alle Hindernisse, die das Team oder der Product-Owner an ihn herantragen, hält der Scrum-Master in einem sogenannten Impediment-Log fest. Es liegt in seiner Verantwortung, diese Liste unverzüglich abzuarbeiten. Der Scrum-Master besitzt gegenüber dem Team keine Weisungsbefugnis, so dass eine Kommunikation stets auf Augenhöhe stattfindet.

Das Team ist typischerweise eine Gruppe von fünf bis neun Personen. Die Mitglieder müssen frei von allen anderen Verpflichtungen sein, um sich vollständig auf die Projektaufgabe konzentrieren zu können. Das Team ist multifunktional, d.h. alle im Projekt erforderlichen Funktionen sind darin vertreten (beispielsweise Qualitätssicherung, Programmierung, Build-Management). Wie sich das Team selbst organisiert, bleibt vollständig ihm selbst überlassen. Eine Anpassung der Teamzusammenstellung ist nur zwischen einzelnen Sprints gestattet.

Agile Softwareentwicklung 11

Aus der Tatsache heraus, dass Scrum nicht mehr als die beschriebenen drei Rollen definiert, kann nicht abgeleitet werden, dass alle anderen Rollen hinfällig sind. Der Gedanke Scrums ist vielmehr, dass sich andere Rollen aus der Selbstorganisation der Teams heraus entwickeln (vgl. Larman, 2004, S.34). Aufgrund der Vielfalt möglicher Projektstrukturen, die im Prozess der Selbstorganisation entstehen können, ist eine weitere Standardisierung in Scrum nicht mit seiner versprochenen Einfachheit vereinbar. Folgt man dieser Logik weiter, dann ist Scrum kein Modell um die Projektstrukturen der Softwareentwicklung zu vereinfachen. Stattdessen wird eine leicht erfassbare Ausgangsbasis für die Entwicklung beschrieben und die sich ergebende explosionsartige Zunahme der Komplexität mit dem Prinzip der Selbstorganisation beantwortet.

3.3.2 Schwerpunkt auf direkte Kommunikation

Gemäß dem agilen Manifest, wonach Individuen und Interaktion wichtiger sind als Tools und Prozesse (vgl. Kapitel 3.2), verpflichtet Scrum das Projektteam zu nur vier Arten von Abstimmungstreffen. Diese Treffen sind bezüglich Ablauf und Umfang wenigen, aber strengen Vorgaben unterworfen, die im Wesentlichen darauf abzielen, in fest definierter Zeit maximalen Informationsfluss zu gewährleisten. Folgende Besprechungsarten kennt Scrum (vgl. Wirdemann, 2009, S. 30f.): N Sprint-Planning-Meeting N Daily-Scrum-Meeting N Sprint-Review-Meeting N Sprint-Retrospective

Im Sprint-Planning-Meeting geht es darum, die Ziele des kommenden Sprints zu vereinbaren und sie in konkrete Aufgabenpakete zu zerlegen. Dafür steht dem Team ein Zeitfenster von exakt acht Stunden zur Verfügung. Im ersten Teil des Treffens vereinbaren der Product-Owner und das Team, welche Einträge des Product-Backlogs im kommenden Sprint umgesetzt werden können. Beide verpflichten sich am Ende des ersten Teils explizit, das Bestmögliche zum Erreichen des gesteckten Ziels zu geben. Dies ZLUG LQ 6FUXP ÄCommitment³ JHQDQQW Im zweiten Teil zerlegt das Team die ausgewählten Product-Backlog-Einträge in Arbeitspakete, die in das sogenannte Sprint-Backlog übernommen werden. Jeder Eintrag im Sprint-Backlog umfasst einen kleinen, überschaubaren Arbeitsumfang. Im Laufe des Sprints werden diese Umfänge umgesetzt und Plan- und Istwerte verglichen. Auch noch während des Sprints können vom Team neue Einträge aufgenommen werden, falls Erkenntnisse aus der Realisierung dies notwendig machen.

Die nächste Besprechungsart, das Daily-Scrum, dient dem Informationsaustausch der Entwickler untereinander. Sie treffen sich einmal täglich für 15 Minuten, um die Einträge

Agile Softwareentwicklung 12

im Sprint-Backlog zu besprechen und aktuelle Soll- und Istwerte zu vergleichen. Jeder beantwortet dabei reihum folgende Fragen: N Was hat er/sie seit dem letzten Daily-Scrum getan? N Was plant er/sie bis zum nächsten Daily-Scrum?

N Welche Hindernisse gab es, die dazu führten, dass er/sie nicht mit maximaler Effizienz arbeiten konnte?

Aufgrund der engen zeitlichen Restriktion von maximal 15 Minuten muss der Scrum-Master alle thematischen Abschweifungen und aufkeimenden Diskussionen unmittelbar unterbinden und die Beteiligten bitten, offene Punkte im Nachgang untereinander zu klären. Damit enthält das Daily-Scrum selbst keine Kontrolle, ob die von einem Teammitglied gesendete Information auch tatsächlich verstanden wurde. Es geht primär darum, möglichst viel Information zu senden (vgl. Abrahamsson et al., 2008). Am Ende eines Sprints steht das Sprint-Review-Meeting. Darin präsentiert das Team in maximal vier Stunden dem Product-Owner und anderen interessierten Personen ihr im letzten Sprint erstelltes, lauffähiges Produktinkrement. Der Product-Owner entscheidet, welche der Product-Backlog-(LQWUlJH DXI ÄHUOHGLJW³ JHVHW]W ZHUGHQ N|QQHQ 1LFKW vollständig implementierte Funktionen werden nicht präsentiert und verbleiben im Product-Backlog. Aus der Diskussion zwischen den Review-Teilnehmern können neue Ideen und daraus neue Product-Backlog-Einträge entstehen. Der Product-Owner priorisiert sie entsprechend deren wirtschaftlichen Nutzen.

Ebenfalls am Ende eines Sprints findet die Sprint-Retrospective statt. Zweck des Treffens ist eine Selbstreflexion des Teams: Was lief während des letzten Sprints gut und was kann im nächsten Sprint verbessert werden? Der Scrum-Master unterstützt das Team bei der Optimierung ihrer Prozesse, protokolliert die einzelnen Punkte und hilft bei der Prioritätenvergabe. Die identifizierten Verbesserungsmöglichkeiten werden zum Abschluss des Treffens entweder in das Product-Backlog übernommen oder finden Eingang in die Aufgabenliste des Scrum-Masters, die in Scrum Impediment-Log genannt wird. Die Retrospektive hat ein Zeitfenster von maximal drei Stunden.

Scrum sieht genau diese oben beschriebenen Besprechungstypen als das ausreichende Minimum für den regelmäßigen Informationsaustausch untereinander. Darüber hinaus gehende Besprechungen entstehen aus der situativen Notwendigkeit heraus. Für den Aufbau komplexerer Kommunikationsnetze in großen Projektorganisationen empfiehlt Scrum neben seinem Skalierungsprinzip (vgl. Kapitel 3.3.5) insbesondere auf das Wissen erfahrener Einzelpersonen zurückzugreifen. Letztere sind der entscheidende Erfolgsfaktor für große Projekte, denn nur mit ihrer Hilfe gelingt der Wissenstransfer in die neu entstehenden Teilteams (vgl. Gloger, 2008b, S. 277f.).

Agile Softwareentwicklung 13

3.3.3 Werkzeuge zur Koordination und Transparenz

Viele der nun folgenden Werkzeuge wurden in den beiden vorangegangenen Kapiteln bereits informell eingeführt. Um die Darstellung von Scrum abzurunden werden sie hier zusammengefasst und etwas detaillierter beschrieben. Im Einzelnen sind dies (vgl. Wirdemann, 2009, S.28ff.): N Product-Backlog N Sprint-Backlog N Burndown-Chart N Impediment-Log N Produktinkrement

Das Product-Backlog enthält eine Auflistung aller Produktfunktionalitäten. Der Product-Owner als Fachexperte hat diese Liste auf der Basis des wirtschaftlichen Nutzens priorisiert. Jeder Eintrag des Product-Backlogs beschreibt das Was, nicht das Wie der Funktion. Häufig findet man eine Beschreibung in Form einer Kurzgeschichte, der sogenannten User-Story. Die Bedingungen für die Abnahme, also wann eine Funktionalität als fertiggestellt gilt, ist ebenfalls Teil der Beschreibung. Während der wirtschaftliche Nutzen eines Eintrags vom Product-Owner geschätzt wird, schätzt das Team den Aufwand für die Umsetzung dieses Eintrags.

Diejenigen Product-Backlog-Einträge, die das Team im kommenden Sprint realisieren wird, werden in das Sprint-Backlog übernommen. Beim Übertrag wird jeder Product-Backlog-Eintrag in mehrere feingranulare Aufgabenpakete zerlegt, die das Wie der Funktion beinhalten. Während des Sprints ändert sich das Sprint-Backlog laufend und spiegelt damit den aktuellen Stand des Sprints wieder. Das Sprint-Backlog ist ein Werkzeug für das Team um die Aufgabenaufteilung zu koordinieren und wird täglich im Scrum-Meeting gemeinsam begutachtet.

Der Burndown-Chart ist ein Hilfsmittel um den Fortschritt im Sprint transparent darzustellen. Die Summe der Restaufwände jedes Sprint-Backlog-Eintrags zeigt die noch offene Arbeit. Diese wird täglich an der Y-Achse aufgetragen (blaue Linie in Abbildung 2). Als Vergleichswert dient die verbleibende Anzahl an Stunden bis zum Sprintende (rote Linie in Abbildung 2). Aus dem Verlauf der blauen Linie kann unter Umständen ein Trend abgeleitet werden, auf den bereits sehr früh reagiert werden kann. Im Beispiel des Burndown-Charts in Abbildung 2 kann eine erhebliche Performance-Zunahme des Teams am letzten Tag beobachtet werden. Hält dieser Trend an, so kann der Sprint früher als geplant fertiggestellt werden. Es gehört zu den Aufgaben des Scrum-Masters, dem Team täglich zum Daily-Scrum eine aktualisierte Grafik vorzulegen.

Agile Softwareentwicklung 14

Der Scrum-Master ist der Verantwortliche für das Impediment-Log. Darin werden alle Punkte erfasst, die das Team daran hindern, bestmöglich produktiv zu sein (Abbildung 3). Aufgabe des Scrum-Masters ist es, diese Punkte schnellstmöglich zu beseitigen. Im Daily-Scrum berichtet er über Aktivitäten und Fortschritte diesbezüglich.

Am Ende des Sprints liefert das Team ein Produktinkrement aus. Dabei handelt es sich um eine lauffähige, potenziell auslieferbare Software, die dem Product-Owner und anderen Interessierten präsentiert wird. Unvollständige Funktionen, die nicht der im Product-Backlog-(LQWUDJ IHVWJHOHJWHQ 'HILQLWLRQ YRQ ÄHUOHGLJW³ entsprechen, sind nicht Bestandteil des Produktinkrements.

Mit den dargestellten Werkzeugen deckt Scrum den Zyklus der Softwareentwicklung gut ab: Product-Backlog für die grobgranulare langfristige Planung, Sprint-Backlog für die feingranulare kurzfristige Planung, Sprint-Burndown-Chart, Produktinkremente für die Fortschrittskontrolle und schließlich das Impediment-Log zur Unterstützung des Risikomanagements. Die detaillierte Planung und Projektverfolgung beschränken sich

Agile Softwareentwicklung 15

immer nur auf den aktuellen Sprint. Damit sind der Planungsaufwand und der Aufwand für die regelmäßige Pflege verhältnismäßig niedrig.

3.3.4 Typischer Ablauf während der Entwicklung

Mit den vorangegangenen Kapiteln wurde die Begriffswelt von Scrum umfassend eingeführt. Abbildung 4 zeigt grafisch, wie die einzelnen Elemente ineinander greifen. Stichpunktartig lässt sich der Ablauf folgendermaßen zusammenfassen: N Der Product-Owner definiert das Product-Backlog und priorisiert die Einträge darin nach deren wirtschaftlichem Nutzen.

N Im Sprint-Planning-Meeting übernimmt das Team die Menge an Einträgen in ihr Sprint-Backlog, die es sich zutraut, in den nächsten 30 Tagen umzusetzen. N Während des nun folgenden 30-Tage Sprints setzt das Team die Einträge im Sprint-Backlog um und koordiniert sich dabei im 24h-Rhythmus über das Daily-Scrum.

N Ergebnis des Sprints ist das lauffähige Produktinkrement, das im Sprint-Review dem Product-Owner präsentiert wird.

N Im abschließenden Retrospective-Meeting reflektiert das Team seine Erfahrungen und formuliert Maßnahmen, um die eigenen Prozesse zu optimieren.

Zusammenfassend setzt Scrum auf möglichst häufige Rückkopplungsprozesse und damit auf Transparenz zwischen allen Beteiligten. Kurze Planungs- und Entwicklungszyklen, ausgerichtet an einer Vision, prägen das Bild. Ein möglichst früher Systemeinsatz schafft Transparenz über den Ist-Zustand und dient als ein Mittel der Risikominimierung.

Agile Softwareentwicklung 16

3.3.5 Scrum für große Projekte skalieren

Ein Scrum-Team besteht typischerweise aus fünf bis neun Personen. Umfangreiche Softwareentwicklungsprojekte können aber durchaus mehrere hundert Personen umfassen. In so einem Fall ist es nötig, mehrere Scrum-Teams zu bilden und die Aufgaben zu verteilen. Damit ergibt sich die Notwendigkeit der Koordination der Scrum-Teams untereinander. Ausgehend von den drei in Scrum definierten Rollen sind in Bezug auf Skalierung folgende Aspekte von Interesse: N Koordination der technischen Aspekte zwischen den Teams N Koordination der fachlichen Aspekte zwischen den Product-Ownern N Koordination der Prozess-Aspekte zwischen den Scrum-Mastern

In der Literatur gibt es XQWHUVFKLHGOLFKH0HLQXQJHQZLHPLWGHP3UREOHPÄSkalierung³in Scrum umzugehen ist. Eine Gruppe empfiehlt konkrete Techniken, um das Miteinander zu strukturieren (vgl. Cohn, 2007), (vgl. Elssamadisy, 2008, S. 97). Eine andere Gruppe sieht diese Techniken als Begrenzungen der Freiheit und fordert, dass sich alle für die Skalierung notwendigen Strukturen nach dem Prinzip der Selbstorganisation aus den Teams heraus selbst entwickeln müssen (vgl. Gloger, 2008b, S. 207). Im Folgenden werden die typischen Techniken der ersten Gruppe beleuchtet, wobei auch hier verschiedene Gestaltungsmöglichkeiten anzutreffen sind.

Agile Softwareentwicklung 17

3.3.5.1 Koordination der technischen Aspekte zwischen den Teams

Arbeiten mehrere Teams an einem gemeinsamen Produkt, dann ist eine Abstimmung auf der operativen Ebene unbedingt notwendig. Ein gemeinsames Daily-Scrum mit den Mitgliedern aller Teams ist dafür nicht geeignet, da zum einen der Zeitbedarf hierfür sehr hoch ist, zum anderen aber auch viele Informationen fließen, die sich nur lokal auf einzelne Teams beziehen. Die empfohlene Lösung mit Scrum besteht daher darin, neben den täglichen Scrum-Meetings je Team eine weitere Besprechung einzuführen, das Scrum-of-Scrums (vgl. Elssamadisy, 2008, S. 7). Am Scrum-of-Scrums nimmt eine Person je Team teil, die alle Belange des Teams in dieser Besprechung vertritt (Abbildung 5).

Das Prinzip lässt sich rekursiv beliebig fortsetzen und bildet eine hierarchische Struktur von Besprechungen. Die nächste Ebene beinhaltet demnach zusätzlich zum Scrum-of-Scrums ein Scrum-of-Scrums-of-Scrums (Abbildung 6). Um der Bildung von Hierarchien zwischen den Teilnehmern entgegenzuwirken findet eine rotierende Auswahl des Team-Repräsentanten statt, der am Scrum-of-Scrums teilnimmt. Auch der Scrum-Master, der auf Ebene des Scrum-of-Scrums die aktuellen Probleme der Teams aufnimmt und priorisiert, wechselt laufend durch. Auf die Frage, wie ohne Hierarchien eine Entscheidungsfindung in Konfliktsituationen aussieht, geht Scrum nicht ein. Interpretiert werden kann hier, dass der Scrum-Master Konflikte als Impediment aufnimmt und deren Lösung vorantreibt.

Agile Softwareentwicklung 18

3.3.5.2 Koordination der fachlichen Aspekte zwischen den Product-Owners

Das Skalieren eines Projekts ist ein mehrstufiger Prozess. Am Anfang steht ein Kernteam, bestehend aus einem Scrum-Master, einem Product-Owner und dem Team. Dieses Kernteam erreicht im Laufe des Projekts seine Kapazitätsgrenze. Es muss skaliert werden. Scrum sieht nun vor, dass die Mitglieder des Teams zu Sub-Product-Ownern werden, da diese neben dem originären Product-Owner das größte Wissen über die zu implementierende Software haben (vgl. Gloger, 2008b, S. 280f.). Jedes neu entstehende Team erhält einen Sub-Product-Owner beigestellt, der das Fachwissen und die Vision in das Team trägt. Die Sub-Product-Owner müssen sich aber natürlich untereinander und mit dem Product-Owner abstimmen. Analog dem Scrum-of-Scrums empfiehlt Scrum hierfür ein Product-Owner-Daily-Scrum einzuführen (vgl. Wikimedia, 2009b). In dieser Besprechung wird der aktuelle Stand des Product-Backlogs begutachtet, es wird an der Vision und an neuen Backlog-Einträgen gearbeitet und es wird vorhandenes Wissen zum fachlichen Umfeld des Projekts ausgetauscht. Ein Taskboard kann den aktuellen Fortschritt auf hoher Ebene veranschaulichen und als gutes Hilfsmittel zur Kommunikation verwendet werden (Abbildung 7).

Agile Softwareentwicklung 19

3.3.5.3 Koordination der Prozess-Aspekte zwischen den Scrum-Mastern

In Projekten mit mehreren Scrum-Teams ist es auch sinnvoll, dass sich die Scrum-Master regelmäßig untereinander abstimmen, denn Probleme, die in einem Team auftreten, können durchaus auch in anderen Teams ein Thema sein. Scrum schlägt zur Abstimmung eine Scrum-Master-Group vor, die sich einmal wöchentlich trifft, um gelöste und offene Impediments gemeinsam zu diskutieren und Standards für die Art und Weise zu vereinbaren, wie die Teams arbeiten (vgl. Gloger, 2008b, S. 290). Die einzelnen Impediment-Logs der Scrum-Master bleiben aber prinzipiell unabhängig voneinander, jeder Scrum-Master ist nach wie vor verantwortlich für sein Impediment-Log.

3.4 Verbesserungsbedarf trotz Scrum und Agilität

Agiles Vorgehen im Allgemeinen und Scrum im Speziellen werden im Licht des momentanen Hypes als ultimative Lösung für bislang unzureichende Ergebnisse typischer Softwareentwicklungsprojekte gesehen. In dysfunktionalen Organisationen kann eine Reorganisation nach den Konzepten der Agilität in der Tat einen außerordentlich hohen Produktivitätsschub bringen. Ob aber eine solche Umstellung in allen Unternehmen erhebliche Vorteile bringt, ist zweifelhaft und kann vorab nicht gesagt werden (vgl. Bea/Göbel, 2002, S. 412). Auffällig ist, dass sich gängige Scrum-Literatur und Diskussionen meist um Organisation im Kleinen drehen (vgl. Wysocki, 2006, S. 246). Das Team von etwa sieben Personen steht im Mittelpunkt der Fragestellungen. Dabei wird