Business Technology 06/15

Agile Entwicklung im Vergleich mit anderen Branchen

Autor:

Eine häufig gestellte Frage ist, warum man agile Vorgehensweisen in anderen produzierenden Branchen nicht antrifft. Gibt es tatsächlich triftige Gründe dafür oder haben wir in der IT unsere Disziplin nur nicht im Griff und versuchen uns dann mit Dingen wie Agilität zu retten, anstatt uns wie die anderen Branchen auf erprobte Ingenieurstugenden zu besinnen? Oder gibt es Agilität sehr wohl in anderen Branchen, und suchen wir nur an den falschen Stellen?

Auch im Rahmen des Speaker Panels zum Abschluss des Agile Days auf der JAX 2010 [1] wurde von einem Teilnehmer aus dem Auditorium die zuvor beschriebene Frage an die versammelten Speaker des Tages gestellt. Das scheinbare Fehlen der Agilität in anderen Branchen wie etwa dem Gebäude- oder dem Autobau verursacht bei vielen Beobachtern und Interessenten von agilen Vorgehensmodellen (z. B. Scrum [2] oder XP [3]) häufig gewisse Vorbehalte gegenüber diesen Vorgehensweisen. Sie fragen sich, ob nicht einfach das Fehlen einer vernünftigen ingenieursmäßigen Behandlung der Softwareentwicklung – was schon seit vielen Jahren immer wieder bemängelt wird – die IT gezwungen hat, sich mit Themen wie Agilität auseinanderzusetzen. Sie fragen sich, ob es nicht sinnvoller wäre, die Softwareentwicklung vernünftig ingenieurmäßig aufzubereiten, um deterministisch eine Produktionsqualität, wie z. B. im Fahrzeug- oder im Hausbau, zu erzielen, anstatt sich auf Behelfslösungen wie agile Vorgehensmodelle zu verlassen. Es gibt eine Menge mehr oder minder guter Antworten auf diese Fragen. Auch die Speaker auf der JAX hatten einige (gute) Antworten parat. Verfolgt man das Thema aber weiter, sind aus Sicht des Autors die folgenden zwei Kernaussagen von essenzieller Bedeutung:

  • Softwareentwicklung ist in der Tat anders als andere Ingenieurwissenschaften, da sie einen relativ einmaligen Bauprozess hat.
  • Ein ausschließlich ingenieurmäßiges Vorgehen funktioniert nicht in komplexen Umgebungen, mit denen wir bei der Softwareentwicklung häufig konfrontiert sind.

Was das im Detail bedeutet, wird im Folgenden genauer betrachtet.

Phasenzuordnung und unterschiedliche Systeme

Softwareentwicklung ist anders

Warum kann man z. B. ein Haus oder ein Brücke nicht agil bauen? Pavlo Baron, einer der Speaker des zuvor beschriebenen Panels auf der JAX 2010, hat dazu ein schönes Beispiel gebracht: „Stellen Sie sich vor, man würde eine Brücke agil bauen. Es werden zehn Meter gebaut, dann lässt man die Autos losfahren und dann …“ (Pause, gefolgt von Gelächter aus dem Publikum) „… oder aber wir bauen die Brücke zwar auf der ganze Länge, aber nur zehn Zentimeter breit.“ Beides führt nicht zum gewünschten Mehrwert für die Anwender. Agiler Brückenbau macht offensichtlich wenig Sinn. Warum geht es dann in der Softwareentwicklung?

