Traditionelle und agile Ansätze

In den letzten Jahren kommen immer mehr Firmen zum Schluss, dass eine Umstellung zu agilen Vorgehensweisen für sie zum Erfolgsfaktor wird. Entsprechend gross ist die Nachfrage nach Ausbildungen und gut ausgebildeten und erfahrenen Fachleuten, welche agile Techniken erfolgreich einsetzen können.

Tatsächlich hängt dies stark mit den Problemen herkömmlicher Projekt-Vorgehensweisen zusammen. In der Fachliteratur wird diese Vorgehensweise oft unter dem Stichwort «Wasserfall»-Modell subsumiert und die offensichtlichste Darstellungsform beruht auf riesigen Gantt-Charts, einer Darstellungsform, welche von Henry L. Gantt (1861–1919) entwickelt wurde und den Eindruck vermittelt, dass sich selbst Projekte mit dutzenden oder hunderten von Beteiligten und Projektdauern über viele Jahre hinweg als terminierbare Abfolgen von Ursache und Wirkung planen und darstellen lassen. In Tat und Wahrheit ist sich jeder Projektleiter, der Projekte in solchen Grössen geleitet hat, sehr wohl bewusst, dass Planungen zwar kurzfristig eine relativ grosse Präzision haben können, dass es aber schlichtweg unmöglich ist, die Einflüsse, welche in einem halben Jahr oder noch später auf ein Projekt einwirken, vollumfänglich zu planen. In solchen Zeitspannen verändern sich Gesetze und äußere Rahmenbedingungen, die Situation des Projekt-Kunden und dessen Anforderungen, womöglich einsetzbare Ressourcen, vorhandenes Know-how, die Entwicklung der Technologie und schließlich und endlich lernen sowohl die Mitglieder des Projektteams wie auch der Kunde mehr über Projektinhalt und Umfang.

Eine Untersuchung der Standish Group von 2012 ergab, dass von den untersuchten Projekten, welche basierend auf «Wasserfall»-Ansätzen geführt wurden, ganze 29% Fehlschläge waren und 57% nicht innerhalb der ursprünglich geplanten Parameter fertiggestellt wurden. Als wirkliche Erfolgsprojekte galten nur gerade 14%. Von den mit agilen Vorgehensweisen geführten Projekten schlugen dagegen nur 9% fehl, 49% wurden nur mit Abweichungen zur ursprünglichen Planung fertiggestellt und ganze 42% waren erfolgreich.

Projekterfolg: Wasserfall vs. Agile

Projekt-Erfolg: Wasserfall vs. Agile

Somit waren dreimal so viele agile Projekte erfolgreich und weniger als ein Drittel der Anzahl der Projekte, welche mit herkömmlichen Vorgehensweisen fehlschlugen, schlugen beim Einsatz von «Agile» fehl. Offensichtlich wird aus der Darstellung aber auch, dass der Einsatz agilen Vorgehens allein noch keinen Erfolgsgaranten für Projekte darstellt.

Wasserfall-Projekte

Unter Projekten nach der Wasserfallmethode werden im Allgemeinen Projekte verstanden, bei denen eine ausgeprägte Planungsphase am Anfang steht, in der das ganze Projekt geplant wird. Ist die Planung abgeschlossen, werden die geplanten Aktivitäten durchgeführt, in die bestehende Umgebung integriert und das Resultat anschliessend getestet und schliesslich an den Kunden ausgeliefert (unterschiedliche Methoden und Ansätze unterscheiden dabei teils die genannten, teils weitere/andere Umsetzungsphasen wie beispielsweise Analyse-Design-Entwicklung-Integration-Test). Allen gemeinsam ist, dass im Wesentlichen von einer Gesamtplanung zu Projektbeginn ausgegangen wird, deren Resultate anschliessend abgearbeitet werden. Die erstellte Planung ist oft Vertragsbestandteil und Grundlage von Aufwandsschätzung und kommerziellen Vereinbarungen. Das führt dazu, dass neue Anforderungen, welche sich teils aus Kundenwünschen und teils aus veränderten Rahmenbedingungen ergeben, meist über Change Requests bearbeitet werden und oft zu weiteren Verhandlungen führen.

Die Vorgehensweise zeigt ein weiteres Charakteristikum, welches oft dazu führt, dass «Wasserfall- Projekte» in vielen Fällen nicht den Erfolg zeigen, wie er gewünscht ist. Gerade bei Vereinbarungen mit festem Budget und Ablieferungszeitpunkt kommt es oft dazu, dass für die zu Projektende eingeplanten Tests zu wenig Budget und Zeit vorhanden ist und Tests entsprechend nicht in dem ursprünglich geplanten Umfang stattfinden.

