Sie möchten Ihre Software-Entwicklung (SW-Entwicklung) auf ein „agiles” Vorgehen umstellen? Und zwar – so nehme ich an – als eine langfristig wirksame strategische Investition? Dann lade ich Sie zu einer langfristigeren Betrachtung ein. Werfen wir doch zunächst einen Blick auf die historischen Meilensteine der agilen SW-Entwicklung:

Der Begriff Agile Software-Entwicklung entstand erst 2001. Allerdings wies Winston W. Royce bereits 1970 in seinem Artikel „Management of Large Software Systems” darauf hin, dass ein „wasserfallartiges” Vorgehen ungeeignet sei, und empfahl stattdessen ein iteratives Vorgehen mit sehr vielen Rückkopplungsschleifen unter Einbeziehung auch des Benutzers [1].

„Agile” Methoden wie RAD bereits ab 1970
Ab 1970 gab es auch schon Vorgehensmethoden und Praktiken wie Rapid Application Development (RAD) von Dan Gielan (in den 1980er-Jahren bis 1991 formalisiert von James Martin) und Evolutionary Systems Delivery (EVO) von Tom Gilb, heute von ihm „Evolutionary Project Management” genannt.

1980er – 1990er: EVO, Crystal, Spiralmodell
Das Spiralmodell von Barry W. Boehm folgte 1986 und die Crystal-Methodenfamilie von Alistair Cockburn ab 1990.

Scrum seit 1995
Jeff Sutherland, John Scumniotales und Jeff McKenna entwickelten 1993 ein schlankes teambasiertes inkrementell-adaptives Vorgehen bei Easel Corporation, das sie „Scrum” nannten, inspiriert von dem Artikel „The New New Product Development Game” der Autoren Hirotaka Takeuchi und Ikujiro Nonaka. Bei Ken Schwaber's Firma Advanced Development Methods wurde in den frühen 1990er-Jahren ein ähnliches Vorgehen wie Sutherlands Scrum praktiziert und 1995 stellte Ken Schwaber „Scrum” in einem Workshop der OOPSLA '95 mit Jeff Sutherland als einem der Organisatoren vor.

XP seit 1996
1996 verwendeten Kent Beck, Don Wells, Ward Cunningham und Ron Jeffries bei Chrysler erstmals eXtreme Programming (XP). Nach seiner Publikation in 1999 fand es rasante Verbreitung.

Ab Mitte 1990er: PRINCE2, DSDM, FDD, ASD
Danach folgten Schlag auf Schlag: 1996 PRINCE2 (Nachfolger von PRINCE) als allgemeine inkrementell-adaptive Projektmanagement-Methode; 1997 DSDM; ebenfalls 1997 das Feature Driven Development (FDD) von Jeff De Luca und 1999 das Adaptive Software Development (ASD), entwickelt von Jim Highsmith und Sam Bayer, ausgehend von RAD.

2001: Agiles Manifest
Am 12. Februar 2001 trafen sich 17 Vertreter solcher – damals „leichtgewichtig” genannter – Methoden und Vorgehensweisen in einem Skiresort in den Rocky Mountains mit dem Ziel, das sie Verbindende kompakt zu formulieren und dafür einen auch für Topmanager attraktiven Titel zu finden. Das Ergebnis war das heute bestens bekannte „Agile Manifest” [2]. Immer wieder kommt seitdem die Forderung auf, seine vier „Werte” und zwölf „Prinzipien” im Lichte der inzwischen gemachten Erfahrungen anzupassen. Andererseits wird das Manifest in seiner Urform oft als „der” bleibende und einzige Maßstab dafür angesehen, was „Agilität” auch heute noch bedeutet. In einem Vortrag am 16. September 2013 in Vorarlberg (bei OMICRON, organisiert von PIONIERBASIS) betonte Alistair Cockburn, einer der Verfasser des Manifests, dass dieses Agile Manifest von 2001 ein „Schnappschuss” aus der damaligen Zeit heraus sei. Deshalb mache es keinen Sinn, diesen historischen Schnappschuss zu aktualisieren. Wenn sich diese 17 Unterzeichner des Manifests – oder andere Vertreter der aktuellen SW-Entwicklungsszene – heute träfen, um wiederum das sie Verbindende zu formulieren, dann wäre das Ergebnis ein anders.