Das Hauptproblem liegt in einer falschen Wahrnehmung des Bauprozesses in der Softwareentwicklung. Zum besseren Verständnis betrachten wir noch einmal den Brückenbau. Der Brückenbau lässt sich in eine Entwurfs- und eine Bauphase unterteilen. In der Entwurfsphase werden die Anforderungen an die Brücke gesammelt, diese werden konsolidiert und abgestimmt, es wird eine Lösungsidee entworfen und immer weiter verfeinert, bis am Ende die detaillierten Baupläne fertig sind. Die Baupläne sind das finale Design des Brückenbaus. Danach geht es in die Bauphase. Wenn man nichts falsch gemacht hat und keine ungeplanten Überraschungen auftauchen, kann man auf Basis der Pläne die Brücke komplett bauen, ohne dass noch irgendeine weitere Klärung oder Verfeinerung notwendig wäre. Das ist die „Definition of Done“ der Entwurfsphase: Die Entwurfsphase ist abgeschlossen, wenn alle notwendigen Festlegungen getroffen sind, um das Produkt – in dem Fall die Brücke – vollständig bauen zu können.

Wie sieht das jetzt in der Softwareentwicklung aus? Beginnen wir mit einer einfachen Frage: Was ist das Produkt in der Softwareentwicklung? Das ist das ausführbare Programm, nicht der Sourcecode. Sourcecode interessiert die meisten Anwender nicht die Bohne und hat insbesondere auch keinen Mehrwert für sie, ein ausführbares Programm hingegen schon. So weit, so einfach.

Jetzt zur deutlich schwierigeren Frage: Wann ist in der Softwareentwicklung die Entwurfsphase zu Ende und wann beginnt die Bauphase? Und mit „Phase“ ist hier keine Phase im Sinne einer zeitlichen Abfolge wie beim Wasserfallmodell gemeint, sondern eine logisch in sich abgeschlossene Tätigkeit. Unter Berücksichtigung der zuvor beschriebenen Definition of Done hat Neal Ford [4] die folgende für viele überraschende Antwort geliefert: Entgegen der weit verbreiteten Ansicht ist die Entwurfsphase nicht am Ende der Designphase zu Ende, sondern erst am Ende der Implementierungsphase. Erst mit dem Schreiben der letzten Zeile Code ist der Entwurf abgeschlossen. Erst dann sind alle Festlegungen für das zu erstellende System getroffen.

Und wo bleibt dann die Bauphase? Nun, die ist in der Softwareentwicklung aufgrund des virtuellen Werkstoffs Software so billig, dass man sie häufig übersieht: Die Bauphase ist – wie der Name schon andeutet – der Build sowie das Deployment, das Übersetzen des Sourcecodes sowie das Zusammensetzen und Verteilen der fertigen Anwendung. Interessanterweise sind wir an dieser Stelle ingenieursmäßig heute schon so weit, dass wir das vielfach schon auf Knopfdruck können. Moderne Build- und Deploymentsysteme können das vollautomatisch. Wir verfügen an der Stelle über eine Effizienz und Effektivität, von der viele andere Ingenieurdisziplinen nur träumen können.

Woher kommt der häufig gemachte falsche Schnitt zwischen Entwurfs- und Bauphase? Dafür gibt es aus Sicht des Autors zwei Hauptgründe:

  • Die Bauphase ist so billig, dass man sie einfach übersieht. Dadurch, dass das Produkt Software so ungemein günstig zu produzieren (nicht zu entwerfen) ist, gehen sowohl die Zeit als auch die Kosten für den reinen Bau der Software nahezu gegen Null. Das ist ein grundlegender Unterschied zu den meisten anderen Branchen, in denen der Bauprozess sehr aufwändig und teuer ist, wesentlich aufwändiger und teurer als der Entwurfsprozess. Ganz anders in der Softwareentwicklung: Hier können wir so häufig bauen wie wir wollen. Es kostet uns nur einen Mausklick. Die meisten Leute suchen aber nach einer aufwändigeren Phase und assoziieren so die Implementierungsphase fälschlicherweise mit der Bauphase anderer Ingenieurdisziplinen.
  • Der Begriff „Designphase“ lässt vermuten, dass am Ende des Designs die Bauphase beginnt. Das ist grundsätzlich auch nicht falsch; nur wurden die bis heute üblichen Begriffe in der Softwareentwicklung zu einer Zeit geprägt, als Programmierung in der Tat noch Teil der Bauphase war. Zu der Zeit wurden Programme häufig während der Analyse und des Designs bis auf Statement-Ebene spezifiziert und die so genannten Anwendungsprogrammierer hatten dann die Aufgabe, die fertige Programmbeschreibung relativ mechanisch in COBOL, PL/1, Assembler o. ä. zu übersetzen. Diese Art der Aufgabentrennung zwischen Design und Programmierung gibt es aber schon lange nicht mehr. Entwickler sind Designer und Programmierer in einer Person. Aufgrund des Zeit-und Kostendrucks erfolgen Designs nur noch auf einer wesentlich gröberen Ebene und werden im Rahmen der Implementierung dann weiter verfeinert. Das eigentliche Programmieren ist dabei nur noch Nebensache. Die alte Vorgehensweise kann sich heute niemand mehr leisten, weder zeitlich noch monetär. Was geblieben ist, sind die alten Bezeichnungen. Abbildung 1 verdeutlicht die beiden Sichtweisen noch einmal.

