Ausgehend von der Frage: Warum überhaupt agil? wird gezeigt, dass es darum geht, mit Unplanbarkeit und Komplexität umzugehen, statt sie beherrschen zu wollen. Nach einer Darstellung der Vieldeutigkeit des Begriffs „agil” wird eine Reihe heute verbreiteter agil genannter Konzepte und Praktiken anhand exemplarischer Beispiele vorgestellt. Im einzelnen sind dies: Konzepte und Praktiken des agilen Entwickelns von Software (eXtreme Programming (XP)), Konzepte und Praktiken des agilen Managements von Projekten (PRINCE2, Dynamic Systems Development Method (DSDM/DSDM Atern)), Konzepte und Praktiken der agilen Neu- und Weiterentwicklung und Wartung von Produkten (Scrum, KANBAN/Kanban, Scaled Agile Framework for Enterprises (SAFe)) und „agile” Organisation.

von:

Hans-Peter Korn

1 Warum überhaupt agil? – Die Herausforderungen

Behände, flink, gewandt, regsam, geschäftig
Agil zu sein ist unbestritten attraktiv: Wer will denn nicht – gemäß dem Duden-Fremdwörterbuch – „behände, flink, gewandt, regsam, geschäftig” sein? Wer will als das Gegenteil von agil im Sinn seines lateinischen Ursprungs (agilis, abgeleitet von agere) gesehen werden, als nicht handelnd oder unbeweglich? Langsamkeit und Müßiggang (als sprichwörtlicher Anfang aller Laster) sind spätestens seit Martin Luther verpönt. Er schrieb: „Von Arbeit stirbt kein Mensch, aber von Ledig- und Müßiggehen kommen die Leute um Leib und Leben; denn der Mensch ist zum Arbeiten geboren wie der Vogel zum Fliegen.”

Wieso aber, obwohl „behände, flink, gewandt, regsam, geschäftig” immer schon erstrebenswert war, ist Agilität in den letzten rund zehn Jahren zu einem Modebegriff geworden? Was macht „Agilität” heute noch viel mehr als früher so attraktiv – oder sogar unabdingbar?

Einige Hinweise sind im seit 2009 vom amerikanischen Deloitte's Center for The Edge jährlich herausgegebenen Shift Index nachzulesen [1]. Im Shift Index wird seit 1965 bis heute die Performance von 20.000 US-Unternehmen analysiert.

Normalität ist Vergangenheit
Der Return on Assets (ROA) (vgl. [2]) sinkt seit Jahrzehnten kontinuierlich und ist heute nur noch knapp über null. Die Volatilität (vgl. [3]) der Aktienkurse nimmt zu. Die topple rate als Maß für den Verlust der Marktführerschaft großer Firmen hat sich mehr als verdoppelt. Die Treue der Kunden ist einer hohen Wahlbereitschaft gewichen. Produktinnovationen sind nicht mehr das Privileg hoch entwickelter Ökonomien, sondern werden mit immer rasanterem Tempo im asiatischen und pazifischen Raum entwickelt. Zwischen 1995 und 2006 haben die Wechsel der Chief Executive Officers (CEO) um 59 % zugenommen, die durch mangelnde Performance begründeten sogar um 318 %.

Und ein Drittel der 1970 in Fortune gelisteten 500 umsatzstärksten Unternehmen der Welt existierte 1983 nicht mehr. Von den 1917 von Forbes genannten 100 größten Firmen existierte 2001 nur noch eine, nämlich General Electric.

Stabilität – eine kaum erfüllbare Hoffnung
Deloitte's Shift Index 2011 zieht daraus die Schlussfolgerung, dass Normalität ein Ding der Vergangenheit sei und wir in eine Welt eingetreten seien, die sich nicht mehr so leicht wie früher stabilisiere.

2 Agil als Lösung?

Agil vorzugehen wird heute als Antwort auf diese Herausforderungen gesehen. Was aber bedeutet das ganz konkret? Was ist dabei anders als bei einem herkömmlichen Vorgehen?

2.1 Mit Unberechenbarkeit und Komplexität umgehen, statt sie beherrschen zu wollen

Die unbegrenzt erscheinende Menge der sich rasch verändernden und ständig wachsenden Informationen und die uns heute spontan mögliche weltumspannende Vernetzung nehmen wir als extrem komplex wahr. In immer mehr bislang einigermaßen voraussehbaren Lebensbereichen werden Planungen zunehmend zu unsicheren Prognosen oder gar nur zu Hoffnungen.

Es ist dann wie beim Überqueren eines frisch zugefrorenen und unbekannten Flusses, um die schemenhaft im Nebel am gegenüberliegenden Ufer erkennbare einfache, aber – vermutlich – gut beheizte Hütte zu erreichen.

Vorantasten auf unsicherem Eis
Die eine Vorgehensweise ist:

Vorsichtig, Schritt für Schritt, bei jedem Knistern die Richtung ändernd, versuchen wir die Überquerung. Und etwa in der Mitte lichtet sich der Nebel etwas und einige hundert Meter neben der Hütte erscheint ein sicher viel angenehmeres Hotel. Und, vorsichtig, Schritt für Schritt, ändern wir unsere Richtung in Richtung Hotel.

Eine andere Vorgehensweise wäre:

… oder tiefgehend analysieren und planbasiert voranschreiten?
Zunächst mit speziellen Wärmebild-Technologien die Beheizung der Hütte überprüfen. Wenn sie geeignet erscheint, wird sie als verbindliches Ziel definiert. Dann wird anhand der Klimawerte der letzten Wochen und der dokumentierten Erfahrungen der letzten Jahre die Eisdicke berechnet und mit Würfen von Steinen bekannten Gewichts und berechneter Ballistik stichprobenartig verifiziert. Dann den besten Weg über das Eis zur Hütte planen. Und dann diesen Weg, ausgerüstet mit Schwimmweste und einer langen Leiter, zügig und nach Plan hinter sich bringen.

Diese zweite Vorgehensweise entspricht einem von der technologischen Analysierbarkeit, Machbarkeit und Planbarkeit bestimmten Denken und ist Basis aller „plangetriebenen” Vorgehensmethoden der Produktentwicklung und des Projektmanagements auf der Grundlage eines möglichst frühen Big Design Up Front (BDUF).

Komplex: Ursache-Wirkung nicht im Voraus erkennbar
Die erste Vorgehensweise hingegen entspricht den Erkenntnissen im Umgang mit Complex Adaptive Systems, wie sie u. a. von Edwin E. Olson und Glenda H. Eoyang beschrieben werden [4]. Geprägt ist diese Vorgehensweise von der Einsicht, dass uns Situationen als komplex dann erscheinen, wenn wir Beziehungen zwischen Ursache und Wirkung nur im Nachhinein erkennen können, nicht aber im Voraus. Unser Vorgehen beruht dann auf Handeln-Beobachten-Reagieren und emergenten Praktiken („emergent” bedeutet in Bezug auf Eigenschaften eines Systems: unerwartet neu auftretend, plötzlich aufbrechend). Im Gegensatz dazu stehen die uns kompliziert erscheinenden Situationen mit – wenn auch sehr aufwendig – analysierbaren und voraussagbaren Ursache-Wirkungs-Beziehungen oder den von uns als simpel betrachteten Situationen mit für alle offensichtlich erscheinenden Ursache-Wirkungs-Beziehungen [5].

Bei dieser ersten – empirischen – Vorgehensweise verzichten wir bewusst auf ein unangemessen aufwendiges und noch dazu unzuverlässiges BDUF. Stattdessen planen wir nur jeweils das für die nächsten Schritte wirklich Erforderliche auf der Basis der bisherigen Einsichten. Zu Beginn unseres Vorhabens gehen wir von einem Just Enough Design Up Front (JEDUF) aus.

Bei Komplexität: JEDUF statt BDUF
Dieser Wechsel vom BDUF mit seiner Paukenschlag(big bang)-Einführung der Lösung zum JEDUF mit seinen häufigen Einführungen von aufeinander aufbauenden Lösungsteilen (Lösungsinkrementen) und den die weitere Entwicklung steuernden raschen Feedbacks zeigt sich exemplarisch in der Softwareentwicklung (als wesentlichem Treiber des agilen Vorgehens) in den letzten 30 Jahren [6]:

James Martin prägte ab dem Ende der 1980er-Jahre mit seinen Büchern [7] die von sequenziellen und jeweils etliche Monate dauernden Phasen (Analyse, Konzept, Realisierung, Einführung) bestimmten wasserfallartigen, betont arbeitsteiligen und stark werkzeugunterstützten Vorgehensweisen. Spätestens seit der Jahrtausendwende erleben wir jedoch einen immer deutlicheren Wechsel hin zu flexiblen, schlanken und stark teamorientierten Entwicklungsmethoden, die in jeweils wenigen Wochen verfügbare und konkret nutzbare Teilergebnisse liefern. Dabei wird im Bereich von Architektur und Design auf den intensiven Einsatz von Modellierungswerkzeugen verzichtet. Stattdessen erfolgt die Software-Realisierung (das Programmieren und Testen) zu einem möglichst hohen Grad toolunterstützt und – beim Testen – automatisiert.

Inkrementell-adaptiv vorgehen ist psychologisch schwierig
Der Wechsel weg vom ab Beginn im Detail ingenieurmäßig analysierten, modellierten und durchgeplanten Vorgehen hin zum nur grob im Voraus abgesteckten und danach schrittweise angepassten inkrementell-adaptiven Vorgehen ist natürlich auch eine psychologische Herausforderung: In der Regel ist es vielen von uns wohler, wenn wir einem detaillierten Plan folgen können [8].

Testen Sie es selbst: Lesen Sie doch jetzt nochmals die zwei Vorgehensweisen zum Überqueren des zugefrorenen Flusses. Hand aufs Herz: Bei welcher wäre Ihnen wohler? Welche würden Sie insbesondere im professionellen Kontext, etwa als verantwortlicher Leiter von Winterexpeditionen mit Gruppen von jeweils 12 Personen, bevorzugen?

Und Sie werden sich möglicherweise jetzt auch fragen, wie denn physische Dinge wie ein Eisenbahntunnel inkrementell-adaptiv realisiert werden können, sodass die einzelnen Teilergebnisse – beim Tunnel die ersten paar hundert Meter Rohbau – praktisch nutzbar sind. Eine etappenweise Nutzung ist hier nicht möglich. Möglich ist jedoch, nach den ersten paar hundert Metern bereits zu erkennen, inwieweit die gewählte Bohrtechnik modifiziert werden muss. Daraus kann sich eine wesentliche Erhöhung der geplanten Kosten und Termine ergeben. Das als Fehlplanung negativ zu werten ist Zeichen einer zu großen Planungsgläubigkeit.

In vielen Fällen ist das inkrementell-adaptive Vorgehen nur beim Design und der Konstruktion möglich (und wird im Übrigen auch seit Langem praktiziert), bei der physischen Realisierung jedoch sind Adaptionen nur sehr begrenzt möglich. So etwa ist es kaum möglich, bei einem Eisenbahntunnel mittendrin in eine ganz andere Richtung weiter zu bohren, weil sich dort das Gestein besser zum Bohren eignet.

Inkrementell-adaptiv erfordert Zergliederung in nutzbare Lösungsteile
Die Entwicklung von Software kann verglichen werden mit dem inkrementell-adaptiven Komponieren eines Musikstücks unter Nutzung eines bereits vorhandenen Klaviers. Teile der Komposition können auf dem Klavier zur Überprüfung vorgespielt und dann angepasst werden. Das Komponieren entspricht dem Programmieren, das Klavier ist die bereits verfügbare IT-Hardware. Ein Klavier jedoch kann ich nur sehr beschränkt (wenn überhaupt) inkrementell-adaptiv so bauen, dass ich bereits mit seinen ersten Teilprodukten klaviermäßig musizieren kann.