Heute: Scrum mit XP-Techniken ist dominant
Bis ungefähr 2005 dominierte Extreme Programming (XP) die agile SW-Entwicklung. Daneben waren auch Scrum, die Crystal Family of Methodologies, Feature Driven Development (FDD), die Dynamic Systems Development Method (DSDM) und das Adaptive Software Development (nebst anderen) verbreitet. Seit 2005 entwickelte sich indessen Scrum (3.3.1 in [3]) rasch zur heute bekanntesten agilen Vorgehensweise der SW-Entwicklung auf Teamebene, jedoch mit Einschluss vieler Techniken aus XP.

Vier Grundsätze
Kennzeichen dieses Vorgehens sind:

Mehr und mehr setzt sich in letzter Zeit die Erkenntnis durch, dass dieses Vorgehen ein vielfach allzu vereinfachendes, idealisierendes und starres (statt agiles) Korsett darstellt und viele Problemzonen der Produktentwicklung und des Projektmanagements unbehandelt lässt.

Scrum oft zu vereinfachend und radikal
Zudem stellt sich immer wieder heraus, dass die mit der Einführung von Scrum verbundenen Verantwortlichkeits- und Organisationsänderungen insbesondere bei etablierten Unternehmen von vielen Betroffenen als unverhältnismäßig groß und in ihrer Radikalität als unangemessen angesehen werden. Zunehmend kristallisiert sich auch heraus, dass eine historisch gewachsene Systemheterogenität mit einem geringen Grad an Automatisierung im Bereich Integration und Test eine rasche Abfolge von Inkrementen (Releases) verhindert. Und es wird zunehmend bewusst, dass bei einer agilen Vorgehensweise der SW-Entwicklung auf Teamebene auch eine ihr entsprechende – adaptive – teamübergreifende Abstimmung auf Projekt-/Programm- und Portfolioebene nötig wird.

2010: Kanban für SW
Die Problematik starrer Sprints und der oft überfordernden Organisationsänderungen wird durch das erst seit 2010 breiter bekannte, von David J. Anderson für die SW-Entwicklung angepasste „Kanban” entschärft (3.3.2 in [3]). Es verbreitet sich derzeit rasch und wird auch zusammen mit Scrum zu „Scrumban” kombiniert.

SAFe gewinnt an Boden
Zur team- und projektübergreifenden agilen Abstimmung der projektunabhängigen fortlaufenden Produktentwicklung auf Programm- und Portfolioebene tritt derzeit das „Scaled Agile Framework for Enterprises” (SAFe) von Dean Leffingwell stark in Erscheinung (3.3.3 in [3]). Er hat es erstmals 2010 als Buch und als „big picture” im Internet veröffentlicht. Und für das agile Management von Projekten gewinnen DSDM und PRINCE2 (3.2 in [3]) als Rahmen für die Arbeit einzelner agiler Teams an Bedeutung.

Methodenentscheidungen sind keine Langfriststrategie!
Angesichts dessen, dass Scrum erst in den letzten Jahren so dominant wurde und heute in der agilen SW-Entwicklung zunehmend bekannte Vorgehensweisen wie Kanban und SAFe erst 2010 ins breitere Bewusstsein rückten, kann heute nicht vorausgesagt werden, was in fünf oder zehn Jahren die Szene der SW-Entwicklung prägen wird und inwieweit dann „agil” (oder „lean”) immer noch dominante Begriffe sein werden.

Längerfristig ausgelegte strategische Investitionsentscheidungen im Bereich eines spezifischen SW-Entwicklungsvorgehens sind also mit einer hohen Unsicherheit verbunden.