Zusammenfassend bedeutet das, dass sowohl die extrem niedrigen Kosten in der Bauphase als auch eine nicht mehr zeitgemäße Begriffsverwendung zu den beschriebenen Verwirrungen beim Vergleich der Softwareentwicklung mit anderen Branchen geführt haben. Zusätzlich eröffnen die extrem niedrigen Baukosten in der Softwareentwicklung gegenüber anderen Branchen ganz neue Möglichkeiten. Softwareentwicklung ist also tatsächlich anders.

Oder können Sie sich folgendes Szenario im Brückenbau vorstellen: Erste Woche: „Ich will eine Brücke über diesen Fluss. Bauen Sie mal eine ganz normale Brücke bis nächste Woche.“ Zweite Woche: „Ach, ich glaube, dass wir die doch besser vierspurig bauen sollten.“ Dritte Woche: „… oder vielleicht doch besser als Hängebrücke?“ Vierte Woche: „Ich habe gerade die Verkehrsprognose erhalten. Wir sollten sie doch auf sechs Spuren erweitern und als Tunnel bauen.“ … und so weiter. Das klingt absolut absurd, oder? In der Softwareentwicklung ist das aber normal und funktioniert meistens sogar, weil die Bauphase praktisch nichts kostet.

Softwareentwicklung ist komplex

Kommen wir zur zweiten Aussage: Ein ausschließlich ingenieurmäßiges Vorgehen funktioniert nur in einfachen und komplizierten Umgebungen, aber nicht in komplexen, mit denen wir bei der Softwareentwicklung häufig konfrontiert sind. Was soll das bedeuten? In der Systemtheorie und darauf aufsetzenden Konzepten findet man die Unterscheidung zwischen den folgenden Typen von Umgebungen bzw. Systemen (z. B. [5], [6], Abb. 2).

  • Einfache Systeme zeichnen sich durch einfach nachvollziehbare Ursache-Wirkung-Zusammenhänge aus. Es gibt nur wenige Einflussgrößen, die nur schwach miteinander verknüpft sind und sich über die Zeit nicht verändern (keine oder nur sehr geringe Dynamik). Probleme in einfachen Systemen sind leicht zu verstehen und zu lösen. Der Lösungsweg lässt sich in klar strukturierten Prozessen und so genannten Best Practices für jedermann wiederholbar festhalten. Ein einfaches Problem ist z. B. das Reinigen eines Fahrzeugs oder das Austauschen der Tonerkartusche bei einem Drucker.
  • Komplizierte Systeme unterscheiden sich von einfachen Systemen dadurch, dass es viele Einflussgrößen gibt, die stark miteinander verknüpft sind. Die Verknüpfungen sind aber ebenfalls über die Zeit konstant (geringe Dynamik). Im Gegensatz zu einfachen Systemenist die Ursachen-Wirkung nicht mehr für jedermann offensichtlich. Deshalb benötigt man häufig Experten, um Probleme in komplizierten Systemen zu analysieren und zu lösen. Das System bleibt aber in sich deterministisch und es gibt zumindest eine richtige Lösung für ein Problem. Ein kompliziertes Problem ist z. B. das Reparieren eines defekten Fahrzeugs oder die Softwareverteilung in einem großen Unternehmen.
  • Komplexe Systeme haben wie komplizierte Systeme viele Einflussgrößen, die stark miteinander verknüpft sind. Allerdings sind diese Verknüpfungen einer hohen Dynamik unterworfen, d. h. sie verändern sich stark über die Zeit. Damit beginnt das System überraschende Eigenschaften zu entwickeln, die durch isolierte Betrachtung seiner Bestandteile nicht mehr erklärbar sind (Stichwort: Emergenz). Die Komplexität liegt nicht primär in den Bestandteilen des Systems, sondern in der dynamischen Interaktion zwischen den Teilen. Dennoch bilden sich im Gegensatz zu chaotischen Systemen (die hier nicht betrachtet werden sollen) Muster, die man erkennen muss, um Probleme in einer solchen Umgebung zu lösen. Man nähert sich der Lösung in (kurzen) Zyklen des Probierens, Bewertens und Korrigierens sukzessive an. Komplexe Systeme entstehen fast immer, wenn Menschen ins Spiel kommen.