2.2 Die Vieldeutigkeit des Begriffes agil

1950
AGIL erscheint in den 1950er-Jahren beim amerikanischen Soziologen Talcott Parsons als Akronym für vier überlebenswichtige Funktionen lebender und somit auch sozialer Systeme [9]:

A:	Anpassung (Adaptation) an die Umwelt
G:	Zielerreichung (Goal-Attainment)
I:	Integration als Mechanismus zur Leistungserbringung der Teilsysteme untereinander
L:	Strukturerhaltung oder Latenz als Mechanismus zur Erhaltung der Identität des Systems, obwohl alles stetig im Wandel ist

1997
Im 1997 erschienenen Buch „Komplexität und Agilität: Steckt die Produktion in der Sackgasse?” beleuchtet eine Reihe von Beiträgen „… die Widersprüche zwischen Komplexität im Produktionsumfeld und Agilität im Markt … und [gibt] Perspektiven für deren Auflösung. Insbesondere wird den Fragen nachgegangen, was Management heute und in Zukunft bedeutet, wohin sich die Märkte bewegen werden und wie man ihnen folgt, wie die technischen Innovationen aussehen und was sie bewirken werden und wie sich die industrielle Produktion durch neue Technologien und Organisationsprinzipien ändern wird.” [10]

2001
Im Februar 2001 trafen sich 17 Vertreter der damals leichtgewichtig genannten Methoden der Softwareentwicklung und formulierten das sie Verbindende als die vier Werte und zwölf Prinzipien des Agilen Manifests der Softwareentwicklung [11], auf das sich auch heute noch alle agilen Vorgehensweisen der Softwareentwicklung implizit oder explizit berufen.

Das war auch der Ausgangspunkt für die rasche Verbreitung des Begriffs „agil” und seine Ausdehnung auf andere Bereiche – und auch der Differenzierung seiner Bedeutung.

Heute
Heute können im Kontext der Produktentwicklung und des Projektmanagements, des Managements und der Organisationsgestaltung folgende vier Gruppen der Bedeutung von agil unterschieden werden:

Agil = Flexibilität und Adaptivität:

Basis Empirical Process Control
Diese Bedeutungsgruppe beruht auf der empirischen Prozesssteuerung. Das bedeutet ein Vorgehen in kleinen, stets gleich langen Schritten, ausgehend von einem möglichst leichtgewichtigen Just Enough Design Up Front. Jeder Schritt liefert dabei ein – wenn immer möglich bereits praktisch nutzbares – Teilergebnis, das Grundlage für Feedbacks zur Gestaltung des nächsten Schritts ist. Das Vorgehen in jedem Schritt wird im Team reflektiert, um kontinuierliche Verbesserung, also Lernen, zu erreichen.

Für Tom Gilb, der bereits in den 1970er-Jahren für ein evolutionäres IT-Projektmanagement eintrat, besteht die zentrale Bedeutung von „agil” in diesem inkrementell-adaptiven Vorgehen und kontinuierlichem Lernen. Und er meint, dass alle anderen agilen Taktiken optionale Details seien [6].

Diese Sicht entspricht auch der von Volker Nissen.

Er unterscheidet dabei zwischen einer „kapazitiven Agilität” als Fähigkeit der IT, auf schwankende mengenmäßige Anforderungen schnell antworten zu können (Skalierbarkeit, Performanz), und einer „funktionalen Agilität”, die sich auf die funktionalen Anforderungen bezieht. Bei vorhersehbaren Anforderungsänderungen spricht er von „reaktiver Agilität”. Wenn die IT jedoch eine aktive Rolle für das fachliche Geschäft übernimmt und unvorhergesehene Änderungen und IT-Innovationen aufspürt, spricht er von „proaktiver Agilität” [12].

Agil = Flexibilität und Adaptivität plus „Lean Management Principles”:

Zusätzlich zur obigen Bedeutung werden hier die Prinzipien des Lean Management als eigentliche Basis von „agil” gesehen, oft dargestellt als House of Lean, ausgehend von Larman und Vodde (2009) und The Toyota Way (2004) [13].

Wert schaffen
Das Ziel „Wert schaffen” als Dach des House of Lean ist gekennzeichnet durch:

•	Kurze Durchlaufzeiten
•	Beste Qualität und höchsten Wert
•	Höchste Kundenzufriedenheit
•	Niedrigste Kosten
•	Hohe Moral
•	Sicherheit

und wird getragen von den zwei Säulen:

•	Respekt für alle Personen
•	Kontinuierliche Verbesserung

Erreicht wird das Ziel durch spezifische Entwicklungsmethoden, basierend auf 14 Lean Principles.

Dieser Begriff von agil wird vertreten auch in der Definition von Agilität gemäß Lexikon IT-Management [14].

Agil = Flexibilität und Adaptivität plus „Lean Management Principles” plus diverse post-tayloristische, hierarchie- und autoritätsfreie und selbststeuernd-kollaborative Prizipien und Überzeugungen:

Dieser Begriff von agil erscheint auch im IT-unabhängigen Kontext des Managements und der Organisationsgestaltung. Das im Agile Enterprise Adaptation Program der Agile Alliance entwickelte Modell ist ein Beispiel für diesen Begriff von agil [15].

Agiles Manifest der Softwareentwicklung
Auch das Agile Manifest der Softwareentwicklung [11] kann dieser Gruppe zugerechnet werden. Seine vier Werte lauten:

„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Funktionierende Software mehr als umfassende Dokumentation

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.”

Diese vier Werte und die weiteren zwölf Prinzipien sind, dem Charakter eines Manifests entsprechend, jedoch als Appell zu verstehen und nicht als „verifizierte Arbeitsregeln”. Sie dogmatisch als wortwörtlich zu erfüllende Handlungsanweisungen für die Software- oder Produktentwicklung in unterschiedlichsten Situationen zu betrachten wäre eine Fehlnutzung [16].

Agil = Aspekte zur Sicherung der Überlebens- und Entwicklungsfähigkeit:

Führung sozialer Systeme
Eine ganz andere, nicht auf die Software- und Produktentwicklung, sondern die Führung sozialer Systeme in risikoreichen und komplexen Missionen ausgerichtete Sicht von agil findet sich in „Power to the Edge”, einer Publikation des Command and Control Research Program des US Departement of Defense [17]:

•	Robustheit: die Fähigkeit, aufgaben-, situations- und bedingungsübergreifend effektiv zu bleiben;
•	Belastbarkeit: die Fähigkeit, sich von Unglücksfällen, Schäden oder einer destabilisierenden Störung der Umgebung zu erholen oder sich darauf einzustellen;
•	Reaktionsfähigkeit: die Fähigkeit, auf eine Veränderung der Umgebung rechtzeitig zu reagieren;
•	Flexibilität: die Fähigkeit, mehrere Lösungsmöglichkeiten einzusetzen und nahtlos von einer zur anderen überzugehen;
•	Innovationsfähigkeit: die Fähigkeit, neue Dinge zu tun und alte Dinge auf eine neue Art und Weise zu tun;
•	Anpassungsfähigkeit: die Fähigkeit, Arbeitsprozesse zu ändern, und die Fähigkeit, die Organisation zu ändern.

Diese Definition versteht unter Flexibilität im Gegensatz zu anderen Sichtweisen von agil nicht nur ein inkrementell-adaptives Vorgehen in kleinen Schritten, ausgehend von einem JEDUF, sondern lässt etwa auch ein stark plangetriebenes, BDUF-basiertes Vorgehen dann zu, wenn es für die aktuelle Situation passender und effizienter ist. Zu dieser Bedeutungsgruppe gehört auch das eingangs erwähnte Akronym „AGIL” von Talcott Parsons.

3 Heute verbreitete agile Konzepte und Praktiken

agil =
Wenn heute von agil gesprochen wird, wird es oft mit Scrum gleichgesetzt. Blicken wir jedoch nur ein Jahrzehnt zurück.

2002: eXtreme Programming
Damals, 2002, war das zu lesen: „Noch immer wird agile Entwicklung in weiten Kreisen gleichgesetzt mit eXtreme Programming. Dadurch wird die Chance vergeben, auch von den anderen Verfahren zu lernen” [18].

Heute: Scrum
Heute – rund ein Jahrzehnt später – wäre in diesem Artikel „eXtreme Programming” durch Scrum zu ersetzen.

… und in zehn Jahren?
Und dadurch wird – auch heute – die Chance vergeben, von den anderen derzeit verbreiteten weiteren agilen Verfahren zu lernen.

Jens Coldewey behandelte 2002 im oben zitierten Artikel sechs agile Konzepte und Praktiken:

Meta-Prozesse
Drei Meta-Prozesse, wie das Team zu einem individuellen Prozess kommt:

•	Adaptive Software Development,
•	die Crystal-Methodenfamilie und
•	Scrum.

Konzepte
Und drei Konzepte, die recht konkrete Verfahren und Techniken, die dann im Laufe des Projekts angepasst werden können, vorschlagen:

•	Dynamic Systems Development Method (DSDM),
•	eXtreme Programming (XP) und
•	Feature Driven Development (FDD).

Dominant im Jahr 2002 war XP. Heute, ein Jahrzehnt später, dominiert Scrum (allerdings nicht in Reinkultur, sondern zum größten Teil in diversen Abwandlungen) die agile Landschaft. Das zeigen übereinstimmend drei unabhängige Studien aus dem Jahr 2012 [19] [20] [21]:

Eingesetzte Vorgehensweisen
Gemäß diesen Studien setzten 2012 bei den antwortenden Firmen – je nach Studie – 51 bis 78 % agile Vorgehensweisen (oft parallel zu klassischen) ein. Davon nutzen 51 bis 84,5 % Scrum (bzw. ein an Scrum orientiertes Vorgehen); es steht damit in allen diesen Studien an erster Stelle. Bei zwei dieser drei Studien stand das vor zehn Jahren noch unbekannte Kanban mit 17 bzw. 43 % an zweiter Stelle, bei der dritten Studie mit 4,5 % an fünfter Stelle. Die Verbindung von Scrum mit Kanban (Scrumban) hatte eine Verbreitung von immerhin bereits 3 bis 8,5 %. Das vor zehn Jahren dominierende eXtreme Programming (XP) stand mit 5,5 bis 33 % Verbreitung in allen Studien nur noch an vierter Stelle, wobei allerdings viele der ursprünglichen XP-Praktiken (wie z. B. User Stories) heute als integraler Bestandteil von Scrum praktiziert werden.

Weitere verbreitete agile Vorgehensweisen waren 2012 u. a. IBM Rational Unified Process (RUP), Agile Unified Process, Open Unified Process, Feature Driven Development, Usability Driven Development und unterschiedliche hybride Vorgehensweisen.

Klassische Vorgehensweisen übernehmen inkrementell-adaptive Elemente
Die vor rund zehn Jahren noch recht bekannte Vorgehensweise Adaptive Software Development und die Crystal-Methodenfamilie haben heute kaum noch Bedeutung. Das Feature Driven Development (FDD) hat nur noch eine begrenzte Verbreitung und die Dynamic Systems Development Method (DSDM/DSDM Atern) ist nach wie vor in Großbritannien – auch bei Großprojekten von Behörden – sehr bekannt. Hingegen stoßen heute weitere etablierte Vorgehensweisen mit immer schon iterativen Elementen wie der Rational Unified Process (RUP) und PRINCE2 (Projects in Controlled Environments) in den Bereich der agilen Vorgehensweisen vor, indem sie ihre iterativen Elemente verstärken. Auch bislang an ausgeprägten sequenziellen Phasen orientierte klassische Vorgehensweisen wie das Schweizer HERMES und das V-Modell XT öffnen sich für eine Kombination mit inkrementell-adaptiven Vorgehensweisen zumindest im Sinn eines hybriden Vorgehens.