Systemheterogenität und Architekturmängel als Hindernisse
Eines aber ist mit Sicherheit auch langfristig gültig: Heterogene Systemlandschaften mit vielen, eher undurchsichtigen und oft improvisierten Schnittstellen, mit unüberblickbaren oder gar nicht dokumentierten Systemarchitekturen und Praktiken, die dem „Clean Code Development” widersprechen, können mit keinem wie auch immer gearteten Vorgehen der SW-Entwicklung entschärft werden. Das bedeutet im Umkehrschluss: Wichtiger als das Optimieren des Vorgehens der SW-Entwicklung ist,

Gefordert weiterhin: „Craftsmanship”
Angenommen, all das ist erreicht. Dann geht es jetzt um das Optimieren des Vorgehens in der SW-Entwicklung. Wie und wo beginnen Sie? Und was genau bedeutet „Optimieren des Vorgehens”? Wohin soll die Reise führen?

Um das zu beantworten, sollten Sie – bevor Sie sich mit spezifischen Philosophien (wie „Lean” oder „Agil”), Vorgehens-Frameworks oder Methodiken (wie Scrum, SAFe, PRINCE2, PMBOK, CMMI, RUP, V-Modell oder HERMES) beschäftigen – zusammen mit ihren „Peers” im Management Folgendes klären:

(Eine ausführliche Beschreibung der Technik solcher „Reisen in die Zukunft” finden Sie in [4])

Formulieren Sie das möglichst spezifisch und mit konkret beobachtbaren Kriterien. Vermeiden Sie dabei Fachbegriffe aus der „agilen Szene” (die in fünf Jahren vielleicht nicht mehr „in Mode” ist), sondern umschreiben Sie es in allgemein verständlichen „5-Cent-Worten”.

Etwa so:

KONKRETE Ziele als beste Hoffnungen
Diese nicht als vage Vision oder allgemeines Leitbild, sondern als konkrete Ziele formulierten „besten Hoffungen” sind nun Ihre Messlatte für mögliche und stets an Ihr Unternehmen anzupassende Vorgehens-Frameworks oder Methodiken Ihrer künftigen SW-Entwicklung.

Ihre Reise ins Land der besten Hoffnung und die als Orientierung möglichen generellen Vorgehens-Frameworks und Methodiken hängen ganz von Ihren spezifischen Zielen und Ihrem Unternehmen ab. Ihr Unternehmen ist ein stets komplex erscheinendes soziales System mit stets unternehmensspezifischen Problemstellungen. Generelle „Best Practices” als Lösung sind hier ungeeignet. Dinge, die in anderen Unternehmen erfolgreich waren, sind bestenfalls Denkanstöße, können aber nicht 1:1 für Ihr Unternehmen übernommen werden.

Kein Kochbuch, keine „Best Practices”
Als solche Denkanstöße und zur Orientierung (nicht aber als direkt nutzbare Blaupausen) werden im vorliegenden Beitrag unterschiedliche Vorgehens-Frameworks und Methodiken für drei von den jeweiligen Hauptaufgaben abhängige Aufgabenkonstellationen angeboten und im Kap. 08A04 im Detail behandelt:

Plattformbasierte Lösungen
Zur Verfügung stellen (Entwicklung/fortlaufende Betreuung/Anpassung/Weiterentwicklung) teils kundenspezifischer Varianten von SW-Lösungen und Services auf der Basis einer kundenneutralen Plattform oder eines kundenneutralen Lösungsbaukastens. Typische Beispiele: Anbieter von ERP-Lösungen; Anbieter umfassender Web-Shops samt Backoffice-Logistik und B2B-Lösungen.

Vorgehens-Frameworks und Methodiken für diese Konstellation müssen insbesondere auch das strategische Portfoliomanagement für die verschiedenen langfristig existierenden Produktlinien umfassen. Von zentraler Bedeutung sind bei dieser Aufgabenkonstellation einerseits die fortlaufende Pflege der kundenneutralen Lösungsplattform und andererseits die rasche Realisierung auch sehr spezieller – später auch zu betreuender – Kundenlösungen, ohne dabei die generelle Lösungsplattform zu verkomplizieren oder mit separaten Speziallösungen zu unterlaufen. Die konsequente Einhaltung und fortlaufende Optimierung einer modularen, serviceorientierten Gesamtarchitektur ist hier unabdingbar.