Ein Unternehmen ist z. B. ein komplexes System. Das Entwerfen eines neuen Autos (nicht nur die reine Konstruktion, sondern der gesamte Prozess) oder einer neuen Software sind ebenfalls (fast immer) komplexe Probleme.

Oft werden komplizierte und komplexe Probleme miteinander gleichgesetzt. Das kommt zum einen daher, dass die Begriffe im täglichen Sprachgebrauch häufig synonym verwendet werden. Zum anderen liegt es aber auch daran, dass komplizierte Probleme auf den Laien – und wir sind nun einmal Laien in allen Themen, die nicht zufällig unsere Fachgebiete sind – ähnlich wirken wie komplexe Probleme. Er erkennt die zugrunde liegenden Ursache-Wirkung-Prinzipien nicht und der Effekt ist, dass ihm das komplizierte Problem komplex erscheint.

Was haben einfache, komplizierte und komplexe Systeme denn mit der zuvor beschriebenen Aussage zu tun? Nun, ingenieursmäßiges Vorgehen basiert auf festen Ursache-Wirkung-Prinzipien und stabilen Teil-Ganzes- Beziehungen. Große Probleme werden nach dem Teile und- Herrsche-Prinzip in kleine Probleme zerlegt, die in der Summe das große Problem ergeben. Komplizierte Lösungen werden nach klaren Regeln aus einfachen Lösungen zusammengesetzt. Damit ist ein ingenieursmäßiges Vorgehen dazu geeignet, einfache und auch komplizierte Probleme zu lösen. Es ist beeindruckend, welch hochkomplizierte Probleme die Ingenieurskunst gelöst hat, aber sie benötigt stabile Ursache-Wirkung-Zusammenhänge.

Komplexe Probleme hingegen mit ausgeprägter Dynamik, bei denen die Wechselwirkungen über die Zeit das Systemverhalten dominieren und nicht mehr die Eigenschaften der Einzelteile, kann man nicht ingenieurmäßig lösen. Komplexe Probleme kann man nur mit empirischen Vorgehensmodellen lösen, die auf kurzen Zyklen, schnellem Feedback, häufigen Reflektionen und kontinuierlicher Annäherung an die Lösung basieren.