Projekt-Management Weisheit: «Kein Plan überlebt den Kontakt mit der Realität.»
Angelehnt an «Kein Plan überlebt die erste Feindberührung» von Helmuth von Moltke, preussischer Generalfeldmarschall.

Projektablauf «Wasserfall-Modell»

Projektablauf Wasserfall-Modell

Erfolgsfaktoren agiler Projekte

Erfolgsfaktoren agiler Projekte

Wenn wir «Agile» als mögliche Alternative zu Projektmanagement nach dem Wasserfall-Modell sehen, gilt es zunächst klar zu definieren, was unter «Agile» zu verstehen ist. Das Adjektiv «agil» meint die Fähigkeit, sich schnell und einfach zu bewegen. In übertragenem Sinn findet das Wort auch für «agiles Denken» Anwendung, wo es für geistige Beweglichkeit steht.
Dieses Adjektiv darf nicht mit dem Wort «Agile» verwechselt werden. «Agile» bezeichnet ein Framework, welches im Wesentlichen auf den Aussagen des «Agilen Manifests» und der damit verbundenen zwölf Prinzipien beruht.

Zur Durchführung eines erfolgreichen Projektes, das «Agile» genannt werden kann, bedarf es dreier grundlegender Voraussetzungen: Zunächst wird das Projekt durch ein Team durchgeführt, welches nach dem «Agilen Manifest» arbeitet.

Für den Projekterfolg ist diese Bedingung aber in keiner Weise ausreichend. Vielmehr muss auch die Organisation, für die das «Agile Team» tätig ist, agiles Vorgehen zulassen. Dies ist in einer großen Zahl von Firmen, welche für sich reklamieren, agil zu arbeiten oder agile Frameworks wie «Scrum» einzusetzen, nicht der Fall. Eine Führung von agilen Teams kann niemals erfolgreich auf Basis von Befehl und Kontrolle erfolgen. Vielmehr bedeutet der Einsatz eines oder mehrerer selbst- organisierter und -verantwortlicher Teams einen Führungsstil, der stark auf «Empowerment» basiert. Dies bedeutet für viele Organisationen die Notwendigkeit eines Kulturwandels. Wenn dieser anhaltend ausbleibt, bleibt «Agiles Vorgehen» ein zahnloser Tiger und der erzielbare Nutzen äusserst beschränkt.

Management ist nichts anderes als die Kunst, andere Menschen zu motivieren.
Lee Iacocca, US-amerikanischer Manager

Schliesslich und endlich ist die Mitarbeit des Kunden und dessen Mittragen einer agilen Vorgehensweise ein weiterer, zentraler Erfolgsfaktor für Erfolg mit «Agile».

In vielen Fällen ist das Aufstellen von Anforderungskatalogen bei Kunden vom Wunsch geprägt, auf keinen Fall eine Funktion, welche während der Einsatzdauer der Software benötigt wird, zu vergessen und dadurch teure Nacharbeiten oder Zusatzprojekte zu verursachen. So entstehen oft riesige Kataloge von Anforderungen, welche zum aktuellen Zeitpunkt nicht benötigt werden und deren tatsächlicher Nutzen auch für die Zukunft höchstens im Bereich des Möglichen liegt. Viele entsprechend formulierte Anforderungen wurden entweder aus Anforderungsdokumenten anderer Firmen, von Branchenverbänden oder aus Sekundärliteratur übernommen. Da man den tatsächlichen Nutzen und zukünftigen Einsatz in vielen Fällen nicht wirklich bestimmen kann, werden die entsprechenden Anforderungen als «Muss-Kriterien» gesetzt, über deren Umsetzung es «nichts zu diskutieren» gibt.

Die 45% Herausforderung

Einsatz von Komponenten in Software-Systemen

Einsatz von Komponenten in Software-Systemen

So verwundert es nicht, dass die Standish Group in einer Analyse von 2000 Entwicklungsprojekten bei 1000 Firmen zum Resultat kam, dass 45% der umgesetzten Funktionalität niemals und weitere 19% nur sehr selten genutzt wird. Diese Funktionalitäten wurden von Analysten analysiert, von Entwicklern umgesetzt und dokumentiert, von Testern geprüft, im Rahmen der Projektabnahme vom Kunden geprüft und sie werden im Rahmen von Wartungsverträgen laufend weiterentwickelt, weiter dokumentiert und weiter getestet. Damit wird nicht nur ein einmaliger Entwicklungsaufwand, sondern auch laufender Wartungs- und Pflegeaufwand verursacht.

Im Gespräch mit Kunden hört man bei Nachfragen oft Aussagen wie «Es ist ja ein Festpreisangebot – also setzen Sie das einfach um».