Es müssen also drei Arten von Vorgehensweisen in Einklang gebracht werden:

Erstens das kontinuierliche, als „Arbeitsfluss mit unbestimmtem Ende” gestaltete Pflegen und Weiterentwickeln der kundenneutralen Plattform. Zweitens das zeitlich begrenzte projektartige Entwickeln kundenspezifischer Lösungen unter weitestgehender Nutzung dieser Plattform. Und drittens das wiederum als „Arbeitsfluss mit unbestimmtem Ende” gestaltete Pflegen und Weiterentwickeln der kundenspezifischen Lösungen.

Unternehmen dieser Aufgabenkonstellation umfassen mehrere Hundert oft bis viele Tausend (weltweit) kooperierende Informatikspezialisten in Hunderten verschiedenen Teams. Nicht das Vorgehen und die Methodik in einem kleinen Team, das ein Produkt innerhalb eines Projekts realisiert, ist hier die Herausforderung, sondern die Koordination all dieser Spezialisten und Teams auf Programm- und Portfolioebene.

Für eine agile Form des Portfoliomanagements sind SAFe oder andere Varianten von Portfolio-Kanban denkbar. Das agile Management von Projekten ist mit PRINCE2 oder DSDM möglich. Die agile Kooperation vieler Teams innerhalb einer Produktlinie kann als „Release Train”, z. B. auf der Basis von SAFe auf der Programmebene erfolgen. Und für das agile Arbeiten im Team eignen sich Kanban (insbesondere bei fortlaufenden Wartungsarbeiten), Scrum, Scrumban oder DSDM. In jedem Fall müssen auf Teamebene Praktiken des Clean Code Development genutzt werden.

Umfassende Individuallösungen
Zur Verfügung stellen (Entwicklung/fortlaufende Betreuung/Anpassung/Weiterentwicklung) umfassender individueller SW-Lösungen und SW-Services für spezifische Kunden oder für den Eigenbedarf des Unternehmens. Typische Beispiele: Anbieter und Betreiber firmenspezifischer Spezialsoftware und -services; unternehmensinterner IT-Bereich.

Vorgehens-Frameworks und Methodiken auch dieser Konstellation müssen das strategische Portfoliomanagement für die verschiedenen langfristig zu unterstützenden individuellen SW-Lösungen und SW-Services umfassen.

In diesen Unternehmen müssen zwei Arten von Vorgehensweisen in Einklang gebracht werden:

Erstens das zeitlich begrenzte projektartige Neuentwickeln oder grundlegende Überarbeiten kundenspezifischer Individuallösungen. Und zweitens das als „Arbeitsfluss mit unbestimmtem Ende” gestaltete Pflegen und Weiterentwickeln der kundenspezifischen Lösungen.

Bei Unternehmen dieser Aufgabenkonstellation, insbesondere bei unternehmensinternen IT-Bereichen, besteht die Herausforderung sehr oft im Umgang mit der ohne „Überbauungsplan” historisch gewachsenen und sehr heterogenen System- und Anwendungslandschaft mit vielen, oft schlecht dokumentierten und undurchsichtigen Altsystemen.

Auch diese Art von Unternehmen kann mehrere tausend weltweit kooperierende Informatik-Spezialisten in vielen verschiedenen Teams umfassen. Auch hier ist die Herausforderung nicht primär das Vorgehen und die Methodik in einem kleinen Team, das ein Produkt innerhalb eines Projekts realisiert, sondern die Koordination all dieser Spezialisten und Teams auf Programm- und Portfolioebene.

