Gestaltungshinweise für agile Software-Entwicklungsprojekte unter dem Blickwinkel der Kybernetik

INHALT

2 EINFÜHRUNG
2.1 Ausgangssituation
2.2 Problemstellung
2.3 Untersuchungsziele
2.4 Untersuchungsverfahren und Aufbau der Arbeit

3 AGILE SOFTWAREENTWICKLUNG
3.1 Bedarf nach neuen Lösungsansätzen in der Softwareentwicklung
3.2 Idee des agilen Vorgehens
3.3 Scrum als konkretes agiles Modell
3.3.1 Selbstverständnis der Beteiligten
3.3.2 Schwerpunkt auf direkte Komm unikation
3.3.3 Werkzeuge zur Koordination und Transparenz
3.3.4 Typischer Ablauf während der Entwicklung
3.3.5 Scrum für große Projekte skalieren
3.4 Verbesserungsbedarf trotz Scrum und Agilität
3.4.1 Problemfeld „ Projektorganisation "
3.4.2 Problemfeld „ Projektdurchführung "
3.4.3 Problemfeld „Projektsteuerung"

4 KOMPLEXITÄTSORIENTIERTES MANAGEMENT
4.1 Bezugsrahmen Systemtheorie und Kybernetik
4.2 Managementkybernetik in der Softwareentwicklung
4.3 Systemaspekte in der Kybernetik
4.3.1 Systembegriff.
4.3.2 Struktur, Verhalten und Selbstorganisation
4.3.3 Komplexität und Komplexitätsbewältigung
4.4 Regelaspekte in der Kybernetik
4.4.1 Steuerungsprozesse
4.4.2 Regelkreise
4.4.3 Homöostase und ultrastabile Systeme
4.4.4 Autopoietische Systeme
4.4.5 Lebensfähige Systeme
4.5 Kybernetik in der Softwareentwicklung kritisch reflektiert

5 AGILES PROJEKTMANAGEMENT AUS SICHT DES LEBENSFÄHIGEN SYSTEMS
5.1 Methodik der Analyse
5.2 Systembildung: Einordnung in Rekursionsebenen
5.2.1 Rekursionsebene-1: Das betrachtete System
5.2.2 Rekursionsebene-2: Untergeordneten Systeme
5.2.3 Rekursionsebene-0: Übergeordnete Systeme
5.3 Elementare Organisationseinheit: Scrum-Team
5.3.1 Aufgaben der elementaren Organisationseinheit im Viable System Model
5.3.2 Ableitung von Anforderungen an agile Software-Entwicklung
5.3.3 Diagnose der Ist-Situation
5.3.4 Gestaltungshinweise und Einblicke in die Praxis
5.4 System 1: Verbund mehrerer Scrum-Teams
5.4.1 Aufgaben des System-1 im Viable System Model
5.4.2 Ableitung von Anforderungen an agile Software-Entwicklung
5.4.3 Diagnose der Ist-Situation
5.4.4 Gestaltungshinweise und Einblicke in die Praxis
5.5 System-2 : Mehrere Scrum-Teams und deren Koordination
5.5.1 Aufgaben des System-2 im Viable System Model
5.5.2 Ableitung von Anforderungen an agile Software-Entwicklung
5.5.3 Diagnose der Ist-Situation
5.5.4 Gestaltungshinweise und Einblicke in die Praxis
5.6 System-3: Scrum-Teams operativ steuern
5.6.1 Aufgaben des System-3 im Viable System Model
5.6.2 Ableitung von Anforderungen an agile Software-Entwicklung
5.6.3 Diagnose der Ist-Situation
5.6.4 Gestaltungshinweise und Einblicke in die Praxis
5.7 System 4: Das Projekt langfristig Ausrichten
5.7.1 Aufgaben des System-4 im Viable System Model
5.7.2 Ableitung von Anforderungen an agile Software-Entwicklung
5.7.3 Diagnose der Ist-Situation
5.7.4 Gestaltungshinweise und Einblicke in die Praxis
5.8 System 5: Identität und Projektleitlinien
5.8.1 Aufgaben des System-5 im Viable System Model
5.8.2 Ableitung von Anforderungen an agile Software-Entwicklung
5.8.3 Diagnose der Ist-Situation
5.8.4 Gestaltungshinweise und Einblicke in die Praxis