Die Anforderungen an den Kunden sind im Rahmen agiler Entwicklungen anders. Dies betrifft nicht nur das tatsächliche Vorgehen oder die Anforderung, sich für jeden Sprint mit dem Entwicklerteam im Rahmen eines Reviews zu treffen und Feedback zu geben. Die Anforderung betrifft die komplette Herangehensweise und das Mindset des Kunden. Um als Kunde optimal von einem Lieferanten zu profitieren, der nach Agile entwickelt, muss ich bereit sein, mich mit ihm gemeinsam auf eine «Entwicklungsreise» zu begeben, auf der beide mehr über das Projekt lernen. Darauf basierend erfolgt die laufende Anpassung und Weiterentwicklung des Entwicklungsproduktes.

Das funktioniert nicht, wenn im Entwicklungsvertrag 1000 Anforderungen als «Muss»-Kriterien festgeschrieben sind. Vielmehr muss der Entwicklungskunde bereit sein, mit seinem Lieferanten gemeinsam eine Vision zu entwickeln, was erreicht werden soll, und die wichtigsten Anforderungen – ohne deren Umsetzung das Projekt keine Rechtfertigung hat – zu definieren und im Rahmen der Beauftragung festzuhalten. Die weitere Entwicklung wird im Rahmen des Projektes auf der Basis eines iterativen Vorgehens, basierend auf Kundenfeedback, realisiert. Ziel ist dabei, den optimalen Nutzen für den Kunden zu realisieren und dabei auf sinnlose Funktionen (z.B. die genannten 45%) zu verzichten.

Agiles Projektvorgehen

Der agile Entwicklungsprozess ist ein iterativer, inkrementeller Prozess, der durch das Kundenfeedback gesteuert wird.

Iterativ meint, dass der Prozess in einer Abfolge einzelner, vollständiger Entwicklungszyklen durchgeführt wird, von denen jeder sämtliche Phasen von Planung-Entwicklung-Integration-Test-Feedback durchläuft. Dabei soll in jeder Iteration ein fertiges Produkt entstehen, welches in Absprache mit dem Kunden auch ausgeliefert werden könnte.

Inkrementell meint ein Vorgehen, bei dem jeder neue Entwicklungsumgang das Produkt der vorangegangenen Iteration erweitert. Es werden nicht separate Liefergegenstände entwickelt, sondern ein Produkt, welches mit jeder Iteration mehr Gestalt annimmt und mehr Kundennutzen bringt.

Der ganze Prozess wird durch das Feedback des Kunden gesteuert, das basierend auf den Resultaten einer Iteration abgegeben wird. Damit entwickelt sich das Projekt basierend auf den gemeinsam in der Realisierung erzielten Lernerfolgen und kann innerhalb kürzester Zeit auf geänderte Rahmenbedingungen und Anforderungen seitens des Kunden reagieren. Planung erfolgt «Just in time» – genau dann, wenn sie auch Nutzen bringt und die notwendigen Informationen vorliegen.

Zusammenfassung

  • Agiles Projektvorgehen unterscheidet sich von herkömmlichen Prozessen dadurch, dass Planung nicht zu Projektbeginn, sondern laufend stattfindet.
  • Iterative Entwicklung, bei der in übersichtlichen Anforderungsportionen geplant, umgesetzt, getestet und in vielen Fällen auch an den Kunden ausgeliefert wird, ermöglicht es dem Kunden, frühzeitig Feedback zu geben und so Fehlentwicklungen und Missverständnissen frühzeitig zu begegnen. Im besten Fall kann schon frühzeitig Nutzen realisiert werden.
  • Im Rahmen inkrementeller Software-Entwicklung wächst die entwickelte Lösung im Rahmen jeder Iteration weiter. Damit wird sichergestellt, dass Entwicklungsprodukte immer in den Gesamtkontext integriert werden.

Praxistipp
Der Einsatz eines agilen Frameworks wie beispielsweise Scrum, Kanban, DSDM, SAFe oder auch andere bietet ein grosses Potential für effektive und effiziente Produktentwicklung. Um diese positiven Effekte wirklich nutzen zu können, ist es notwendig, dass sowohl das firmeninterne Umfeld als auch die Bereitschaft des Kunden, ein agil durchgeführtes Projekt mitzutragen, gegeben ist. Es ist wichtig, dass entsprechendes Wissen und die Bereitschaft, sich auf «Agilität» einzulassen, sowohl innerhalb des eigenen Managements als auch beim Kunden aufgebaut wird, soweit dies nicht bereits ohnehin vorhanden ist. Wo die passenden Rahmenbedingungen (sowohl intern als auch beim Kunden) nicht gegeben sind, bleibt der Nutzen agilen Projektvorgehens fraglich und man sollte sich fragen, ob er sinnvoll ist.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.