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.
Foto: Gorodenkoff - shutterstock.com
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.
Fokussierung auf das Wesentliche statt Goldene Henkel
Eine Möglichkeit herauszufinden, ob eine fachliche Funktion oder ein ganzes System nützlich sein könnte, ist die Beschreibung und die Kalkulation des Business Case. Bei einzelnen Anforderungen im Sinne eines Eintrags im Backlog genügt oftmals die Kategorisierung in T-Shirt-Größen (S, M, L, XL) und die Erkenntnis des Product Owners, auf welche Funktionen er/sie gegebenenfalls verzichten muss, weil Zeit und/oder Budget ausgereizt sind.
Bei umfangreicheren Themenstellungen hilft den Stakeholdern die Gegenüberstellung der konkreten Kosten bei Realisierung der Anforderung oder Aufrechterhaltung des Status quo. Bei Letzterem sind unbedingt die Prozesskosten zum Beispiel für Personal bei manuellen Tätigkeiten zu berücksichtigt.
Performance früh im Fokus behalten
Eine nicht nur in agilen Projekten gerne vernachlässigte nicht-funktionale Anforderung betrifft die Performance des zukünftigen Systems. Es ist keine gute Idee, erst kurz vor dem geplanten Livegang Last- und Performancetests durchzuführen.
Unter Umständen sind beachtliche Aufwände für Korrekturen erforderlich, weil Basisbereiche, zum Beispiel Datenbankzugriffe/Datenmodelle, angepasst werden müssen und dies Auswirkungen auf weite Teile des Systems hat. Daher ist eine frühzeitige Betrachtung von Last- und Performanceaspekten inklusive prototypischer Realisierungen angeraten.
Migrationsarbeiten berücksichtigen
Die Mehrheit der heutigen Software-Projekte löst Legacy-Systeme durch moderne Implementierungen ab. Die meist über Jahre oder Jahrzehnte entstandenen Daten werden in den seltensten Fällen nicht mehr benötigt, sondern sind in die neue Welt zu migrieren. Auch hier ist es sinnvoll, frühzeitig mit den Arbeiten zu beginnen.
Diese sind nicht nur technisch durch die Datenbank getrieben; vielfach beeinflusst die Migration die fachliche Realisierung und umgekehrt. Um in agilen Projekten der Volatilität der entstehenden Systeme Rechnung zu tragen, können ETL-Werkzeuge (Extract, Transform, Load) hilfreich sein. Dabei werden Transformationslogiken grafisch modelliert, welche im Bedarfsfall relativ einfach anpassbar sind.
Personal dediziert einsetzen
Der Mensch ist nachweislich nicht für Multitasking-Tätigkeiten geeignet. Zwar mögen Frauen diesbezüglich über evolutionsbedingte Vorteile gegenüber Männern verfügen. Sicher ist, dass beide Geschlechter schnellere und bessere Ergebnisse erzielen, wenn sie sich auf eine Aufgabe konzentrieren können.
Viele Firmen neigen jedoch dazu, ihre Mitarbeiter aufgrund von Ressourcenengpässen und Kopfmonopolen gleichzeitig in mehreren Projekten zu platzieren - mit entsprechend negativen Konsequenzen. Bei dediziert eingesetztem Personal dankt es jeder Einzelne mit größerer Zufriedenheit und höherer Motivation, wovon nicht nur das Projekt, sondern das ganze Unternehmen profitiert.
Fazit
Um die eingangs gestellte Frage zu beantworten: Ja, der Hype um agile Vorgehensmodelle ist absolut begründet und eine Umstellung ist rentabel, wenn man nicht allein auf die Methode vertraut, sondern weiterhin die Grundsätze professioneller Softwareentwicklung berücksichtigt.
Unternehmen, die mit dem Gedanken zur Umstellung ihrer Projektprozesse spielen, sollten sich bewusst sein, dass die Einführung von Scrum und Co. für viele Menschen einen ausgeprägten kulturellen Wandel zur Folge hat, der nicht von heute auf morgen vollzogen werden kann (siehe auch: Radikales Umdenken nötig).
Entgegen der klassischen Methoden bedeutet agiles Arbeiten mehr Eigenverantwortung, Selbstorganisation, ständige Reflexion und vor allem Transparenz bezüglich der Tätigkeiten jedes einzelnen und das zu jeder Zeit. Wer dies in seinen Projekten berücksichtigt und die Menschen aktiv an den Change-Prozessen beteiligt, wird mit zufriedeneren Mitarbeitern und besseren Projektergebnissen belohnt. (hal)