Für eine agile Form des Portfoliomanagements sind – wie bereits vorher erwähnt – SAFe oder andere Varianten von Portfolio-Kanban denkbar. Das agile Management von Projekten ist mit PRINCE2 oder DSDM möglich. Die agile Kooperation vieler Teams innerhalb einer Produktlinie kann, wie schon erwähnt, als „Release Train”, z. B. auf der Basis von SAFe auf der Programmebene, erfolgen. Und für das agile Arbeiten im Team eignen sich Kanban (insbesondere bei fortlaufenden Wartungsarbeiten), Scrum, Scrumban oder DSDM. In jedem Fall müssen auf Teamebene auch hier Praktiken des Clean Code Developments genutzt werden.

Für das Bereinigen der historisch gewachsenen und sehr heterogenen System- und Anwendungslandschaften kann im SAFe all das nützlich sein, was sich auf „Architektur” (z. B. „Architectural Epics” auf Portfolioebene oder „Architectural Runway” auf Programmebene) bezieht.

SW-Entwicklung als Dienstleistung
Anbieten von SW-Entwicklungskapazität (Spezialisten samt Entwicklungsinfrastruktur) im Rahmen unterschiedlichster Kundenprojekte bis zur Inbetriebnahme der Lösung mit nur seltenen – separat beauftragten – anschließenden punktuellen Wartungs-, Anpassungs- und Erweiterungsarbeiten. Typische Beispiele: Als Agenturen auf Projektbasis arbeitende „Softwareschmieden” für kundenspezifische Individual-SW, etwa im Bereich Web-Lösungen.

Die Vorgehens-Frameworks und Methodiken sind vom Anbieter der SW-Entwicklungskapazität dann selbst bestimmbar, wenn mit dem Auftraggeber nur der funktionale Umfang der SW, die Kosten und die Termine vereinbart werden. Da solche Aufträge typischerweise als jeweils autonome Projekte mit einem klar definierten Ende von einem oder höchstens einer Handvoll kooperierender Teams bearbeitet werden, können Vorgehensweisen und Methodiken gewählt werden, die die Arbeit im Team und für ein Projekt ohne herausfordernde teamübergreifende Abstimmungen ins Zentrum rücken. Oft aber arbeiten Anbieter von SW-Entwicklungskapazitäten innerhalb von größeren und vom Auftraggeber gemanagten Projekten mit auftragsspezifischen Vorgaben für das Vorgehen und die Methodik.

Erfolgsentscheidend für solche Anbieter ist, dass sie sich in verschiedensten Vorgehens-Frameworks und Methodiken professionell bewegen können. Und zwar so, dass sie gegenüber dem Auftraggeber dessen Vorgehen nicht nur als „Fassade” bedienen und dahinter in ihrer gewohnten Art agieren, sondern effektiv im Sinn dieses Frameworks/dieser Methodik arbeiten. In jedem Fall – und kaum im Widerspruch zu vorgegebenen Frameworks – müssen auf Teamebene Praktiken des Clean Code Development als „die” Kernkompetenz des Dienstleisters genutzt werden.

Herausfordernd für diese Anbieter ist, dass sie einerseits in der Regel an mehreren solcher Projekte gleichzeitig arbeiten und andererseits bestimmte Spezialisten wie z. B. GUI-Designer mit nur einem Projekt allein nicht ausgelastet sind. Das erfordert eine projektübergreifende mittelfristige Einsatzplanung auf Personenebene, was allerdings die kurzfristige Flexibilität erschwert und der Idealvorstellung eines personell stabilen interdisziplinären Teams mit Personen, die nur in einem Team arbeiten, widerspricht.

Wenn Vorgehens-Frameworks und Methodiken vom Anbieter der SW-Entwicklungskapazität frei wählbar sind, dann sind auf der Ebene des agilen Projektmanagements – auch bei sehr kleinen Projekten – mit „Tailoring” angepasste Formen von PRINCE2 oder DSDM möglich und das agile Arbeiten auf Teamebene kann z. B. mit Kanban, Scrum, Scrumban oder DSDM erfolgen, kombiniert mit der Nutzung der Praktiken des Clean Code Development. Für die projektübergreifende mittelfristige Einsatzplanung auf Personenebene sind alle bekannten Methoden denkbar. Sie sollten im Interesse der Flexibilität und Transparenz jedoch möglichst einfach gestaltet sein und von den Betroffenen selbst (und nicht von einer zentralen Planungsinstanz) gepflegt werden können.