Typisch agil
In den nächsten zehn Jahren wird sich die agile Methodenlandschaft sicher auch weiterhin erheblich verändern. Wohin die Reise geht, ist schwer abzuschätzen. Möglicherweise wird es dann agile Vorgehensweisen geben, an die wir heute noch gar nicht denken … wie im Jahr 2002 in der Softwareentwicklung noch niemand an Kanban dachte. Und möglich ist auch, dass in zehn Jahren ein anderes Label als typisch agil in aller Munde ist.

3.1 Konzepte und Praktiken des agilen Entwickelns von Software

Inkrementell-adaptive SW-Entwicklung schon in den 1970er-Jahren
Begonnen hat das inkrementell-adaptive Vorgehen zur Lieferung praktisch nutzbarer Software-Lösungen im Abstand von nur wenigen Wochen bereits in den 1970er-Jahren, gefördert u. a. durch Tom Gilb. Also noch vor dem Entstehen des stark plangetriebenen Vorgehens mit seinem BDUF in den 1980er-Jahren, das insbesondere vom James Martin mit seinem Information Engineering [7] vorangetrieben wurde. Diese frühen inkrementell-adaptiven Vorgehensweisen wie etwa das Rapid Application Development (RAD) wurden jedoch als eher chaotisch empfunden und die 1997 erstmals publizierte Dynamic Systems Development Method (DSDM) – damals noch eine reine Software-Entwicklungsmethode – hatte das Ziel, hier etwas mehr Disziplin zu schaffen.

Dass ein inkrementell-adaptives Vorgehen mit in jeweils wenigen Wochen verfügbaren Lösungsinkrementen in der Software-Entwicklung entstand, hat einen einfachen Grund:

