Scrum, Kanban und Lean sind, zumindest in der Softwareentwicklung, die Vorgehensmodelle der Stunde. Wer heute nach klassischer Wasserfallmethodik entwickelt, hat die Zeichen der Zeit verschlafen - so scheint es. Viele namhafte Unternehmen haben ihre über Jahrzehnte eingesetzten Verfahren umgestellt oder sind dabei wie etwa BMW. Sogar in klassisch geprägten Branchen wie zum Beispiel dem Finanzsektor sind Scrum- und Kanban-Projekte auf dem Vormarsch.

Ist dieser Hype rund um "agil" begründet oder werden wir irgendwann eher nüchtern auf die aktuelle Phase zurückblicken?

Um die Frage zu beantworten, lohnt sich ein Blick auf die Beweggründe für die Entwicklung von Scrum und Co. und damit auf die negativen Erfahrungen, welche oftmals mit der klassischen Wasserfallmethodik und den darauf aufbauenden Unternehmens- und Projektstrukturen einhergehen.

Dokumentation vor Software

Bevor in einem Wasserfall-Projekt die erste Zeile Code entsteht, werden umfangreiche Konzepte geschrieben, diskutiert, reviewed, geändert und wieder reviewed bis zur Abnahme - des Dokuments wohlgemerkt.

Leider krankt dieses Verfahren erstens daran, dass es Fachbereichsmitarbeitern schwerfällt, eine Anwendung detailliert mit Worten zu beschreiben, und zweitens sind notwendige Änderungen der Anforderungen während der Realisierungsphase zu erwarten, sodass die spätere Software zwar dem Konzept, aber nicht unbedingt den Bedürfnissen der Benutzer entspricht.

In agilen Projekten liegt der Fokus auf dem zu erstellenden System. Die Anforderungsbeschreibungen sind kurz und knapp aus Anwendersicht formuliert und im Rahmen eines Backlogs priorisiert. Potenzielle fachliche oder technische Änderungen fließen stetig in die früh beginnende Entwicklung ein. Mit jeder Iteration (Sprint) entsteht ein Stück System, das von den Stakeholdern bewertet und gegebenenfalls korrigiert werden kann. Auf diese Weise verliert das für SW-Projekte typische "Moving Target" seinen Schrecken; Änderungen führen nicht zu umfangreichen Change Requests mit den damit zwangsläufig verbundenen Kosten.

Horizontale Schnitte

Ein auch heute noch beliebtes Modell für klassische Projektorganisationen ist die Teilung der Teams analog der Schichten der zu erstellenden Anwendung, in beispielsweise Frontend, Business Funktionen und Backend (sogenannter horizontaler Schnitt). Neben den meist ohnehin anzubindenden benachbarten Systemen resultieren zusätzliche Schnittstellen zwischen den Teams und deren Code. Dadurch sind nicht nur unnötige Abstimmungen, sondern auch aufwändige Integrationsmaßnahmen erforderlich. Die Projekte dauern zwangsläufig länger und haben mit Qualitätsproblemen zu kämpfen.

In einem nach Scrum-Methodik durchgeführten Projekt sind die Teams crossfunktional organisiert, das heißt alle für die Realisierung der SW benötigten Rollen sind vertreten (vertikaler Schnitt) - idealerweise an einem Ort und in einem gemeinsamen Projektraum, sodass die Kommunikation vereinfacht wird.

Darüber hinaus existieren aufgrund der Entwicklung der fachlichen Anforderungen gleichzeitig über alle Schichten keine zusätzlichen Schnittstellen; jedes Inkrement der Anwendung ist lauffähig und testbar.

Späte Integration

In klassischen Projekten erfolgen die Integration und der Test über alle Module und Systeme in einem Abschnitt gegen Ende der geplanten Zeit. Erst dann zeigt es sich, ob die Absprachen mit Schnittstellenpartnern eingehalten wurden. Oftmals werden die Komplexität und der zeitliche Aufwand für diese Phasen maßgeblich unterschätzt.

Eine Maxime der agilen SW-Entwicklung ist es, mit jeder Iteration (Sprint) ein potenziell lieferfähiges Produktinkrement zu erhalten. Das impliziert die frühe Integration mindestens über alle Bestandteile des eigenen Projektes. Idealerweise werden auch Partnersysteme frühzeitig in die Realisierung einbezogen und miteinander getestet. Diese Arbeiten zeigen Probleme und Schwachstellen rechtzeitig auf und verhindern Überraschungen gegen Projektende.

Zu wenig Zwischenziele

In einem Wasserfallprojekt werden Meilensteine meist entlang der Phasen Konzeption, Design, Realisierung, Test und Abnahme definiert, auch wenn diese weit auseinander liegen. Neben der Problematik, dass im Zuge dessen erst spät Software entsteht, führen Meilensteine in einer eher fernen Zukunft zum Verlust des Fokus.

Es liegt in der Natur des Menschen, dass er sich auf kurzfristige Ziele konzentriert und sich dabei gerne in Details verliert, während das große Ganze außer Acht gerät. Je weiter Meilensteine auseinander liegen, desto größer ist die Wahrscheinlichkeit, dass gegen Ende Wesentliches fehlt und die Zeit knapp wird.

Bei einem Scrum-Projekt liegt der nächste Meilenstein maximal eine Sprintlänge in der Zukunft - mit klarem Fokus auf die Umsetzung und Validierung der vereinbarten fachlichen Funktionen (User Stories). Umfangreichere Produktinkremente werden in größeren Abständen synchron zum Sprintraster definiert, sodass diese Zwischenziele einen zusätzlichen Anreiz bilden.

"Agil" ist kein Wundermittel!

Angesichts derartiger Vorteile ist in der Tat ein Wechsel von Wasserfall zu Scrum,Kanban oder ähnlichen Methoden zu empfehlen. Doch Vorsicht! Agil zu arbeiten bedeutet nicht, die Grundprinzipien der professionellen Softwareentwicklung zu vernachlässigen. Wesentliche Aspekte müssen weiterhin Beachtung finden, um unliebsame Konsequenzen zu vermeiden.

Fachliche Prozesse definieren und berücksichtigen

Auch wenn in einem agilen Projekt Beschreibungen kurz und knapp sein sollten, ist es von entscheidendem Vorteil, Prozessdokumentationen zu erstellen und hieraus die Anforderungen in Form von Epics, Features und User Stories abzuleiten.

Insbesondere bei komplexen Vorhaben verhindert diese deduktive Vorgehensweise die Entwicklung von potenziell überflüssigen Systembereichen und sorgt für die Integrations- und Ablauffähigkeit auch über mehrere Anwendungen hinweg.