Es gibt also nicht „das eine” Vorgehens-Framework und „die eine” Methodik für alle diese unterschiedlichen Konstellationen. Und daher gibt es auch nicht „DIE” Agilität und „DEN EINEN” Weg in Richtung Agilität, sondern ganz verschiedene Ausprägungen von Agilität und der Wege dorthin. Selbst innerhalb eines Unternehmens können sich diese Ausprägungen und die Wege dorthin je nach aktueller Situation im und rund um das Unternehmen immer wieder ändern.

„Agilität” für ein Unternehmen bedeutet also nicht, sich einer der als „agil” bezeichneten Vorgehensweisen zu verpflichten, sondern je nach Situation das angemessene Vorgehen zu praktizieren, solange es passt, und rasch zu einem anderen Vorgehen zu wechseln, wenn es sich als passender anbietet.

„Agile Agilität”, keine normierte
Führt diese „agile Agilität” nicht zu einer überfordernden Vielfalt? Sollte Agilität nicht eher zu einer markanten Vereinfachung führen?

Ja – Vereinfachung, aber im Sinn eines drastischen Abbaus des zentralistischen Mikromanagements überall dort, wo es nicht passt, zugunsten des Vertrauens in die Selbststeuerungsfähigkeit sozialer Systeme.

Keine Simplifizierungen!
Vereinfachung jedoch nicht in dem Sinn, dass die Gesamtheit der unterschiedlichsten internen Steuerungsformen insgesamt betrachtet einheitlicher und einfacher wird. Vereinfachung darf nicht als Simplifizierung verstanden werden, dass z. B. alle Organisationseinheiten eines Unternehmens die identischen und einfachen Arbeitsregeln anwenden. Das wäre unangemessen.

Dieses Dilemma beschreibt der Philosoph Paul Valéry gut mit dem Satz: „Alles Einfache ist falsch, alles Komplizierte unbrauchbar.”

Zentrale Frage
Zu Beginn dieser Reise ist es wichtig zu klären, was denn diese „unternehmensindividuelle Art der Agilität” bedeutet.

Mithilfe der „Zeitmaschine” konnten Sie ja die „besten Hoffungen” für ein an Ihr Unternehmen angepasstes Vorgehens-Framework für eine optimale SW-Entwicklung als konkrete Ziele formulieren. Um diese Ziele zu erreichen, wird die Reise ziemlich sicher durch diese zwei Kontinente führen:

Das heute am meisten verbreitete Verständnis von „Agilität” beinhaltet

und findet seinen Ausdruck insbesondere auch im „Agilen Manifest”.

„Agilität” in diesem Sinn bedeutet also nicht, in erster Linie irgendeine der „agilen” Vorgehensweisen (z. B. Scrum) einzuführen, sondern in erster Linie beizutragen, dass sich die Kultur des Unternehmens in Richtung „vertrauensvolles Loslassen” und „Organisation entsteht durch Kommunikation” verändert.

Agilität ist zuallererst eine Kulturveränderung
Erst dann kann der polymorphe Kontinent der Vorgehensweisen die zur jeweiligen Aufgabenstellung passende Gestalt annehmen. Das kann z. B. Scrum, SAFe, PRINCE2, PMBOK, CMMI, RUP, V-Modell oder HERMES sein. Oder in einigen Jahren etwas, das wir heute noch gar nicht kennen. „Passend” kann nämlich je nach Situation etwas davon sein:

Natürlich ist es einfacher, vor allem in Vorgehensweisen zu investieren:

Investitionen in die Unternehmenskultur hingegen lassen sich nicht in diesem Sinn „machen”. Und deren Wirkung lässt sich nur bedingt „beweisen” und ist langfristiger Natur.

Es sind unternehmerische Entscheidungen, keine „Management Issues”.

Dieser „Reiseführer” beschreibt keine empfehlenswerten Routen, sondern für Ihr Unternehmen möglicherweise interessante Gegenden. Welche Sie wählen und wie Sie ihre Route zusammenstellen, hängt ganz von Ihrem Unternehmen ab. Und zwar von jenen mithilfe der „Zeitmaschine” erkannten Zielen, die sich auf den „Kontinent der Kultur” beziehen, also auf Kommunikations-, Kooperations- und Führungsmethoden, die Gegenstand der Organisations-, Personal- und Führungsentwicklung sind.

Auch dieser Reiseführer beschreibt, wie jener durch den Kontinent der Kultur, keine empfehlenswerten Routen, sondern für Ihr Unternehmen und für die jeweils spezifische Aufgabestellung der SW-Entwicklung mögliche Optionen. Welche Sie wählen und wie Sie Ihre Route zusammenstellen, hängt von der Aufgabenstellung und vor allem auch von der Kultur des die Aufgabe leistenden Bereichs im Unternehmen ab.

In der „agilen Szene” werden, insbesondere im Zusammenhang mit Scrum, geradezu phantastische Erhöhungen der Entwicklungsgeschwindigkeit berichtet.

Phantastische Erhöhung der Entwicklungsgeschwindigkeit?
Ein typisches Beispiel ist das Paper „Scrum Metrics for Hyperproductive Teams: How They Fly like Fighter Aircraft” von Scott Downey und Jeff Sutherland [16]. Dort wird über Fälle mit um mehr als einige hundert Prozent (!) höheren Geschwindigkeiten von Scrum-Teams im Vergleich zu „Wasserfall-Teams” berichtet. Alle diese Berichte beruhen jedoch auf einzelnen Fällen mit eher episodischem Charakter, die überdies von überzeugten Vertretern agiler Methoden publiziert wurden.

Wissenschaftliche Studie zeigt anderes Bild
Eine unabhängige Masterarbeit an der Universität Hagen [17] zeigte im Gegensatz dazu, dass Scrum zu keiner signifikanten Erhöhung der Effizienz führt. Insgesamt (bezogen auf ein gesamtes fertiges Produkt) wird es demnach mit Scrum nicht eindeutig schneller oder billiger. Die von Verfechtern des agilen Vorgehens behaupteten massiven Verbesserungen der Entwicklungsgeschwindigkeit und Kostenreduktionen bedürfen noch der Erhärtung durch unabhängige wissenschaftliche Studien, basierend auf einer Vielzahl von Fällen.

Gelegentlich wird auch das „CHAOS Manifesto” der Standish Group 2011 zitiert, wonach agil abgewickelte Projekte nur in 9 % der Fälle scheiterten, „Wasserfallprojekte” hingegen in 29 %. Unterschlagen wird dabei, dass es sich bei den agilen Projekten vor allem um eher kleine bis mittlere Projekte handelt. Und gemäß CHAOS-Report der Standish Group hängt die Erfolgsrate von Projekten, unabhängig von der Vorgehensweise, stark von ihrer Größe ab: Projekte unter 750.000 US$ sind zu 46 % erfolgreich, jene zwischen 6 und 10 Mio. US$ nur zu 11 %.

Auch negative Auswirkungen des agilen Vorgehens
Dass sich die Umstellung auf agile SW-Entwicklung in jedem Fall rechnet, ist also umstritten. Im Gegenteil: Sie kann, gemäß der Swiss Agile Study 2012 [18], auch zu einer eher verschlechterten Wartbarkeit und Erweiterbarkeit und zu eher höheren Entwicklungskosten führen, wobei andererseits die Handhabbarkeit geänderter Prioritäten und „time to market” markant besser werden.