6 ERGEBNISSE UND AUSBLICK
6.1 Untersuchungsverlauf und -Ergebnisse
6.1.1 Untersuchungsergebnis zu: Erarbeitung von Problemfeldern agiler Scrum-Projekte
6.1.2 Untersuchungsergebnis zu: Modellabbildung und Interpretation
6.1.3 Untersuchungsergebnis zu: Ableitung von Gestaltungshinweisen
6.2 Ausblick auf weiteren Forschungsbedarf

7 GLOSSAR

8 ANHANG: GESTALTUNGSHINWEISE FÜR AGILE PROJEKTE

9 LITERATURVERZEICHNIS

TABELLEN

Tabelle 1: Elemente eines Regelkreises

Tabelle 2: Diagnoseergebnisse der elementaren Organisationseinheit

Tabelle 3: Diagnoseergebnisse des System-1

Tabelle 4: Diagnoseergebnisse des System-2

Tabelle 5: Identifizieren von Synergiepotenzialen

Tabelle 6: Laufende Beobachtung zur Früherkennung von Oszillationsquellen

Tabelle 7: Diagnoseergebnisse des System-3

Tabelle 8: Beobachtung der Umwelt durch das agile Projekt

Tabelle 9: Diagnoseergebnisse des System-4

Tabelle 10: Diagnoseergebnisse des System-5

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

Tabelle 12: Korrelation zwischen Untersuchung und Problemfeldern

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

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

2 Einführung

2.1 Ausgangssituation

Moderne Software ist komplex^[1]. 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 geschei­terten 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 metho­dischen Vorgehen abhängt (vgl. Becker/Huber, 2006, S. 5)^[2]. Das zu erstellende Soft­wareprodukt 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" des Entwicklerteams im 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 traditio­nellen 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 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^[3]. Stafford Beer, einer ihrer Pioniere, veröffentlichte 1959 ein Modell, das die Voraussetzungen für überlebensfähige komplexe Organisationen beschreibt (vgl. Beer, 1959). Als „Modell des lebensfähigen Systems" („Viable System Model", kurz VSM) findet 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­projekten helfen. Projekte sind „Organisationen auf Zeit" (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^[4]:

- Minimieren der Projektkosten
- Minimieren der Projektdauer
- Maximieren der Qualität
- 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:

- 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 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^[5] der vorliegenden Arbeit ist ein nicht triviales Scrum-Projekt. „Nicht trivial" bedeutet in diesem Zusammenhang, der Projektablauf ist als Ganzes nicht im Detail vorhersehbar und die Projektabwicklung erfordert eine komplizierte Struktur, bestehend aus mehreren kooperierenden Teams^[6].

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
a) Abbilden des Untersuchungsobjekts auf das Viable System Model
b) Identifizieren und Interpretieren von Abweichungen

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 Untersuchungs­objekt 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^[7], 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.

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).

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

- 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 Projektkosten, -termine und -ergebnisse beeinflussen. Das Projekt muss der hohen Dynamik in technischer und fachlicher Umwelt flexibel entgegentreten, um nicht zu scheitern^[8].

- 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 aufgrund fehlender Normierung breit gefächert^[9]. 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

Das Wort „agil" hat seinen Ursprung im Lateinischen „agilis" und bedeutet übersetzt „beweglich", „gewandt" (vgl. Duden Online, 2009). Übertragen auf die Software­entwicklung 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-Alliance im „Manifesto for Agile Software Development" wie folgt formuliert (Beck et al., 2001a)^[10]:

Individuen und Interaktionen sind wichtiger als Prozesse und Tools 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.

"Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.

Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity--the art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly."
(Beck et al., Principles behind the Agile Manifesto, 2001b).

Der Begriff „agiles Vorgehensmodell" dient der Klassifizierung verschiedener konkreter Vorgehensmodelle. Unter einem Vorgehensmodell versteht man in der Software­entwicklung 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 beispiels­weise 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 „agil" mehr und mehr zum Trendwort wird. Jedes Team sieht sich als agil - 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 der „Agilität" noch schwerer greifbar (vgl. Götzenauer, 2006, S.80), (vgl. Bomarius/Iida, 2004, S. 437ff.)^[11].

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 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 30 Tage dauernde Zeitscheiben unterteilt. Eine Iteration wird in Serum „Sprint" genannt 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 ü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.):