Heutige Softwareentwicklung ist eine komplexe Aufgabenstellung. Genauer gesagt besteht sie aus einfachen, komplizierten und komplexen Anteilen. Die Komplexität ergibt sich alleine schon daraus, dass in der Regel viele Menschen in den Entwicklungsprozess involviert sind, vom Manager über Fachbereiche, Anwender, Projektleiter, Entwickler, Tester, Betrieb, Datenschutzbeauftragte, Betriebsrat usw., und sich dadurch ein komplexes System mit hoher, nicht vorhersagbarer Dynamik über die Zeit ergibt. Zusätzlich sind die genauen Anforderungen zu Beginn eines Projekts häufig noch unklar. Sie klären sich erst im Laufe des Projekts, und erste Lösungen haben dann wieder Rückwirkungen auf die Anforderungen. So ändern sich Anforderungen, weil man lernt, dass sie sich in der geplanten Form nicht umsetzen lassen, die ursprüngliche Anforderung nicht zum gewünschten Ergebnis führt, Konflikte zwischen verschiedenen Anforderungen aufgedeckt werden oder durch veränderte Rahmenparameter neue Anforderungen entstehen usw. Die Wechselwirkungen und Einflüsse sind hochdynamisch, kurzum: Softwareentwicklung ist heute in der Regel komplex.

Komplexität kann man nicht ignorieren

Man kann versuchen, diese Komplexität zu verleugnen und so tun, als wären alle Probleme in der Softwareentwicklung höchstens kompliziert, getreu dem Motto „Es gibt kein Problem, das man per ‚Teile und Herrsche’ nicht in den Griff bekommt“. Die Fehlschlagstatistiken von IT-Projekten sprechen da aber eine andere Sprache. Massive Termin- und Budgetüberschreitungen, schlechte Qualität und unzufriedene Kunden sind das häufige Ergebnis, wenn man die Komplexität ignoriert und nur auf definierte Prozesse und ingenieursmäßiges Vorgehen setzt. Besser ist es, auf Vorgehensweisen zu setzen, die explizit mit der Komplexität umgehen. Die derzeit bekanntesten Vertreter dieser Kategorie sind die agilen Vorgehensweisen. Sie bündeln genau die Elemente, die man benötigt, um komplexe Probleme zu lösen: Kurze Zyklen, schnelles Feedback, häufige Reflektionen, kontinuierliche Annäherung an die Lösung, gepaart mit weiteren Erfolgsfaktoren für komplexe Umfelder wie viel Kommunikation, interdisziplinäre, sich selbst organisierende Teams, indirekte Führung, kontinuierliches Lernen usw.

Andere Branchen wie die Automobil- oder die Pharmaindustrie haben das übrigens schon lange verstanden: Komplexe Probleme wie das Entwickeln neuer Fahrzeuge oder neuer Medikamente werden dort schon lange mit agilen Methoden gelöst. Auch wenn es nicht immer explizit agil genannt wird, findet man an diese Stelle die ganzen zuvor beschriebenen Elemente der Agilität: kurze Zyklen, schnelles Feedback usw.

Tatsächlich stammen viele der Grundideen der heutigen Agilität nicht aus der Softwareentwicklung, sondern aus anderen Branchen wie Automobil-, Kopierer- oder Kamerabau, die Lösungen für die Komplexitätsprobleme in der Produktentwicklung gesucht haben [7]. Die agilen Grundideen lassen sich sogar bis in den militärischen Flugzeugbau der 50er Jahre zurückverfolgen [8], wo sie sehr erfolgreich angewendet worden sind. Vielleicht würde uns der in anderen Ingenieursbranchen schon lange selbstverständliche Umgang mit Agilität leichter fallen, wenn wir endlich akzeptieren, dass das Entwickeln und Schreiben des Sourcecodes nicht (mehr) zum Bauen, sondern zum Entwerfen der Lösung gehört. Und das ist wie in den anderen Branchen in der Regel eine komplexe Aufgabenstellung, für die man die angemessene Vorgehensweise – wie etwa Agilität – benötigt.