Keine bessere SW-Qualität mit „agil”
Ein ernüchterndes Ergebnis zeigt auch die in Kooperation mit den Hochschulen Bremen und Bremerhaven, der Fachhochschule Köln, der ANECON Software Design und Beratung G.m.b.H., dem German Testing Board und dem Swiss Testing Board durchgeführten „Umfrage 2011: Softwaretest in der Praxis” [19]. Rund 800 Personen antworteten, 1/3 davon aus Firmen zwischen 100 und 1'000 Mitarbeitenden. Ergebnis war, dass es bezüglich der SW-Fehler im Betrieb kaum einen Unterschied zwischen agil und nicht-agil erstellter SW gab.

Agil dann nützlich, wenn es zum Ziel passt
Ob die Umstellung auf ein agiles Vorgehen in der SW-Entwicklung wirtschaftlichen Nutzen bringt, hängt also davon ab, was damit erreicht werden soll: Geht es primär um die schnelle Reaktionsfähigkeit oder primär um die langfristige Wartbarkeit und um eine möglichst hohe Qualität?

Zielerreichung mit Metriken verfolgen!
Wenn das Vorgehen der SW-Entwicklung verändert wird, muss also klar sein, was der Effekt sein soll, und dieser Effekt muss im Verlauf der Umstellung kontinuierlich mit geeigneten und robusten Metriken beobachtet werden.

Kulturveränderung entzieht sich der Wirtschaftlichkeitsbetrachtung
Unabhängig von der rein wirtschaftlichen Betrachtung ist der Nutzen einer veränderten Kultur im Unternehmen. Veränderungen im Bereich der Kommunikation, Kooperation und Führung entziehen sich jedoch harten Wirtschaftlichkeitsbetrachtungen. Es sind unternehmerische Entscheidungen dazu, wie ein Unternehmen von innen und von außen wahrgenommen werden soll und wie ausgeprägt seine Fähigkeiten bezüglich Robustheit, Belastbarkeit, Reaktionsfähigkeit, Flexibilität, Innovationsfähigkeit und Anpassungsfähigkeit sind.

Die Umstellung auf agile SW-Entwicklung ist vergleichbar mit einer langen Reise: Die Reise führt zunächst durch den Kontinent der Kultur, um die Voraussetzungen für die jeweils passende Art der (agilen) SW-Entwicklung zu schaffen. Diese Reise durch den Kulturkontinent ist eine strategische und langfristig wirksame Investition. Die dabei erworbenen Praktiken im Bereich Kommunikation, Kooperation und Führung sind – unabhängig von speziellen agilen oder nicht agilen Vorgehensweisen der SW-Entwicklung –wertvoll, auch wenn einige davon – wie etwa Daily Stand-up oder die Visualisierung des Arbeitsflusses – heute als typische Elemente bestimmter agiler Entwicklungsmethoden gesehen werden.

Danach (und nicht vorher!) führt die Reise durch den Kontinent der Vorgehensweisen. Sie beginnt in jedem Fall mit dem Craftsmanship für eine handwerklich professionelle SW-Entwicklung jenseits aller spezifischen Vorgehensweisen. Danach geht die Reise – je nach der Kultur Ihres Unternehmens, seinen Hauptaufgaben, Aufträgen und Kunden – durch ganz unterschiedliche Vorgehenslandschaften. Seien Sie also gerüstet für einen sehr agilen Umgang mit agilen (und nicht agilen) Vorgehensweisen. Und rechnen Sie damit, dass in wenigen Jahren der Kontinent der Vorgehensweisen möglicherweise von anderen, heute noch nicht erahnten, Landschaften geprägt sein könnte. Legen Sie sich also nicht allzu stark auf bestimmte, heute aktuelle Vorgehensweisen fest. Bleiben Sie auch diesbezüglich agil!

Und formulieren Sie klar, was der wirtschaftliche Effekt der Umstellung sein soll, und beobachten Sie fortlaufend mit geeigneten Metriken, wie gut dieser Effekt erreicht wird.