- Product-Owner
- Scrum-Master
- 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 verantwortlich. Diese wird in Scrum „Product-Backlog" genannt und 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.

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.):

- Sprint-Planning-Meeting
- Daily-Scrum-Meeting
- Sprint-Review-Meeting
- 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 wird in Scrum „Commitment" genannt. 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 im Sprint-Backlog zu besprechen und aktuelle Soll- und Istwerte zu vergleichen. Jeder beantwortet dabei reihum folgende Fragen:

- Was hat er/sie seit dem letzten Daily-Scrum getan?
- Was plant er/sie bis zum nächsten Daily-Scrum?
- 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-Einträge auf „erledigt" gesetzt werden können. Nicht 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.).

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.):

- Product-Backlog
- Sprint-Backlog
- Burndown-Chart
- Impediment-Log
- 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.

Abbildung in dieser Leseprobe nicht enthalten

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

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.

Abbildung in dieser Leseprobe nicht enthalten

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

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-Eintrag festgelegten Definition von „erledigt" 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 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:

- Der Product-Owner definiert das Product-Backlog und priorisiert die Einträge darin nach deren wirtschaftlichem Nutzen.
- 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.
- 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.
- Ergebnis des Sprints ist das lauffähige Produktinkrement, das im Sprint-Review dem Product-Owner präsentiert wird.
- 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.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Scrum-Zyklusmodell

in Anlehnung an (Kriegisch, 2009)

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:

- Koordination der technischen Aspekte zwischen den Teams
- Koordination der fachlichen Aspekte zwischen den Product-Ownern
- Koordination der Prozess-Aspekte zwischen den Scrum-Mastern

In der Literatur gibt es unterschiedliche Meinungen, wie mit dem Problem „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.

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).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Skalierung mit Scrum-of-Scrums

in Anlehnung an (Cohn, 2007)

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.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Rekursive Scrum-of-Scrums

in Anlehnung an (Cohn, 2007)

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).

Abbildung in dieser Leseprobe nicht enthalten

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

in Anlehnung an (Gloger, 2008b, S. 256)

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 gerne übersehen, dass mit Teams dieser Größenordnung auch das traditionelle Projektmanagement durchaus erfolgreich ist (vgl. Becker/Huber, 2006, S. 5)^[12], denn die Komplexität ist in derartigen Projekten in der Regel leicht überschaubar und das Projekt gut kontrollierbar. Wesentlich interessanter ist eine koordinierte Entwicklung mehrerer kooperierender Teams. Mit ihnen steigt der Kommunikationsbedarf der Beteiligten, der aber nur durch eine geeignete Struktur gedeckt werden kann (vgl. Gloger, 2008b, S. 278). Mit Blick auf große agile Projekte, bestehend aus mehreren Teams, lassen sich Bezug nehmend auf die Formalziele aus Kapitel 2.2 folgende Problemfelder im agilen Vorgehen mit Scrum identifizieren:

3.4.1 Problemfeld „Projektorganisation"

a) Evolutionäres Entstehen der Projektorganisation über Selbstorganisation ist abhängig von den Erfahrungen der Beteiligten und nicht immer erfolgreich. Betroffene Formalziele: Projektkosten, Projektdauer, Skalierbarkeit.

Gelingt die Selbstorganisation im Team, so tritt Emergenz^[13] auf und aus dem Team wird ein hochperformantes Team (vgl. Gloger, 2008b, S. 67). Im anderen Fall droht jedoch Chaos und damit ein Scheitern des Projekts (vgl. Mainzer, 2008, S. 113).

b) Die mit Scrum propagierte absolute Freiheit des Teams ist nicht vereinbar mit der koordinierten Erstellung eines Softwareprodukts durch mehrere Teams.

Betroffenes Formalziel: Skalierbarkeit

Jedes Team ist Teil einer Organisation. In großen Projekten bildet die Projektorganisation das Dach, unter dem die Teams miteinander kooperieren. Scrum fordert jedoch uneingeschränkte Autonomie und freie Selbstorganisation (vgl. Gloger, 2008b, S. 207), was im Kontext großer Projekte vor allem anfänglich Unruhe oder gar Instabilität erzeugen kann.

3.4.2 Problemfeld „Projektdurchführung"