Ist damit ingenieursmäßiges Vorgehen in der Softwareentwicklung komplett passé? Nein, natürlich nicht. Wie bereits zuvor geschrieben, besteht Softwareentwicklung aus einfachen, komplizierten und komplexen Anteilen. Die einfachen und komplizierten Anteile sollten wir natürlich weiterhin mit ingenieursmäßigem Vorgehen lösen (bzw. ad hoc in ganz einfachen Fällen), denn da hilft uns Agilität nicht weiter. Das tun wir auch schon mit großem Erfolg, was aber nicht heißt, dass wir da nicht noch besser werden sollten. Abbildung 3 verdeutlicht den Zusammenhang zwischen Aufgabenstellung und angemessener Methodik noch einmal.

Aufgabe und Methode

Zusammenfassung

Zusammenfassend lässt sich festhalten, dass das Implementieren von Software, d. h. das Entwickeln von Sourcecode, nicht Teil der Bauphase, sondern Teil der Entwurfsphase ist. Erst mit der letzten Zeile Sourcecode ist der Entwurf abgeschlossen. Die extrem niedrigen Kosten des eigentlichen Bauens von Software im Vergleich zu anderen Branchen führen häufig dazu, dass diese Phase komplett übersehen wird. Als Folge wird das Implementieren von Software mit der Bau- oder Produktionsphase in anderen Branchen verglichen, also sozusagen Äpfel mit Birnen. Dadurch hinken praktisch alle Vergleiche der Softwareentwicklung mit anderen Branchen sowohl in Bezug auf ingenieursmäßiges Vorgehen als auch in Bezug auf Agilität.

Weiterhin ist die heutige Softwareentwicklung eine komplexe Aufgabenstellung, die man mit klassischen ingenieurmäßigen Mitteln nicht in den Griff bekommen kann. Dafür benötigt man andere Mechanismen, wie sie z. B. die Agilität anbietet. Andere Branchen praktizieren das schon lange erfolgreich, indem sie z. B. die komplexe Produktentwicklung nach agilen Prinzipien organisieren, während sie den komplizierten Produktbau ingenieurmäßig optimieren. Agilität gibt es also sehr wohl in anderen Branchen, man muss nur an den richtigen Stellen suchen.

Damit stellt sich in der Softwareentwicklung nicht die Frage nach ingenieursmäßigem Vorgehen oder Agilität, sondern es ist klar, dass wir beides benötigen: Die einfachen und komplizierten Aufgabenstellungen sollten wir weiter ingenieurmäßig optimieren, während wir die komplexen Probleme mithilfe von Agilität lösen sollten. Grundsätzlich sind wir da aber schon auf einem guten Weg (wenn auch nicht immer aus den richtigen Gründen). Jetzt müssen wir nur noch mit den Glaubenskriegen aufhören und uns auf das Lösen unserer reichlich vorhandenen Herausforderungen und „Probleme“ mit den jeweils passenden Mitteln konzentrieren. Aber auch das werden wir noch schaffen…

Links & Literatur

[1] Agile Day auf der JAX 2010: http://it-republik.de/konferenzen/jax2010/session/?tid=1505
[2] Scrum: http://de.wikipedia.org/wiki/Scrum
[3] Extreme Programming: http://de.wikipedia.org/wiki/Extreme_Programming
[4] Ford, Neal: „Emergent Design & Evolutionary Architecture“, Vortrag bei der rheinjug: http://www.rheinjug.de/videos/gse.lectures.app/Talk.html#EmergingDesignRheinjug
[5] Snowden, D.J.; Boone, M.E.: „A Leaders’s Framework for Decision making“, in Havard Business Review, November 2007
[6] Honegger, J.: „Vernetztes Denken und Handeln in der Praxis“, Versus Verlag Ag, Zürich 2008
[7] Takeuchi, H.; Nonaka, I.: „The new new Product Development Game“, in Havard Business Review, Januar-Februar 1986
[8] Bradshaw, Pete: „R&D Archaeology: The Lockheed SkunkWorks“

Vollständiger Artikel