Die Entwicklung von Software ist im Wesentlichen die Herstellung einer modellhaften Beschreibung automatisierbarer Funktionen als in einer speziellen Kunstsprache (Java, C#, COBOL …) formulierter Text. Für die Ausführung dieser so beschriebenen Funktionen ist das Informations- und Kommunikationstechnik(ICT)-System als bereits vorhandenes physisches System vorbereitet. Es kann diese Funktionen leisten, indem der maschinenlesbare Text der Funktionsbeschreibung (= der Programmcode) das Verhalten des ICT-Systems steuert. Das Entwickeln von Software ist – wie weiter oben bereits erwähnt – vergleichbar mit dem stückweisen Komponieren und Spielen und Überarbeiten eines neuen Musikstücks auf einem bereits vorhandenen Instrument, ohne das Instrument selbst zu verändern.

Physische Produkte: Konstruktion inkrementell-adaptiv möglich
Physische Produkte hingegen wie etwa eine Autobahnbrücke können nicht oder nur sehr schwer in kleinen und stets bereits nutzbaren Lösungsinkrementen realisiert werden. Deren Konstruktions- und Fertigungspläne hingegen können immer inkrementell-adaptiv erstellt werden – und das ist seit Langem auch durchaus üblich.

3.1.1 eXtreme Programming (XP)

Charakteristik und Herkunft [22]

XP geht davon aus, dass Software nicht auf der Basis bereits zu Beginn möglichst vollständig erhobener Anforderungen realisiert und danach eingeführt werden kann, sondern dass sich die Anforderungen kontinuierlich und differenzierter erst im Verlauf der schrittweisen Realisierung einzelner Softwareteile (Inkremente) ergeben. Diese Software-Inkremente müssen vom Benutzer getestet oder – besser – praktisch genutzt werden können. Daraus ergeben sich dann weitere und noch spezifischere Anforderungen. Jedes Software-Inkrement wird dabei innerhalb einer Iteration von einer bis maximal vier Wochen realisiert.

Vier Basisaktivitäten
Eine Iteration umfasst die vier Basisaktivitäten:

•	Zuhören (als Entwickler darauf hören, was der Benutzer haben will)
•	Entwerfen (als Entwickler eine übergeordnete Konzeption dazu entwickeln, wie die Software möglichst einfach und daher gut erweiterbar und änderbar strukturiert sein soll)
•	Programmieren, eng verzahnt mit
•	Testen (wobei idealerweise zunächst die Testfälle erarbeitet und erst dann – mit kontinuierlichem Testen – programmiert wird)

Eine möglichst enge Zusammenarbeit der Benutzer und der Software-Entwickler und eine direkte Kommunikation sind dabei unabdingbar. So etwa werden die Anforderungen aus Benutzersicht nur als grobe Anwendungsfälle mit wenigen Sätzen als User Stories beschrieben. Sie sind keine umfangreichen und verbindlichen Detailspezifikationen, sondern dienen als Diskussionsanstöße für den Benutzer und Entwickler dann, wenn die Anforderung unter Mitwirkung des Benutzers konkret realisiert werden soll.

Detailanforderungen im persönlichen Gespräch
Zu Beginn jeder Iteration klären die Entwickler mit dem Benutzer, welche der ihm wichtigsten Anforderungen (Features) innerhalb der den Entwicklern verfügbaren Ressourcen realisiert werden sollen. Bei der anschließenden Konzeption (z. B. anhand von Mock-ups oder Prototypen) und der Phase des Realisierens und Testens bleibt die enge Zusammenarbeit zwischen Benutzer und Entwickler erhalten.

Den Iterationen übergeordnet ist die Planung mehrere Iterationen umfassender Releases.

XP wurde erstmals ab 1996 von Kent Beck, Don Wells, Ward Cunningham und Ron Jeffries zur Erstellung von Software im Bereich der Lohnabrechnung (Comprehensive Compensation System) bei Chrysler entwickelt. 1999 veröffentlichte Don Wells XP als Hypertext [23] und Kent Beck in Buchform [24]. Damit begann auch die weltweit rasante Verbreitung von XP.

Fünf Werte
Es existiert zwar nicht die eine verbindliche Definition von XP, alle seine Beschreibungen beruhen jedoch auf diesen fünf Werten:

•	Kommunikation
•	Einfachheit
•	Rückmeldung
•	Mut
•	Respekt

Je nach Quelle werden spezifische Prinzipien und je nach Autor unterschiedlich strukturierte Sammlungen konkreter Praktiken, Techniken oder Regeln für die Softwareentwicklung, die Arbeit im Team und für die Benutzer genannt.

Getragen wird XP heute von international vernetzten Softwareentwicklern, die sich in vielen Foren und auf Konferenzen (z. B. dem XP day Germany) austauschen. Zentrale Referenzen für all das, was XP aktuell umfasst, sind nach wie vor die Bücher von Kent Beck und die von Don Wells editierte Website „extremeprogramming” [22]. Nutzung und Schulung von XP sind an keinerlei Lizenzen gebunden.

XP-Methoden oft in Scrum integriert
Einige Methoden von XP werden heute insbesondere im Rahmen von Scrum eingesetzt und daher oft auch als integraler Bestendteil von Scrum betrachtet, wie etwa die User Stories.

Das Spezielle im Hinblick auf den Umgang mit Unberechenbarkeiten und Komplexität

Verstehen entsteht im Dialog
Ganz zentral bei XP ist die möglichst synchrone, persönliche und spontane Kommunikation zwischen Benutzer und Entwickler und im Team. Dahinter steht die Einsicht, dass Verstehen in unvertrauten Situationen am einfachsten und zuverlässigsten im Dialog entsteht und nicht durch das Schreiben, Lesen und Kommentieren umfassender Dokumente.

XP verlangt möglichst einfache Lösungen. Eine Technik dafür ist die fortlaufende Überprüfung und Überarbeitung der bereits realisierten Lösungen (refactoring): Was ist unnötig? Was ist doppelt? Was kann noch einfacher gelöst werden?

XP beruht auf der Realisierung überprüfbarer Lösungsteile nach längstens vier Wochen und damit auf entsprechend raschen und häufigen Rückmeldungen der Nutzer. Diese Rückmeldungen sind Anlass zur Anpassung der Release- und Iterationsplanung.

Häufige bis kontinuierliche Integration
XP fordert eine sehr häufige (ein- bis mehrmals pro Tag) Integration getesteter Teillösungen ins Gesamtsystem und fortlaufende Tests des Gesamtsystems. Damit sind Fehler rasch erkennbar und lokalisierbar.

Konsequenzen beim Praktizieren innerhalb üblicher Organisationen

Dass Anforderungen zu Beginn der Realisierung nur grob formuliert und erst im Verlauf der schrittweisen Realisierung weiter konkretisiert und durchaus auch verändert werden können, steht im Gegensatz zum vertrauten und insbesondere projektorientierten Vorgehen. Das ist zwar typisch für alle agilen Vorgehensweisen, bei XP aber besonders stark ausgeprägt.

Fortlaufende Mitarbeit entscheidungsbefugter Benutzer
Dass Anforderungen nicht schon zu Beginn im Detail formuliert, sondern erst im Verlauf der schrittweisen Lösungsrealisierung vom Benutzer bzw. Kunden zusammen mit den Entwicklern im Dialog erarbeitet werden, erfordert die kontinuierliche und rasche Verfügbarkeit der Benutzer bzw. Kundenvertreter für die Entwickler.

Diese Benutzer bzw. Kundenvertreter müssen das neben – oder anstelle – ihrer üblichen Arbeit organisieren können und zusätzlich müssen sie in der Lage sein, alle Arten von Benutzern bzw. Kunden zu vertreten. Und sie müssen das Vertrauen genießen, ohne langwierige Genehmigungsverfahren selbst Entscheidungen fällen zu dürfen. Abstimmerfordernisse mit übergeordneten Koordinationsinstanzen wie etwa dem Produktmanagement oder Budgetverantwortlichen müssen diese Benutzer bzw. Kundenvertreter selbst erkennen.

Räumliche Zusammenarbeit
Je stärker die Organisationsstruktur auf einer arbeitsteiligen Spezialisierung beruht, umso schwieriger wird es sein, in sich abgeschlossene und funktional überprüfbare (besser noch praktisch nutzbare) Lösungsteile in einer bis vier Wochen zu realisieren. Es muss also – möglicherweise quer zur Organisationsstruktur – ein Team aus allen zur Konzeption, Realisierung und zum Testen nötigen Spezialisten gebildet werden. Dieses Team soll physisch in einem Teamraum und nicht nur virtuell und örtlich verteilt arbeiten. Auch das ist typisch für sämtliche agilen Vorgehensweisen.

3.2 Konzepte und Praktiken des agilen Managements von Projekten

Gibt es überhaupt ein „agiles” Management von Projekten?

Widerspruch zur klassischen Projektsicht
Im Abschnitt 2.1 wurden die beiden gegensätzlichen Vorgehensweisen beim Überqueren eines zugefrorenen Flusses beschrieben. Beim sich schrittweise vorantastenden Vorgehen ergab sich mitten auf dem Weg eine neue Richtung hin auf ein bequemeres Hotel, statt wie ursprünglich geplant zur Hütte. Wäre das Überqueren des Flusses ein Projekt, dann hätte sich das ursprüngliche Ziel deutlich verändert und vermutlich auch die Zeit für die Überquerung des Flusses. Stabil wären nur die eingesetzten Ressourcen (die Anzahl der mitwandernden Personen) und die Qualität geblieben (den Fluss sicher überqueren und eine möglichst angenehme Stube finden). Würden wir auch die verfügbare Zeit begrenzen, dann könnte es sein, dass noch auf dem Fluss einige Meter vor dem Ufer angesichts des Hotels die Überquerung zum Stillstand käme. Wir müssen also noch ein paar Weginkremente (also zusätzliche Zeit für die mitwandernden Personen) investieren, um dieses neue, aber bessere Ziel zu erreichen. Aus klassischer Projektsicht wäre das ein typisches aus dem Ruder gelaufenes Projekt, obwohl das Ergebnis schließlich besser ist als das ursprünglich geplante.

Die Flexibilität bezüglich des Ziels (oder Funktionsumfangs) der Produktentwicklung und allenfalls auch der Anzahl der erforderlichen Produktinkremente (die gesamte Durchlaufzeit) ist essentiell für das agile Vorgehen. Das „eiserne Dreieck” des klassischen Projektmanagements (fixer Umfang der Ergebnisse, fixe Kosten, fixe Zeit) wird damit ersetzt durch seine inkrementell-adaptive Variante (fixe Qualitätsansprüche, fixe Kosten, fixe Zeit → daran angepasste Ergebnisse). Auf vertraglicher Ebene passt zu dieser Variante der vielerorts beschriebene „Agile Festpreis”.

Abb. 1: Das veränderte „eiserne Dreieck”

Das aber passt schlecht zu Projekten im üblichen Sinn. Prof. Dr. Ayelt Komus (Hochschule Koblenz) schreibt dazu [25]:

„Agile Methoden wie Scrum sind keine Projektmanagementmethoden im eigentlichen Sinne. Ein Projekt, bspw. nach DIN 69901, ist durch seine „Einmaligkeit der Bedingungen in ihrer Gesamtheit” gekennzeichnet. Weiterhin werden Projekten klare Ziele und begrenzte zeitliche und finanzielle Ressourcen zugeschrieben. Scrum als besonders populäre agile Methode hingegen zeichnet sich eben dadurch aus, dass es einen festen Rhythmus gleicher Dauer und gleicher Personalressourcen anstrebt. Die Ziele werden laufend weiterentwickelt … Im Gegensatz zum klassischen Projektmanagement werden die jeweils im Fokus befindlichen Ziele an den Ressourcen ausgerichtet und nicht umgekehrt.”

Und in einem Interview zu dieser Studie sagt Prof. Komus [26]:

Projekte sind oft keine Projekte
„Interessanterweise werden oft Aufgabenstellungen als Projekte verstanden, die im eigentlichen Sinne gar keine sind. Schließlich ist mit der Einführung eines Softwareproduktes, eines Geschäftsprozesses, eines neuen Autos oder einer neuen SAP-Lösung die Arbeit nicht abgeschlossen. Vielmehr geht es um kontinuierliche Verbesserung der Lösungen und der Nutzung derselben. Wahrscheinlich ist das eines der Hauptprobleme klassischer Projektmanagementmethoden. Sie beruhen auf dem Gedanken: ‚Es gibt eine Fertigstellung und dann ist die Arbeit getan.’ Außerdem verleitet diese Denkweise dazu, viel zu große Aufgabenstellungen in einem Stück zu bearbeiten.”

Fokus auf Produkte statt Projekte
Dennoch, so schreibt Prof. Konus in der Langfassung der Studienergebnisse, finden „agile Methoden Eingang in das Projektmanagement – oft auch als Ergänzung oder Erweiterung in Form eines sogenannten ‚hybriden Ansatzes’, also einer vermischten bzw. kombinierten Form agiler und klassischer Methoden. An vielen Stellen werden eigentlich kontinuierliche Prozesse, deren Ziele und Ressourcen eben nicht zu Beginn feststanden, als Projekte gemanagt bzw. bezeichnet.”

3.2.1 PRINCE2

Charakteristik und Herkunft [27] [28] [29]

Weltweit am verbreitetsten
PRINCE2 (ein Akronym für Projects in Controlled Environments) ist einer der weltweit am meisten verbreiteten und für alle Arten von Projekten einsetzbaren Projektmanagement-Standards.

Es ist der De-facto-Standard für Projekte in Großbritannien und die Standardmethode für die Projektmanager-Trainings der Vereinten Nationen. Derzeit verbreitet es sich stark auch in ganz Europa, vor allem in Deutschland, der Schweiz, Österreich, Italien, Frankreich und Polen. Für seine Nutzung (nicht aber seine Schulung) durch Personen und Firmen ist keinerlei Lizenz oder Zertifizierung erforderlich.

Merkmale von PRINCE2
Speziell an PRINCE2

•	ist seine konsequente und im Projektverlauf immer wieder überprüfte Ausrichtung auf die geschäftliche Rechtfertigung, dargestellt als Business Case, der fortlaufend aktualisiert wird;
•	ist die Strukturierung seines Ablaufs nach überprüfbaren aufeinander aufbauenden Teilergebnissen (Produkten);
•	ist die Gliederung in die Managementphasen: Initiierungsphase und danach eine oder mehrere Durchführungsphasen (die jeweils die Produktinkremente liefern);
•	ist, dass am Ende jeder Phase und nicht nur am Projektende die gemachten Erfahrungen gesammelt werden (das Projekt als lernende Organisation) und der Business Case überprüft und aktualisiert wird;
•	ist, dass es zu Beginn über das gesamte Projekt hinweg nur eine grobe Konzeption und Planung gibt, die Details aber jeweils erst zu Beginn einer Durchführungsphase nur für diese Phase erarbeitet werden;
Reduktion auf das Nötige (tailoring)
•	ist, dass es stets an die jeweilige Größe, Art und Umgebung des Projekts anzupassen ist und nicht sein umfangreicher Maximalumfang 1:1 genutzt werden soll (Tailoring). Im Minimum umfasst es nur diese vier Dokumentensätze: Projektleitdokumentation – Projektstatusberichte (auch mündlich möglich) – Projekttagebuch – Projektabschlussbericht;
•	ist, dass seine Rollenträger möglichst autonom innerhalb eines definierten Rahmens agieren.

Inkrementell-adaptiv bereits seit den 1990er-Jahren
Damit kommt PRINCE2 zentralen Elementen des inkrementell-adaptiven Vorgehens im Projektmanagement entgegen, erzwingt sie aber nicht. Es befasst sich jedoch nur mit den Arbeitsprozessen und Rollen bis zum Teammanager, nicht mit jenen auf der Teamebene selbst. Dort müssen spezifische Methodenrahmen wie Scrum, XP oder DSDM als Ergänzung angeschlossen werden.

Eigentümer von PRINCE2 ist das UK Office of Government Commerce, seit 2010 integriert in die Efficiency and Reform Group innerhalb des UK Cabinet Office. Zertifizierungen auf zwei Stufen bietet APMG an [30].

Der Ursprung von PRINCE2 ist die in den 1970er-Jahren von der britischen Regierung initiierte PROMPT-Methode, eine Sammlung der Best Practices der IT-Entwicklung. Daraus wurde 1989 als UK-Regierungsstandard für das IT-Projektmanagement PRINCE. 1996 entstand daraus PRINCE2 als allgemeine PM-Methode. Nach einer grundlegenden Überarbeitung von 2006 bis 2009 liegt es derzeit als PRINCE2:2009 vor.

Das Spezielle im Hinblick auf den Umgang mit Unberechenbarkeiten und Komplexität

PRINCE2 – als universelle PM-Methode – erlaubt sowohl ein betont inkrementell-adaptives als auch ein stark plangetriebenes Vorgehen. Das spezifische Vorgehen wird im projektspezifischen Tailoring festgelegt. Es findet Ausdruck insbesondere in der Art der Gestaltung der Durchführungsphasen.

Betont inkrementell-adaptives Vorgehen
Bei einem betont inkrementell-adaptiven Vorgehen werden die Durchführungsphasen dazu dienen, konkrete und vom Benutzer testbare oder gar produktiv nutzbare Produkte zu liefern, etwa:

1.	Spielfeld mit Containern als Umkleidekabinen
2.	Zuschauertribüne ohne Dach
3.	Tribünenüberdachung und Umkleideräume mit Duschen
4.	Flutlichtanlage
5.	Kiosk und Bar

Stark plangetriebenes Vorgehen
Bei einem stark plangetriebenen Vorgehen mit nur einer Produktionsübergabe als Abschluss wird es Durchführungsphasen mit dieser Art von Produkten geben, da PRINCE2 auch ein Konzept als Produkt sieht:

1.	Konzeption der gesamten Sportanlage
2.	Detaildesign der gesamten Sportanlage
3.	Bau der gesamten Sportanlage
4.	Abnahme der gesamten Sportanlage
5.	Einweisung der Betreiber der gesamten Sportanlage
6.	Freigabe der gesamten Sportanlage zur Nutzung

Vertrauen und Ausnahmeprinzip
In beiden Fällen beruht PRINCE2 zur Reduktion der Komplexität auf dem Vertrauen in das autonome und sich selbst steuernde Agieren der Rollenträger innerhalb des definierten Rahmens und der übergeordneten Steuerung nach dem Ausnahmeprinzip nur beim Überschreiten dieses Rahmens.

Konsequenzen beim Praktizieren innerhalb üblicher Organisationen

Hang zur Bürokratisierung
Die deutsche Beschreibung von PRINCE2 umfasst 377 Seiten [29]. Das verleitet übliche Organisationen mit ihrer traditionellen Regelungs- und Absicherungstradition dazu, beim Tailoring eher zu viel des Maximalumfangs stehen zu lassen, als radikal das nur unbedingt Nötige zu nutzen. Gegen diesen Hang zur Bürokratisierung anzukämpfen ist nicht einfach.

Zusätzlich muss vermieden werden, dass – weiterhin – möglichst früh allzu umfassende und detaillierte Konzeptionen (BDUF) verlangt werden, um zuverlässige Schätzungen und Planungen zu erhalten. PRINCE2 zwingt nicht dazu (es will ja im Gegenteil eher den JEDUF fördern), es kann jedoch auch dazu weiterhin so genutzt werden.

Kulturwandel nötig
Für Organisationen mit einem ausgeprägten Bedürfnis nach granularer Kontrolle bedeuten das Steuern nach dem Ausnahmeprinzip und das autonome Agieren der Rollenträger einen erheblichen Kulturwandel.

3.2.2 Dynamic Systems Development Method (DSDM/DSDM Atern)

Charakteristik und Herkunft [31]
31
Caine, Matthew: DSDM Atern im Überblick. Online in: www.netzwoche.ch/de-CH/News/2011/10/19/DSDM-Atern-im-Ueberblick.aspx
[32]
32
Kompakte Darstellung von DSDM Atern in Deutsch: www.dsdm.org/shop/books/dsdm-atern-pocketbook
[33]
33
Umfangreichere Darstellung von DSDM in Englisch: www.dsdm.org/shop/books/the-dsdm-atern-handbook

DSDM beschreibt auch die Teamarbeit
DSDM ist einerseits ein für sich allein stehendes agiles Framework zur projektmäßigen Entwicklung dynamischer, also nicht genau vorausplanbarer Systeme einschließlich eines Rahmens für das Projektmanagement. Andererseits fokussiert DSDM (wie Scrum) insbesondere auch auf die teambasierte Entwicklungsarbeit.

Dieser Teil des DSDM kann auch im Rahmen anderer übergeordneter Projektmanagementmethoden wie PRINCE2 [34] eingesetzt werden. DSDM ist mit seinen Phasen, Prozessen und Outputs aus traditioneller Sicht gut verständlich, andererseits ist es durch essenzielle agile Elemente gekennzeichnet:

Kombinierte Phasen für inkrementell-adaptives Vorgehen
Es ermöglicht, bei entsprechender Verschmelzung seiner eher sequenziellen Phasen, ein iterativ-adaptives und inkrementelles Entwicklungsvorgehen. Es fordert den fortlaufenden Einbezug der Nutzer und Kunden in den Entwicklungsprozess. Es unterstützt die Ausrichtung auf klar definierte strategische Ziele und auf die frühe Lieferung echter Geschäftsvorteile. Deren Realisierungsreihenfolge folgt einer Prioritized Requirement List (PRL), basierend auf den MoSCoW-Regeln (Must Have/Should Have/Could Have/Won't Have this Time). Ergebnis der frühen Phasen ist ein JEDUF. Weitere Details werden nur für den jeweils nächsten iterativen Realisierungsschritt für das wirklich Erforderliche (und Machbare) konzipiert und geplant. DSDM sieht eine frühzeitige Risikoanalyse (in den Phasen Machbarkeitsprüfung und Rahmenplanung/Grundlagen) vor.

DSDM wurde 1997 erstmals publiziert, damals jedoch beschränkt auf eine reine Software-Entwicklungsmethode mit dem Ziel, im Rapid Application Development (RAD) etwas mehr Disziplin zu schaffen.

„Agil” und stark teamorientiert seit 2007 als DSDM Atern
Im Jahr 2007 wandelte es sich unter dem Namen DSDM Atern zu einer generischen teamorientierten Vorgehensweise des Projektmanagements und zur agilen Entwicklung von Lösungen. Atern ist die Abkürzung von Arctic Tern, der Küstenseeschwalbe, einer Vogelart, die im Schwarm extrem lange Strecken dank einem hohen Maß an Kollaboration zurücklegen kann.

Auch das dem DSDM Atern vorangehende und immer noch weit verbreitete DSDM 4.2 (aus dem Jahr 2003) integrierte bereits eXtreme Programming für die agile Softwareentwicklung.

DSDM Consortium
DSDM wurde entwickelt und wird weiterentwickelt vom 1994 gegründeten DSDM Consortium. Es versteht sich als eine herstellerunabhängige Non-Profit-Organisation. Das DSDM Consortium wird finanziert durch jährliche Mitgliederbeiträge (dreistellige Eurobeträge) der das DSDM nutzenden Firmen. DSDM ist das einzige als ISO9001-verträglich akkreditierte agile Verfahren. Alle zur Nutzung von DSDM und DSDM Atern erforderlichen Beschreibungen und Vorlagen sind online entweder frei und kostenlos verfügbar oder zum Preis üblicher Fachbücher zu erwerben.

DSDM ist bis jetzt außerhalb Großbritanniens kaum bekannt, wird dort aber insbesondere auch für große Projekte – auch im Bereich der öffentlichen Verwaltung – als einer der Standards (neben oder auch in Verbindung mit PRINCE2) genutzt (siehe dazu Fallbeispiele in [6]).

Das Spezielle im Hinblick auf den Umgang mit Unberechenbarkeiten und Komplexität

Charakteristische Eigenschaften
•	Das inhaltliche Projektergebnis wird anpassbar gehalten, Kosten, Termine und Qualitätsanforderungen sind fixiert.
•	Einzelne Phasen oder Phasengruppen können iterativ durchlaufen werden.
•	Die Lösung kann schrittweise in einzelnen Inkrementen ausgeliefert werden.
•	MoSCoW-Priorisierung (Must Have/Should Have/Could Have/Won't Have this Time) der Teilresultate: Pro Timebox werden etwa 60 % Must Have, 20 % Should Have, 20 % Could Have geplant.
•	Förderung von Modellen und Prototypen.
•	Kein BDUF, aber ein bewusstes JEDUF – mit allen Stakeholdern vereinbart – als Mittel gegen schleichende Funktionserweiterungen.
•	Frühzeitige Risikoanalyse (in den Phasen Machbarkeitsprüfung und Rahmenplanung/Grundlagen).

Konsequenzen beim Praktizieren innerhalb üblicher Organisationen

Passt zu vertrauten PM-Rollen
DSDM Atern definiert wie auch PRINCE2 – im Unterschied zu Scrum – keine ungewöhnlichen und neuen Rollen und Verantwortlichkeiten, sondern solche, die auf die im Unternehmen bereits bestehenden Rollen und Positionen übertragbar sind.

Wie alle agilen Vorgehensweisen bleibt auch bei DSDM Atern der Projektscope flexibel, nur Kosten, Termin und Qualitätsanforderungen werden fixiert. Das und das Prinzip JEDUF statt BDUF erfordern ein grundlegendes Umdenken und führen zu weitreichenden Konsequenzen für das Projektcontrolling, Vertragswesen und die langfristigen Portfolio-Roadmaps. All das erfordert eine stark vertrauens- statt nur vertragsbasierte Zusammenarbeit mit den Kunden und Lösungsnutzern.

Das modellierungs- und prototyporientierte Arbeiten ist nur möglich mit einem intensiven Einbezug der späteren Lösungsnutzer. Das hat oft erhebliche Konsequenzen für deren Termin- und Ressourcenplanung und die geografische Verfügbarkeit in Konkurrenz zur üblichen Arbeit.

Das Projektteam muss ermächtigt sein, auch wichtige Entscheidungen zu treffen oder rasch zur Diskussion zu stellen, ohne umfangreiche formale Anträge an das höhere Management schreiben zu müssen.

3.3 Konzepte und Praktiken der agilen Neu- und Weiterentwicklung und Wartung von Produkten

Wie weiter oben bereits erläutert, passt die Flexibilität bezüglich des Ziels (oder Funktionsumfangs) und allenfalls auch der investierten Anzahl von Produktinkrementen besser zu einer den gesamten Produktlebenszyklus betrachtenden Vorgehensweise als zu einem bezüglich Zeit, Kosten und Inhalt begrenzten Projekt. So etwa ist im Scrum Guide [35] zu lesen: „Solange ein Produkt existiert, existiert auch ein Product Backlog.”. Das Wort Projekt kommt im Scrum Guide nur an einer einzigen Stelle vor: „Jeder Sprint kann als Projekt verstanden werden, für das ein zeitlicher Rahmen von maximal einem Monat zur Verfügung steht.”

Inkrementell-adaptives Vorgehen fokussiert auf Produktlebenszyklus
Deshalb ist Scrum keine Projektmanagement-Methode (auch wenn sie oft so bezeichnet wird), sondern beschreibt die Regeln einer inkrementell-adaptiven Produktentwicklung, beginnend mit der Realisierung des ersten Produktinkrements über alle weiteren Inkremente der Weiterentwicklung des Produkts hinweg bis zu seinem Lebensende.

Auf den gesamten Lebenszyklus von Produkten, nicht nur auf die Phasen seiner projektmäßigen Bearbeitung (Erstentwicklung und umfassende Überarbeitungen) beziehen sich auch das Scaled Agile Framework (SAFe) und Kanban. Wobei Kanban nicht nur das Entwicklungsvorgehen beschreibt, sondern für alle Arten sequenziell aufeinander folgender Arbeitsschritte nutzbar ist.

3.3.1 Scrum

Charakteristik und Herkunft

Beschreibt kein Projektvorgehen
Scrum (s. a. [36] [35]) beschreibt kein Projektvorgehen von der Projektinitialisierung bis zum Projektabschluss, sondern ist ein Framework zum Vorgehen bei der Neu- und Weiterentwicklung (Detailanalyse, Design, Implementation) komplexer, im Voraus also nicht genau definierbarer und planbarer Produkte auf der Basis empirischer Prozesssteuerung. Das illustriert z. B. auch Ken Schwaber in einem Fallbeispiel, bei dem eine existierende Großrechneranwendung auf eine Webanwendung umgestellt werden sollte. Die Fallbeschreibung beginnt dort, wo das Projekt bereits bewilligt, seine Finanzierung gesichert und der Projektplan und das Entwicklerteam schon vorhanden waren [37].

Liefert Produktinkremente in Sprints von max. vier Wochen
Scrum beschreibt, unabhängig von der Art des Produkts, wie das Scrum-Team innerhalb einer immer gleich langen Timebox (genannt Sprint) von zwei bis maximal vier Wochen ein fertiges, nutzbares und potenziell auslieferbares Produktinkrement herstellen kann. Das Scrum-Team besteht aus dem Product Owner, den Entwicklern (als Entwicklerteam) und dem Scrum Master (der dem Team dienenden Führungskraft).

Product Backlog
Zu Beginn jedes Sprints wird im Scrum-Team vereinbart, was für das nächste Produktinkrement zu leisten ist. Basis dafür ist eine fortlaufend aktualisierte und nach Erledigungsreihenfolge geordneten Liste (genannt Product Backlog) von all dem, was im Produkt künftig benötigt werden könnte. Am Ende des Sprints werden – unter Einbezug relevanter teamexterner Stakeholder – das effektiv Geleistete (Sprint-Review) und die Arbeitsweise während des Sprints (Sprint-Retrospektive) überprüft.

Fortlaufende Verbesserung
Diese Überprüfung dient der fortlaufenden Verbesserung sowohl des Produkts (Review) als auch des Prozesses der Produktentwicklung (Retrospektive).

Abb. 2: Scrum: Inkrementell-adaptives Vorgehen in Sprints

Was Scrum nicht macht
Das – und nicht mehr oder weniger – beschreiben die Regeln von Scrum. Sie beschreiben z. B. nicht, wie die Elemente des Product Backlogs vor dem ersten Sprint ermittelt, beschrieben, bezüglich Machbarkeit und Risiko beurteilt und mit den Backlogs anderer Produkte koordiniert werden und wie die fortlaufende Aktualisierung und Abstimmung mit anderen Teams und Produkten erfolgt. Scrum gibt auch keine Hinweise, wie eine Handvoll bis mehrere Dutzend Teams gleichzeitig an verschiedenen Produkten und Projekten arbeiten können. Scrum beschreibt auch kein spezielles Vorgehen, wie während eines Sprints ungeplante und sehr dringende Fehler bereits produktiver Produktinkremente behoben werden können.

All das und die je nach Produktart ganz unterschiedlichen Methoden und Techniken der Analyse, des Designs, der Modellierung, der Konstruktion/Realisierung, der Tests und der Qualitätssicherungsmaßnahmen und der Inbetriebnahme und fortlaufenden Produktbetreuung müssen ergänzend erarbeitet und vereinbart werden.

Scrum ist keine Entwicklungsmethode
Scrum will alle diese spezifischen Aspekte auch nicht regeln, sondern ist „weder ein Prozess noch eine Technik zur Erstellung von Produkten; es ist vielmehr als Framework zu verstehen, innerhalb dessen verschiedene Prozesse und Techniken zum Einsatz gebracht werden können.” [25].

Das ist einer der Hintergründe auch für diese Aussage im Scrum Guide: „Scrum ist

•	leichtgewichtig,
•	einfach zu verstehen,
•	extrem schwer zu meistern.”

Vorgehens-Framework für Teamarbeit
So gesehen ist Scrum als solches ein allgemeines Vorgehens-Framework für jene Art der Teamarbeit, bei der

•	in kurzen Abständen (d. h. pro Sprint von max. vier Wochen) nutzbare und aufeinander aufbauende Teile irgendeines Produkts von einem Entwicklerteam für teamexterne Nutzer hergestellt werden können;
•	mindestens drei bis maximal neun Entwickler zu 100 % nur in diesem einen Team sehr eng und sich selbst organisierend zusammenarbeiten;
•	die Erfahrungen mit den bereits realisierten Produktinkrementen in die Realisierung der künftigen so rasch wie möglich einfließen und sich das Produkt somit fortlaufend verändern kann und die Arbeitsprozesse des Teams sich fortlaufend optimieren lassen;
•	als Basis der Teamarbeit eine von einem und nur einem unternehmensweit anerkannten Product Owner fortlaufend aktualisierte Liste (Product Backlog) mit all dem existiert, was im Produkt künftig benötigt werden könnte.

Scrum passt nicht immer
Für derartige Produkte (oder Arbeiten i. a.) passt die Teamarbeit gemäß Scrum daher nicht:

•	Es sind keine vernünftigen pro Sprint (alle zwei bis vier Wochen) verfügbaren und zumindest potenziell von teamexternen Stakeholdern nutzbaren Teilergebnisse (Produktinkremente) denkbar.
•	Es gibt keine pro Sprintergebnis alle zwei bis vier Wochen überprüfungs- und nutzungsbereiten repräsentativen Stakeholder.
•	Das Produkt ist von Anfang an im Detail definiert. Veränderungen sind nur ausnahmsweise und auf der Basis schwergewichtiger Change-Request-Verfahren möglich.
•	Ein alles umfassendes Product Backlog, das gegenüber dem Team von einem und nur einem Product Owner verantwortet wird, ist nicht denkbar.
•	Die Entwickler arbeiten gleichzeitig und zusammen mit immer wieder anderen Entwicklern an diversen Produkten.

Jeff Sutherland schuf das Scrum-Vorgehen 1993. Mit dem Wort Scrum bezog er sich auf eine 1986 im Harvard Business Review publizierte Studie von Takeuchi und Nonaka [38], in der high-performing, cross-functional teams mit der Scrum-Formation im Rugby verglichen wurden. Ken Schwaber zusammen mit Jeff Sutherland formalisierte den Prozess für die Software-Industrie in einem Artikel für die OOPSLA 1995. Jeff Sutherland und Ken Schwaber beschreiben im Scrum Guide [35] als gültigem Leitfaden für Scrum die verbindlichen Spielregeln, die unantastbar sind: „Obwohl es möglich ist, nur Teile von Scrum zu implementieren, ist das Ergebnis nicht Scrum. Scrum existiert nur in seiner Gesamtheit”. Diese Forderung des konsequenten Einhaltens der Scrum-Regeln vergleichen Jeff Sutherland und Ken Schwaber mit den Regeln des Schach, die ebenfalls kompromisslos einzuhalten sind, wenn das Spiel Schach genannt wird [39].

Scrum-Prinzipien
Ken Schwaber ist jedoch kein Scrum-Dogmatiker, sondern schreibt ausdrücklich [40], dass Scrum durch irgend etwas anderes ersetzt werden könne, das auf diesen Prinzipen beruhe:

•	Selbstorganisation
•	Bottom-up-Intelligenz
•	Empirismus
•	Transparenz

Scrum kann ohne Lizenzen von allen Personen (auch ohne Zertifizierung) und Firmen auf der Basis des frei verfügbaren Scrum Guide und einer fast unüberblickbaren Literatur zu Scrum eingesetzt und geschult werden.

Sowohl die Scrum Alliance als auch Ken Schwabers scrum.org und deren Scrum-Trainer und Scrum-Coaches bieten weltweit kommerzielle Trainings und diverse Zertifizierungen (Scrum Alliance) bzw. Assessments (scrum.org) für verschiedene Scrum-Rollen und Niveaus an.

Im Januar 2013 hat die Scrum Alliance eine weitere Beschreibung von Scrum als Core Scrum publiziert, das sich vom Scrum Guide der scrum.org in einigen Punkten deutlich unterscheidet [41].

Missverständnisse und Zuschreibungen

Scrum ist als Vorgehens-Framework der Teamarbeit im Rahmen der Produktentwicklung überall dort sehr erfolgreich, wo die vorhin genannten Voraussetzungen gegeben sind. Das zeigt die nahezu unüberblickbare Menge publizierter Beispiele. Andererseits bringt auch die Nutzung nur einiger weniger agiler Elemente, die mit Scrum assoziiert werden, wie das Daily Standup Meeting oder ein kurzer sprintartiger Arbeitszyklus auch ohne potenziell nutzbare Produktinkremente, aber mit sichtbaren Zwischenresultaten, schon große Vorteile. Das allein wird – leider – sehr oft schon als Scrum-Vorgehen bezeichnet.

Nur Scrum, wenn Scrum Guide erfüllt
Die sich daraus ergebende Popularität von Scrum ist jedoch, bezogen auf Scrum als solches (also gemäß Scrum Guide), verbunden mit etlichen Missverständnissen. Hier ein paar essenzielle Klarstellungen:

•

Scrum ist keine schlanke Entwicklungsmethode. Es ist ein allgemeines Vorgehens-Framework und ein leerer Container verfügbar für etablierte spezifische Methoden der professionellen Produktentwicklung (die ganze Bibliotheken füllen), die es zusätzlich zu beachten gilt.

•

Scrum führt nicht zu einer massiven Erhöhung der Effizienz: Es unterstützt die Adaptivität, Qualität und Effektivität. Insgesamt (bezogen auf ein gesamtes fertiges Produkt) wird es mit Scrum nicht eindeutig schneller oder billiger [42].

•

Scrum erfordert die strikte Professionalität erfahrener Entwickler. Welche spezifischen Methoden und Techniken erforderlich sind, beschreibt Scrum als Framework und leerer Container nicht, sondern setzt ihre Beherrschung stillschweigend voraus.

•

Scrum legalisiert kein Arbeiten auf Zuruf, sondern setzt insbesondere auch beim Product Owner ein agiles und professionelles Anforderungsengineering und -management und kontinuierlich adaptierte Design- und Architekturrahmen voraus.

•

Scrum kann nicht für JEDE Art von Vorhaben eingesetzt werden, sondern ist dann geeignet, wenn EIN Produkt von einem oder wenigen ausschließlich dafür arbeitenden interdisziplinären Teams allein (also ohne Abhängigkeit von teamexternen Spezialisten) so neu- oder weiterentwickelt wird, dass lieferbare Teile davon nach jeweils bereits zwei bis vier Wochen vorhanden sind. Und zwar so, dass die raschen Rückmeldungen ihrer Nutzer unmittelbar zur Steuerung der weiteren inhaltlichen Entwicklung dienen. Nicht angemessen ist das z. B. bei

Hier ist Scrum nicht angemessen
–	technologisch sehr heterogenen Produkten mit langwierigen Integrationsprozessen,
–	Vorhaben, deren Anforderungen und Lösungskonzeptionen bereits zu Beginn gut modellierbar und stabil sind,
–	im Voraus genehmigungspflichtigen Produkten ohne fortlaufende Adaptionsmöglichkeit,
–	physischen Produkten, die nur als Ganzes funktionieren,
–	Änderungen des schon Gelieferten, die lange dauern und sehr teuer sind,
–	Organisationsentwicklungen u. ä. Vorhaben ohne Produktcharakter.

Selbstorganisation braucht Führung

•

Selbstorganisation braucht Führung: Das Team als Ganzes ist selbstverantwortlich – jedoch innerhalb klar vorgegebener Spielregeln und Rahmenbedingungen. Das, WAS zu erledigen ist, legt der Product Owner fest, für den Rahmen des effizienten und qualitätsbewussten WIE ist der Servant Leader des Teams (= der Scrum Master) verantwortlich. Es hat sich jedoch die Ansicht verbreitet, dass der Scrum Master nur als Coach ohne Führungskompetenz agiert. Das aber widerspricht seiner im Scrum Guide klar formulierten Verantwortung. Und es entsteht in Unternehmen eine erhebliche Führungslücke [43]. Die Behauptung, dass ein Teamleiter mit Führungsverantwortung die Selbstorganisation des Teams behindert, ist Ausdruck einer spezifischen auf hire and fire geprägten direktiven Führungskultur. Sie steht jedoch im Gegensatz zum heute üblichen sachorientiert-kooperativen Führungsstil.

Das Spezielle in Hinblick auf den Umgang mit Unberechenbarkeiten und Komplexität

Transparenz
Die wesentlichen Aspekte des Prozesses (und nur diese und nicht alle Vorkommnisse z. B. innerhalb des Teams) müssen für diejenigen Personen transparent sein, die für das Prozessergebnis verantwortlich sind. Transparenz setzt einen dafür definierten gemeinsamen Standard voraus. Produkt- und Sprint-Backlogs und der Fortschritt auf dem Weg zur Erreichung des Ziels müssen ständig durch sachkundige Personen am Ort des Geschehens überprüft werden, um unerwünschte Abweichungen rasch zu entdecken. Das geschieht nicht via Statusberichte sondern täglich beim Daily Scrum und bei jedem Sprintende in einem Review. Wird eine Abweichung festgestellt, dann muss so rasch wie möglich – auch innerhalb des Sprints – das Vorgehen oder der Arbeitsgegenstand angepasst werden.

Überprüfung
Überprüft werden nur konkrete, fertige und zumindest potenziell nutzbare Produktinkremente und z. B. keine bloßen Beschreibungen oder konzeptionellen Modelle.

Anpassung
Das initial erstellte Produkt-Backlog kann im weiteren Verlauf jederzeit – aber nur vom Product Owner – verändert werden.

Zur besseren Handhabung der Komplexität ist ein und nur ein Product Owner für das WAS (das Produkt-Backlog), nicht aber für das WIE verantwortlich. Das WIE – und nicht das WAS – verantwortet das Entwicklerteam.

Zur Vereinfachung und Beschleunigung der Kommunikation und der internen Organisation arbeiten die Entwickler zu 100 % nur an dem Produkt des Teams, und zwar als interdisziplinäres und sich selbst steuerndes Team, am besten in einem gemeinsamen Teamraum.

Team wacht über Fortschritt
Der Forschritt wird in erster Linie durch das Scrum-Team als Ganzes selbst überwacht, nicht durch teamexterne Kontrollinstanzen. Die Fortschrittskontrolle erfolgt mit möglichst einfachen, wenn immer möglich visuellen und manuell aktualisierten Mitteln.

Ergebnisse zählen – nicht Stunden
Der Fortschritt wird nicht mittels des Vergleichs geplante Stunden/verbrauchte Stunden, sondern nur mittels des Vergleichs insgesamt nötige Ergebnisse/noch zu realisierende Ergebnisse gemessen. (Analogie: Bei einer Hausmauer ist nicht wichtig, wie viele Stunden bereits daran gebaut wurde, sondern wie viel Prozent der Ziegel noch zu verbauen sind und wie viel Prozent der Bauzeit noch zur Verfügung stehen).

Konsequenzen beim Praktizieren innerhalb üblicher Organisationen

Knackpunkt Product Owner:

Abstimmung mit teamübergreifenden Rollen
In großen Unternehmen führt die gemäß Scrum Guide definierte Rolle des Product Owner als alleiniger und umfassender Repräsentant des WAS zu Überschneidungen und Konflikten mit anderen Rollen. Diese müssen im Rahmen der Abstimmung des agilen Vorgehens mit der teamübergeordneten Produktentwicklung und dem Portfolio-, Programm- und Releasemanagement und der teamübergreifenden Koordination pro Produkt und Release bereinigt werden.

Knackpunkt Entwicklerteam:

Teams optimal strukturieren
Für die teamarbeitsbasierte Produktentwicklung gemäß Scrum ist es in der Regel nötig, die bisherigen Teams neu zu strukturieren:

•	Jedes Team ist interdiziplinär besetzt, verfügt also über permanente, stets im Team voll ausgelastete und daher ungeteilte Mitglieder/Spezialisten, die insgesamt zum Definieren/Realisieren/Testen des vom Team entwickelten Produkts nötig sind.
•	Jedes Teams muss abgeschlossene Produktinkremente und nicht nur Teile davon, die erst zusammen mit Teilen anderer Teams funktionsfähig sind, liefern können.

Knackpunkt Scrum Master als dienende Führungskraft des Teams:

Scrum Master = Führungskraft, nicht nur Coach
Wenn Teams aus Personen verschiedener Einheiten der Linienorganisation zusammengesetzt werden und führungsmäßig weiterhin dort beheimatet bleiben, dann entsteht eine Führungslücke, da deren eigentliche Vorgesetzte von ihrer tagtäglichen Arbeit im Team weit entfernt sind. Zur Beurteilung und Förderung ihrer Mitarbeiter sind die Vorgesetzten dann auf Informationen insbesondere des Scrum Masters angewiesen, der damit de facto – aber nicht explizit deklariert – zum Vorgesetzen wird. Im Interesse der Transparenz sollte der Scrum Master daher auch der Teamleiter sein [43].

Knackpunkt mittel- und längerfristige Planung und vorausgehende Basisarbeiten und Scrum innerhalb von Projekten:

Bei Projekten zusätzlicher agiler PM-Rahmen nötig
Der Planungshorizont von Scrum bezüglich „Was ist wann mit welchen Ressourcen (Personal) vorhanden?” umfasst nur jeweils einen Sprint. Alle darüber hinausgehenden Planungen benötigen zusätzliche Methoden des Release- und Portfoliomanagements außerhalb von Scrum. Auch das Schaffen aller Voraussetzungen, damit die eigentliche Produktentwicklung gemäß Scrum auf der Basis eines Product Backlog beginnen kann, erfordert zusätzliche Maßnahmen außerhalb von Scrum. Wenn Scrum zur Neuentwicklung oder umfassenden Überarbeitung eines Produkts im Rahmen eines Projekts genutzt wird, dann ist zusätzlich zu den Scrum-Regeln ein Projektmanagement-Rahmen erforderlich. Dieser Rahmen muss jedoch das inkrementell-adaptive Vorgehen unterstützen. Rahmen, die sequenzielle Phasen fordern (Analyse/Design mit einem BDUF als Ergebnis → Realisierung/Implementierung auf der Basis dieses BDUF → Einführung als big bang), sind mit Scrum unvereinbar. Vereinbar hingegen ist z. B. PRINCE2.

Knackpunkt Controlling:

Umdenken im Controlling
Die teambasierte Fortschrittskontrolle mit möglichst einfachen, visuellen und manuell aktualisierten Mitteln erschwert eine teamübergreifende und automatisierte Gesamtübersicht. An ihre Stelle tritt die fortlaufende Kommunikation mit den Product Ownern.

Die Fortschrittskontrolle anhand des Erledigungsstands der konkreten Arbeitsergebnisse anstatt auf der Basis von Personentagen erfordert ein Umdenken und Neugestalten vieler etablierter Instrumente.

3.3.2 KANBAN/Kanban

Charakteristik und Herkunft

KANBAN – Prozessverbesserung
KANBAN (in Großbuchstaben), siehe [44], ist eine 2007 veröffentlichte Methode zur evolutionären Verbesserung des Prozesses der Softwareentwicklung auf den Grundlagen des Lean Management mit dem Ziel, den Arbeitsfluss sichtbar zu machen und zu beschleunigen.

Kanban – Selbststeuerungssystem
Kanban (in Kleinbuchstaben) ist ein für die Softwareentwicklung stark abgewandeltes dezentrales Selbststeuerungssystem auf der Grundlage der bei der Toyota Motor Corporation entwickelten Methode der Produktionsablaufsteuerung auf der Basis des Pull-Prinzips. Unter Pull-Prinzip wird in diesem Kontext verstanden, dass bei einer Abfolge von Bearbeitungsschritten jeder Schritt die nächste Aufgabe vom vorgelagerten Schritt sich dann selbst holt, wenn bei ihm Kapazität dafür vorhanden ist und sein Arbeitsergebnis vom nachfolgende Bearbeitungsschritt benötigt wird. Das steht im Gegensatz zu push, bei dem ein Schritt seine Ergebnisse zur weiteren Bearbeitung an den nächsten Schritt ungefragt weiterleitet oder eine zentrale Steuerungsinstanz die Arbeiten verteilt.

Ursprung in Logistik und Produktion
Im Ursprung ist Kanban ein in der Logistik und Produktion etabliertes und 1947 von Taiichi Ohno in der japanischen Toyota Motor Corporation entwickeltes dezentrales Produktionssteuerungssystem. David J. Anderson suchte Ende des letzten Jahrtausends als Manager der SW-Entwicklung in verschiedenen Firmen Wege, um die etablierten, aber suboptimalen Vorgehensweisen in Entwicklungsteams zu verbessern. Dabei erkannte er, dass jede Teamsituation spezifisch ist und es keine generell passenden Prozesse gibt. Bei seiner Arbeit am Buch Agile Management for Software Engineering [45] suchte er einen neuen Lösungsansatz für seine Anliegen auf der Basis der Engpasstheorie [46]. Seine Lösungsidee war, einen Prozess zu beschreiben, mit dem jedes Team selbst den seinen kontinuierlichen Arbeitsfluss begrenzenden Engpass finden und erweitern kann. Daraus entwickelte Anderson einen einfachen, auf dem Pull-Prinzip basierenden Drum-Buffer-Rope-Ansatz für die Softwareentwicklung. Diesen Ansatz konnte er 2004 bei Microsoft erfolgreich und ohne große Widerstände umsetzen und berichtete 2005 und 2006 auf Konferenzen darüber. Donald G. Reinertsen [47] machte Anderson darauf aufmerksam, dass er all das als komplettes Kanban-System gestalten könne. 2006, als Entwicklungsleiter bei Corbis, führte er dort mit Erfolg Kanban in der SW-Entwicklung ein und schuf etliche Erweiterungen dafür. 2010 erschien sein auch heute noch grundlegendes Buch Kanban: Successful Evolutionary Change for Your Technology Business [44], in dem er einerseits das von ihm entwickelte Kanban (in Kleinbuchstaben) zur operativen dezentralen (Selbst-)Steuerung der SW-Entwicklungsarbeit beschreibt und andererseits das KANBAN (in Großbuchstaben), das der evolutionären Prozessverbesserung der SW-Entwicklung dient.

Das Spezielle im Hinblick auf den Umgang mit Unberechenbarkeiten und Komplexität

Kanban: extrem flexibel und rasch anpassbar
Kanban (in Kleinbuchstaben) zur operativen dezentralen (Selbst-)Steuerung der Arbeit ist extrem flexibel und rasch an spezielle, auch nicht vorausgesehene Situationen anpassbar. Die Arbeitsschritte – die Spalten der Kanban-Tafel, siehe Abb. 3 – und deren Work-In-Progress-Limits (WIP-Limits) können im Sinn der empirischen Prozesskontrolle rasch und auch experimentell verändert werden. Die WIP-Limits sind die Ziffern oben pro Spalte bzw. Doppelspalte als Maximalzahl der pro Spalte/Doppelspalte erlaubten Arbeiten, dargestellt als graue „Zettel”.

Abb. 3: Beispiel einer einfachen Kanban-Tafel

Die Häufigkeit der Nachschubmeetings zum Auffüllen der Spalte „zu tun” (ganz links auf der Tafel) ist beliebig festlegbar. Es kann auch mehrmals pro Tag stattfinden. Prioritäten können daher sehr kurzfristig geändert werden.

Abbildung 3 zeigt ein recht einfaches Beispiel. Zusätzlich kann die Menge an Arbeit z. B. pro Kundenart oder Produktfamilie in speziellen Swimlanes dargestellt und mit zusätzlichen WIP-Limits pro Swimlane gesteuert werden. Auch unplanbare Notsituationen können im Prozess geordnet berücksichtigt werden. Die Kanban-Tafel zeigt jederzeit den aktuellen Arbeitsstand, Unterlast und Engstellen im Arbeitsfluss und erlaubt sofortige Interventionen.

KANBAN: Arbeitsweisen sehen und optimieren
KANBAN (in Großbuchstaben) zur evolutionären Prozessverbesserung der Arbeit macht die aktuell praktizierten Arbeitsweisen sicht- und messbar (quantifiziert und statistisch auswertbar) und schafft damit objektive Voraussetzungen für schrittweise, auch experimentelle Verbesserungen.

Konsequenzen beim Praktizieren innerhalb üblicher Organisationen und Skalierbarkeit/Übertragbarkeit auf ganze Organisationen

Positive Erfahrungen bilden Vertrauen
Kanban (in Kleinbuchstaben) zur operativen dezentralen Steuerung auf der Basis des Pull-Prinzips kann in Organisationen mit einem ausgeprägten Top-down-Steuerungs- und Kontrollbedürfnis auf Detailebene zum Gefühl des Kontrollverlusts führen und zu Unsicherheiten bezüglich der längerfristigen Planbarkeit und Zuverlässigkeit der Fertigstellungstermine der Arbeitspakete. Erst eine Reihe positiver Erfahrungen mit trotz Pull-Prinzips termingerechten Lieferungen vermag diese Skepsis ab- und Vertrauen aufzubauen. Für Manager können die unzähligen und bereits jahrzehntelangen positiven Erfahrungen mit solchen Systemen in der Produktion und Logistik vertrauensbildend sein.

Es kann zur operativen dezentralen Steuerung auf der Basis des Pull-Prinzips unter Beachtung von WIP-Limiten für alle Arten von – in Schritten zerlegbaren – Arbeitsflüssen auf allen Stufen einer Organisation und in allen Bereichen praktiziert werden.

Geschwindigkeit der Veränderung steuerbar
KANBAN (in Großbuchstaben) zur evolutionären Prozessverbesserung geht vom Existierenden und Etablierten aus ohne Anspruch, es sofort verändern zu wollen, und erlaubt evolutionäre Veränderungen in jener Art und Geschwindigkeit, wie sie der Organisation angemessen sind. Das reduziert den Widerstand gegen Veränderungen erheblich.

Andererseits macht es das Existierende und Etablierte sehr transparent – und auch messbar. Bisher unentdeckte (und evtl. bewusst verschleierte) Schwachstellen und Zeitverschwendungen werden damit sichtbar. Das kann zu erheblichen Irritationen führen.

Es kann ebenfalls für alle Arten von – in Schritten zerlegbaren – Arbeitsflüssen auf allen Stufen einer Organisation und in allen Bereichen praktiziert werden.

Weder Kanban noch KANBAN setzt ein inkrementell-adaptives Vorgehen voraus.

3.3.3 Scaled Agile Framework for Enterprises (SAFe)

Charakteristik und Herkunft [48] [49] [50]

Skalierung auf Multi-Team-/Multi-Produkt-Situationen
Die Grundprinzipien agiler Vorgehensweisen beziehen sich in der Regel entweder auf nur EIN Projekt oder – wie bei Scrum – auf EIN Team, das EIN Produkt entwickelt. Und es wird stillschweigend eine relativ homogene technologische Systemlandschaft angenommen, in der einzelne Produktinkremente innerhalb einer Iteration mit einer Dauer von zwei bis vier Wochen auch in das Gesamtsystem integrierbar sind und danach in Produktion gehen und – zumindest potenziell – genutzt werden können. Die Skalierbarkeit von agilen Vorgehensweisen auf Multi-Team- bzw. Multi-Produkt-Situationen bezogen auf den gesamten Lebenszyklus der Produkte in großen Unternehmen mit einer hohen technologischen Vielfalt wird bei diesen Vorgehensweisen kaum thematisiert.

Das agile Portfolio- und Programmmanagement in großen Unternehmen, die Koordination Dutzender von Teams und technologische Aspekte wie die team- und systemübergreifende Continuous Integration bleiben offen und führen dann zu erheblichen Problemen.

Vor diesem Hintergrund hat Dean Leffingwell – ein in seiner Rolle als Top-Manager großer IT-Firmen davon selbst Betroffener – nach Lösungen gesucht und sie in seinen Büchern beschrieben [50] [51].

Das Ergebnis nennt er Scaled Agile Framework for Enterprises (SAFe). Das SAFe hat sich auf der Basis von Einsätzen in Programmen mit nur 50–100 Beteiligten, aber auch in großen Unternehmen mit mehreren tausend Softwareentwicklern entwickelt. Seine jeweils aktuellste Version ist als umfassende Dokumentation in [49] frei verfügbar.

Ebenen: Teams – Programm – Portfolio
SAFe offeriert umfassende Beschreibungen der individuellen Rollen, Teams, Tätigkeiten und Artefakte zum agilen Arbeiten auf den Ebenen

•	Teams (dort wird als Vorgehen Scrum in Verbindung mit XP empfohlen),
•	Programm/Agile Release Trains (diese liefern alle etwa zehn Wochen = fünf Scrum-Sprints in die gesamte IT-Systemlandschaft integrierte Potential Shipable Increments, die aus Beiträgen mehrerer Teams und IT-Plattformen bestehen),
•	Portfolio (dort wird ein an Kanban angelehntes Vorgehen empfohlen).

Zentrale Aspekte
Zentrale Aspekte, gemäß Leffingwell, sind:

•	Skalierung der zu schaffenden Werte: Nicht alles ist eine User-Story.
•	Skalierung von Team und Timebox: Kein Team ist eine Insel.
•	Skalierung des Design: Emergentes Design verbindet sich mit bewusst vorausgedachter Architektur.
•	Skalierung des Portfoliomanagements: Das althergebrachte Denken hinterfragen und ändern.
•	Skalierung der Führerschaft: Das Unternehmen kann nur so „lean" wie das Denken der Geschäftsführung sein.

Herzschlag = teamübergreifende (interne) Releases
Das SAFe versteht sich im Gegensatz zu einem Projektmanagement-Framework als agiles Framework zur kontinuierlichen Lieferung produktiv nutzbarer Lösungen in (internen) Releases im Rahmen der Neu- und Weiterentwicklung und der Wartung von Produkten längs ihrer gesamten Lebenszeit.

SAFe nennt daher bewusst keinerlei auf Projekte bezogene Rollen oder Artefakte. Aus den Beschreibungen des SAFe kann jedoch indirekt abgeleitet werden, dass Projekte als – auch quer über diverse Teams und Agile Release Trains liegende – Strukturen auf der Programm-Ebene gesehen werden können. Die Teams arbeiten an Produkten, nicht an jeweils einem (evtl. mehrere Produkte umfassenden) Projekt. Die Projektleiter sind dann am besten auf der Programmebene im Product Management angesiedelt.

SAFe bietet ein Angebot an guten Praktiken, die, obwohl aufeinander abgestimmt, auch nur teilweise genutzt werden können. SAFe verlangt nicht, alle seine Praktiken vollumfänglich zu verwenden.

Das Spezielle im Hinblick auf den Umgang mit Unberechenbarkeiten und Komplexität

Teamebene = Scrum & XP
SAFe nutzt auf Teamebene alle iterativen, inkrementellen und adaptiven Elemente insbesondere von Scrum und XP, so auch kurze Iterationen, umrahmt sie aber mit langsamer getakteten (internen) Releases als Lieferzeitpunkten für die eigentlichen Potential Shipable Increments.

Das erleichtert umfangreiche Integrationsarbeiten einerseits und trägt der in der Regel auf Nutzerseite begrenzten Fähigkeit (und Bereitschaft) zur Entgegennahme neuer Produktinkremente in sehr kurzen Abständen Rechnung.

Programmebene = Agile Release Trains
Auf Programm- und Portfolioebene wird ein rollender JEDUF praktiziert.

Im Rahmen der einzelnen Agile Release Trains wird der Umfang nur des jeweils nächsten internen Release verbindlich festgelegt. Für die späteren Releases enthält die Roadmap nur grobe und unverbindliche Prognosen.

Portfolioebene = Kanban
Auf Portfolioebene gibt es statt der festen Jahresplanung eine rollende Aktualisierung. Die mit Kanban erreichte Mengenbegrenzung der auf Portfolioebene gleichzeitig bearbeiteten Epics erhöht die Flexibilität.

Konsequenzen beim Praktizieren innerhalb üblicher Organisationen

SAFe orientiert sich an den üblichen Planungs-, Steuerungs- und Aktionsebenen größerer Unternehmen und schafft dort eine deutlich verbesserte Transparenz und Rückverfolgbarkeit. Allerdings wird die Mikropolitik damit erschwert bzw. offensichtlicher.

Schwierig sind sicher der Wechsel von den etablierten und starren Jahresplanungen und der Abschied von verbindlichen Mehrjahresprogrammen.

SAFe sieht die Manager aller Ebenen als Botschafter des Lean Management, die die Basis des House of Lean darstellen [52].

3.4 Die insgesamt agile Organisation

Alter Wein in neuen Schläuchen
Seit einigen Jahren werden auch Aspekte der im Abschnitt 2.2 genannten Begrifflichkeiten als Wirkungsprinzipien von Organisationen und Unternehmen insgesamt gefordert. Da jedoch Unternehmen nebst der – allenfalls inkrementell-adaptiv gestaltbaren – Entwicklung und Realisierung von Produkten auch viele Prozesse ohne Produktcharakter (wie etwa das Personalwesen) umfassen, werden unter agil dann nicht primär das inkrementell-adaptive Vorgehen sondern diverse post-tayloristische, hierarchie- und autoritätsfreie und selbststeuernd-kollaborative Prinzipien und Überzeugungen verstanden.

All das sind jedoch in der Organisationsentwicklung schon lange bekannte und diskutierte Ideen. Einige davon wurden – allerdings in vergleichsweise wenigen Fällen – erfolgreich umgesetzt. Vielfach zitierte Beispiele sind u. a. SEMCO [53] [54] und die Morning Star Company Inc. [55]. Weitere Fälle, die man heute als agil bezeichnen könnte, finden sich in [56].

Quellen

www.deloitte.com

de.wikipedia.org/wiki/Return_on_Assets

wirtschaftslexikon.gabler.de/Definition/volatilitaet.html

Olson, Edwin E.; Eoyang, Glenda H.: Facilitating Organization Change: Lessons From Complexity Science. Pfeiffer; 2001

Kurtz, Cynthia; Snowden, David: The New Dynamics of Strategy: Sense-making in a Complex-Complicated World. In: IBM Systems Journal. vol. 42, no. 3.2003, S. 462–483

Wernham, Brian: Agile Project Management for Government, Kindle eBook, 1 Edition, Maitland and Strong, 2012

Martin, James: Information Engineering, Book I/II/III Prentice Hall, Englewood Cliffs/NJ 1990

Dobelli, Rolf: Die Kunst des klugen Handelns. Carl Hanser Verlag, 2012, S. 185

Parsons, Talcott: The social system. University of California Libraries, 1951 und Quid Pro, LLC, 2012

Schuh, Günther (Hg); Wiendahl, Hans-Peter (Hg): Komplexität und Agilität: Steckt die Produktion in der Sackgasse? Springer 1997

agilemanifesto.org und agilemanifesto.org/iso/de/principles.html

Nissen, Volker; Mladin, Alexander: Messung und Management von IT-Agilität. In: Hans-Peter Fröschle (Hg.): Wettbewerbsfaktor IT. HMD 269, 46. Jahrgang, Oktober 2009

Leffingwell, Dean: Thoughts on Lean Thinking. Blog vom 15. 09. 2009 in scalingsoftwareagilityblog.com/thoughts-on-lean-thinking/

Lexikon IT-Management. Symposion Publishing 2010

Coldewey, Jens: Was heißt hier eigentlich „agil”? Kennzeichen agiler Organisationen. In: OBJEKTspektrum Ausgabe 05/2012

Janes, Andrea; Succi, Giancarlo: The Dark Side of Agile Software Development. Free University of Bolzano. Online in darkagilemanifesto.org/dark-side-of-agile-janes-succi-splash-2012.pdf

Alberts, David S.; Hayes, Richard E.; Honekamp, Wilfried (Übersetzer): Power to the Edge. Re Di Roma-Verlag; 2009

Coldewey, Jens: Multi-Kulti: ein Überblick über die agile Entwicklung. In: OBJEKTspektrum Ausgabe 01/2002

SwissQ Agile Trends & Benchmarks 2012, online verfügbar in swissq.it/de/news/requirements-trends-benchmarks-2013/, weitere Studien in www.swissq.it/ressourcen/

Swiss Agile Study 2012, online verfügbar in www.swissagilestudy.ch

Status Quo Agile 2012, online verfügbar in www.hs-koblenz.de/Status-Quo-Agile.4782.0.html

www.extremeprogramming.org/donwells.html und en.wikipedia.org/wiki/Extreme_programming

www.extremeprogramming.org

Beck, Kent: Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999

Komus, Prof. Dr. Ayelt: Ergebnisbericht (Langfassung) Studie: Status Quo Agile. Verbreitung und Nutzen agiler Methoden. Studie des BPM-Labors der Hochschule Koblenz, 2012. Online verfügbar in www.status-quo-agile.de

borisgloger.com

Überblick: de.wikipedia.org/wiki/PRINCE2

Kurzbeschreibung: Hoffmann, Guido; Mitchell Lee, James: Kontrolle ohne Bürokratie: Projektflexibilität durch PRINCE2. In: Führung im IT-Projekt. Hg.: Kammerer, Sebastian; Amberg, Michael; Lang, Michael. Symposion Publishing 2012

Detail: UK Office of Government Commerce: Erfolgreiche Projekte managen mit PRINCE2. The Stationery Office Ltd 2009

www.apmg-international.com/en/qualifications/prince2/prince2.aspx

Caine, Matthew: DSDM Atern im Überblick. Online in: www.netzwoche.ch/de-CH/News/2011/10/19/DSDM-Atern-im-Ueberblick.aspx

Kompakte Darstellung von DSDM Atern in Deutsch: www.dsdm.org/shop/books/dsdm-atern-pocketbook

Umfangreichere Darstellung von DSDM in Englisch: www.dsdm.org/shop/books/the-dsdm-atern-handbook

www.infoq.com/news/XP-DSDM-Prince2

Verbindliche Regeln von Scrum in diversen Sprachen: www.scrum.org/Scrum-Guides

Überblick: www.scrum.org/Resources/What-is-Scrum und www.scrumalliance.org/pages/what_is_scrum

Schwaber, Ken: Agiles Projektmanagement mit Scrum. Microsoft Press Deutschland, 2007. S. 72

Takeuchi, Hirotaka: „The New New Product Development Game"; Harvard Business Review 86116:137–146

www.scrum.org/Portals/0/Documents/Scrum%20Updates/Scrum%20Update%202011.pdf

kenschwaber.wordpress.com/2012/10/05/what-comes-after-scrum/

agileatlas.org/

Harwardt, Mark: Wasserfallmodell versus Scrum – Ist der gute Ruf der agilen Methode gerechtfertigt? Masterarbeit. Fernuniversität Hagen Lehrgebiet Programmiersysteme, 2008

Korn, Hans-Peter: Redesigned Agile in großen Unternehmen. In: Korn, Hans-Peter (Hg); Berchez, Jean Pierre (Hg): Agiles IT-Management in großen Unternehmen. Symposion Publishing, 2013

Anderson, David J.: Kanban: Evolutionäres Change Management für IT-Organisationen. Dpunkt Verlag, 2011

Anderson, David: Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Prentice Hall International, 2003

Goldratt, Eliyahu M.: What Is This Thing Called Theory of Constraints. North River Pr Inc, 1990

Reinertsen, Donald G.: The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009

Leffingwell, Dean: Agil bis zur Unternehmensstrategie – ein „Big Picture”. In: Korn, Hans-Peter (Hg); Berchez, Jean Pierre (Hg.): Agiles IT-Management in großen Unternehmen. Symposion Publishing 2013

Details: scaledagileframework.com

Leffingwell, Dean: Agile Software Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise. Addison-Wesley, 2010

Leffingwell, Dean: Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley Longman, 2007

Leffingwell, Dean: Thoughts on Lean Thinking. Blog vom 15. Sept. 2009 in scalingsoftwareagilityblog.com/thoughts-on-lean-thinking/

Semler, Ricardo: Maverick: The Success Story Behind the World's Most Unusual Workplace. Grand Central Publishing; Reprint edition (April 1, 1995)

geschaeftsmann20.com/2012/07/02/semcosystem/

www.handelszeitung.ch/management/cheflose-unternehmen-ein-hauch-von-anarchie

Radatz, Sonja: Evolutionäres Management: Antworten auf die Management- und Führungsherausforderungen im 21. Jahrhundert. Verlag Systemisches Management, 2003

Weiterlesen und „IT-Servicemanagement digital“ 4 Wochen gratis testen:

IT-Servicemanagement nach ISO 20000, IT Governance und IT Compliance
Zugriff auf über 220 Fachbeiträge und 160 Arbeitshilfen
Onlinezugriff – überall verfügbar

4 Wochen gratis testen

Sie haben schon ein Abonnement oder testen bereits? Hier anmelden