a) Das Sprintvorgehen, der hohe Grad an Transparenz und Auslieferungen von Produktinkrementen in kurzen Zeitabständen sind eine dauerhafte Belastung für das Team.

Betroffenes Formalziel: Qualität.

Da Scrum in den täglichen Abstimmungsrunden und mit Hilfe des Sprint- Burndown-Charts Fortschritte jedes einzelnen für alle transparent macht, entsteht unter Umständen ein sehr hoher Druck auf Einzelpersonen. Weiterhin erzeugt das selbstgesteckte Gruppenziel, zum Ende eines Sprints einen versprochenen Funktionsumfang realisiert zu haben, Druck auf die gesamte Gruppe. Da die Taktung der Sprints typischerweise sehr dicht ist, besteht die Gefahr einer dauerhaften Überlastung (vgl. Sharma, 2009).

b) Fachliche Anforderungen konkretisieren sich unter Umständen erst im Projektverlauf und können vorher nicht eingeschätzt werden.

Betroffene Formalziele: Projektkosten, Projektdauer, Qualität.

Mit dem Ausblick hin zu einem evolutionären Entwicklungsprozess entfällt aus Kundensicht die Notwendigkeit, das geplante Produkt vorab vollständig zu durchdenken. Der Kunde skizziert Anforderungen zunächst nur vage und nimmt ggf. neue Punkte in das Product-Backlog auf (vgl. Waters, 2009). Eine reibungslose Implementierung wird stillschweigend erwartet. Dies ist aber nicht immer möglich, da die zu Beginn der Entwicklung getroffene Wahl einer Softwarearchitektur immer auch Restriktionen mit sich bringt (vgl. Malich, 2008, S. 23).

3.4.3 Problemfeld „Projektsteuerung"

a) Der Prozess der Entscheidungsfindung ist unklar und zeitaufwändig.

Betroffenes Formalziel: Skalierbarkeit

Da Kompetenzen selbständig zwischen den beteiligten Personen und Teams ausgehandelt werden müssen, ist das Konfliktpotenzial gegenüber streng hierarchischen Organisationen grundsätzlich höher. Zusätzlich dauern Lösungs­und Entscheidungsfindung vergleichsweise länger (vgl. Wikimedia, 2009c).

b) Die Koordination einzelner Teams über das Konzept der rekursiv organisierten Besprechungen (vgl. Kapitel 3.3.5) ist nicht ausreichend.

Betroffene Formalziele: Skalierung, Qualität, Funktionsmenge.

Verschiedene Teams haben unterschiedliche Motivation, kämpfen mit unterschiedlichen Problemen und tendieren dazu, vorrangig ihre eigenen Ziele erreichen zu wollen. Es fehlen Hilfestellungen, wie trotz Reibung möglichst effizient ein gemeinsames Produkt entwickelt werden kann (vgl. Shalloway/Trott/Beaver, 2009, S. 86).

Mögliche Lösungsideen liefert die Kybernetik. Sie beschäftigt sich seit vielen Jahren mit dem Phänomen der Komplexität und mit der Frage, welche Merkmale eine Organisation aufweisen muss, um sie trotz der Komplexität im erforderlichen Maße steuern zu können.

Ob und inwieweit oben dargestellte Problemfelder damit adressiert werden können, untersucht die Arbeit im Anschluss an die nun folgende Einführung in die Kybernetik.

4 Komplexitätsorientiertes Management

Nachdem im vorhergehenden Kapitel der Bezugsrahmen aus Sicht agiler Softwareentwicklungsmodelle formuliert wurde, stellt das nun folgende Kapitel den notwendigen Kontext aus kybernetischer Perspektive her.

4.1 Bezugsrahmen Systemtheorie und Kybernetik

Die Systemtheorie bildet das Fundament für die Kybernetik und das systemorientierte Management. Sie beschäftigt sich mit dem Erkennen und Erforschen der Prinzipien von Systemen, sowohl gedanklicher als auch real existierender. Der Begriff des Systems nimmt in diesem Zusammenhang eine zentrale Rolle ein und wird daher in Kapitel 4.3.1 genauer betrachtet. Die Kybernetik widmet sich einem Teilausschnitt der Systemtheorie, nämlich dem der technischen Systeme, der sozialen Systeme und der Lebewesen. Systemorientiertes Management als weitere Spezialisierung fokussiert mit den sozialen Systemen einen Teil der Kybernetik. Eine Einordnung der Begriffe bietet eine Übersicht von Ulrich (Abbildung 8).

Die Arbeit beschäftigt sich überwiegend mit Aspekten der systemorientierten Managementlehre. Da aber viele der Überlegungen auf Erkenntnissen beruhen, die originär der Kybernetik entstammen, verzichtet sie auf eine exakte Unterscheidung und verwendet im Folgenden durchweg den allgemeineren Terminus „Kybernetik".

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Einordnung der Begriffe aus der Systemtheorie

(Schwaninger/Ulrich, 2001, S. 44)

4.2 Managementkybernetik in der Softwareentwicklung

Die Kybernetik befasst sich interdisziplinär mit den Aspekten der Struktur, der Lenkung und der Anpassungsfähigkeit von Systemen. Eine für diese Arbeit geeignete Definition des Begriffs kann wie folgt formuliert werden:

„Kybernetik, [griech. kybernetike (techne): ’Steuermannskunst’], die allgemeine, formale Wissenschaft von der Struktur, den Relationen und dem Verhalten dynamischer, insbesondere komplexer Systeme, die gewisse allgemeine Eigenschaften und Verhaltensweisen realer Systeme aus den verschiedensten Bereichen der Wirklichkeit widerspiegeln. [...]" (Brockhaus, 1989).

Begründet wurde die Kybernetik 1948 von Norbert Wiener mit der Veröffentlichung von „Cybernetics or Control and Communications in the Animal and the Machine" (vgl. Wiener, 1948). Mitte der 60er Jahre entwickelte sich im deutschsprachigen Raum die systemorientierte Managementlehre, auch Managementkybernetik genannt (vgl. Lehmann, 1974). Sie beschäftigt sich mit vom Menschen gestalteten soziotechnischen Systemen unter dem Aspekt der kybernetischen Steuerungs- und Regelungsmechanismen. Das Konzept des Feedbacks spielt in der Kybernetik eine ebenso große Rolle wie Selbstorganisation und Selbstreproduktion (vgl. Kapitel 4.4). Die Arbeiten des Begründers der Managementkybernetik Stafford Beer beleuchten Systeme aus allen Bereichen unter dem Aspekt ihrer Überlebensfähigkeit. Ziel von Stafford Beer ist es, Gemeinsamkeiten zwischen den Systemen zu identifizieren (vgl. Beer, 1979) (vgl. Beer, 1972), denn wenn es Gemeinsamkeiten im Sinne von Naturgesetzen gibt, die lebensfähige Systeme beeinflussen, dann muss sich diesen Gesetzen jedes lebensfähige System unterwerfen (vgl. Beer, 1972, S. 238). Ergebnis seiner Forschung ist das von ihm erarbeitete Modell lebensfähiger Systeme, welchem ein hohes Problemlösungspotenzial für Diagnose und Gestaltung sozialer Systeme zugesprochen wird (vgl. Mulej, 2006, S. 965) (vgl. Malik, 2008, S. 441) (vgl. Kapitel 4.4.5).

Im Kontext der Softwareentwicklung besteht die Hoffnung, dass mit Hilfe der Managementkybernetik viele Facetten der Komplexität im Softwareentwicklungsprozess beherrschbarer werden. Konkret sind dies:

- Hilfestellung im Umgang mit den zahlreichen nicht-linearen, sich gegenseitig beeinflussenden Faktoren eines großen Entwicklungsprojekts.
- Hilfestellung zu Fragen der Koordination und Kommunikation in großen Projekten.
- Hilfestellung in der Teamentwicklung mittels Selbstorganisation.
- Hilfestellung zur optimalen Strukturierung großer Projekte.
- Hilfestellung zur optimalen Steuerung großer Projekte vorausschauend über die Zeit.

4.3 Systemaspekte in der Kybernetik

4.3.1 Systembegriff

Auf den ersten Blick scheint der Begriff „System" intuitiv klar. Will man ihn allerdings konkret definieren, merkt man schnell, wie wenig greifbar er im Grunde ist. Ursache dafür ist, dass die Abgrenzung eines Systems gegenüber seiner Umwelt stets ein subjektiver Vorgang ist. Was für den einen Beobachter ein System ist, kann ein zweiter Beobachter völlig unterschiedlich interpretieren. Eine mögliche und für diese Arbeit geeignete Begriffsdefinition liefert Stafford Beer, der ein System schlicht als eine Menge von Elementen sieht, die zueinander in Beziehung stehen^[14].

Auch in der Softwareentwicklung können Systeme gebildet werden. Ein Beispiel für ein System aus diesem Bereich ist das Projektteam. Es scheint wieder klar, wo die Systemgrenzen liegen. Gehört aber eine Projektassistenz, die einmal wöchentlich halbtags Auswertungen erstellt, zum Projektteam? Die Antwort ist sicherlich abhängig vom Beobachter, und somit auch die Systembildung in Abbildung 9. Die Menge der Elemente, im Beispiel die Menge der Teammitglieder, existiert also nicht per se, sondern entsteht erst durch die gedankliche Leistung des Betrachters. Verstärkt wird das Problem der Systembildung, insbesondere der beobachterübergreifenden Systembildung, noch durch die Tatsache, dass jedes System stets auch Teil anderer Systeme ist und selbst wiederum in untergeordnete Systeme unterteilt werden kann. So gehört ein Projektteam zu einem Projekt. Ein Mitarbeiter ist Teil eines - oder vielleicht auch mehrerer - Projektteams. Das Projekt könnte in einem Unternehmen abgewickelt werden oder aber zu einem Unternehmenskonsortium gehören.

Trotz all dieser Schwierigkeiten haben Systeme charakteristische Eigenschaften, nach denen sie klassifiziert werden können. Wichtige Gegensatzpaare sind (vgl. Wille, 1970, S. 139 ff.):

- Statische und dynamische Systeme
- Offene und geschlossene Systeme
- Stabile und instabile Systeme
- Determinierte und chaotische Systeme

Abbildung in dieser Leseprobe nicht enthalten

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

Bei der Unterscheidung zwischen dynamischen und statischen Systemen spielt das zeitliche Verhalten des Systems eine Rolle. Statische Systeme ändern ihren Zustand über die Zeit hinweg nicht, dynamische Systeme ändern sich über die Zeit hinweg (Abbildung 10). Dies kann sich auf die Struktur des Systems auswirken, auf die Beziehung zur Umwelt oder aber auf die Beziehungen zwischen den Systemelementen selbst (vgl. Jetzke, 2007, S. 200).

[...]

---

^[1] Der Begriff der Komplexität wird in Kapitel 4.3.3 eingeführt. Hier reicht das intuitive Beg ri ffsve rständnis.

^[2] 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%.

^[3] 1948 legte Norbert Wiener mit „Cybernetics: or Control and Communication in the Animal and the Machine" (MIT Press, 1948) den Grundstein zur Kybernetik. Er beschäftigte sich darin mit der Steuerung von Systemen.

^[4] Die Formalziele leiten sich aus dem als „Teufelsquadrat" genannten Zusammenhang zwischen Anforderungen, Dauer, Kosten und Qualität ab (vgl. Sneed, 2005, S. 5f.).

^[5] 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).

^[6] Der Begriff Kompliziertheit wird zusammen mit dem Begriff Komplexität in Kapitel 4.3.3 eingeführt.

Mit „lebensfähig" ist das Erhalten der eigenen Identität gemeint (Beer, 1979, S.113ff).

^[8] Die Forderung nach der Dynamik lässt sich direkt aus dem Gesetz der erforderlichen Varietät ableiten (vgl. Kapitel 4.3.3).

^[9] 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.

^[10] Die folgende deutsche Übersetzung ist angelehnt an (Hruschka/Rupp/Starke, 2009, S.2).

^[11] 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).

^[12] Die Studie kommt zu dem Ergebnis, dass bei einer Projektgröße von 4 Personen 60% der Projekte erfolgreich abgeschlossen wurden. Mit „erfolgreich" ist ein Abschluss zum angestrebten Termin, im vorgesehenen Budgetrahmen und mit dem geplanten Funktionsumfang gemeint.

^[13] Emergenz (lat. emergere = auftauchen) nennt man das Entstehen neuer Eigenschaften oder Strukturen aus dem Zusammenwirken der Elemente eines komplexen Systems (vgl. Willke, 2005, S. 52).

^[14] (Beer, 1979, S.7): „A System consists of a group of elements dynamically related in time according to some coherent pattern".