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.
- Kleines Scrum-Glossar
Was meint eigentlich Scrum, Product Owner oder Backlog? Wir stellen Ihnen die wichtigsten Begriffe und ihre Bedeutung vor. - Scrum
Der Begriff stammt aus dem Rugby und bedeutet wörtliche "Gedränge". In der Softwareentwicklung bezeichnet er ein Vorgehensmodell der agilen Softwareentwicklung, das 1995 von Ken Schwaber, Jeff Sutherland und Mike Beedle veröffentlicht wurde. - Das Scrum-Team
Aufgabe des Teams ist es, die Anforderungen der Fachabteilung umzusetzen. Es bietet drei Rollen: - 1. Rolle: Product Owner
Er vertritt den Auftraggeber, also die fachliche Seite. Also zeichnet er für die Priorisierung der Anforderungen verantwortlich und letztlich auch für den Nutzen, den das Projekt dem Unternehmen bringt. - 2. Rolle: Scrum-Master
Er ist quasi der Herr über die Prozesse. Er sorgt dafür, dass die Scrum-Regeln im Projekt eingehalten werden, er fördert die Transparenz, unterstützt das Team bei der Beseitigung von Hindernissen und sucht ständig nach möglichen Verbesserungen. - 3. Rolle: Die Entwicklergruppe
Sie besteht idealerweise aus sieben Entwicklern. - Sprint
Mit diesem Begriff bezeichnet Scrum einen Iterationszyklus, innerhalb dessen ein Scrum-Teams eine Anforderung umsetzt. Ein Sprint dauert mindestens zwei Wochen und maximal einen Monat. - Backlog
So heißt in Scrum die priorisierte Anforderungsliste für das zu entwickelnde Produkt. Sie wird vom Product Owner verantwortet und gepflegt. - Definitionen von fertig
Dabei handelt es sich um die Kriterien, unter den ein Produkt als umgesetzt akzeptiert wird.
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.
- Schneller als Plan-Build-Run
Die Anforderungen an Software verändern sich im Laufe der Entwicklung oft erheblich - anders als bei einem Auto zum Beispiel. Dem tragen agile Methoden wie Scrum Rechnung. - Besseres Ineinandergreifen
Bei traditioneller Softwareentwicklung greifen Zahnräder oft nicht ineinander, sondern sie rotieren nebeneinander vor sich hin. Scrum sorgt für nahtlosere Prozesse. - Jeder spricht mit jedem
Bei vielen Softwareprojekten mangelt es an gelungener Kommunikation, bei Scrum ist regelmäßiges Feedback für alle Beteiligten Pflicht. - Mehr Qualität
Mit Hilfe von Scrum entwickelte Software ist in der Regel besser als andere, weil hier frühzeitig das Feedback der Kunden integriert wurde. - Chaos führt nicht zu Panik
Chaotisch ist Scrum insofern, als sich der damit verbundene Prozess nicht einfach mit einem Pfeil beschreiben lässt, der links auf dem Blatt Papier anfängt und irgendwo rechts aufhört. Sondern er ist mehrdimensional. Wenn sich alle an bestimmte Regeln halten, läuft trotzdem nichts aus dem Ruder. - Im Mittelpunkt: Der Mensch
Scrum heißt Gedränge. Und es bedeutet, den Menschen in den Mittelpunkt zu stellen in dem Sinne, dass ihm die Methode ermöglicht, effizient und gleichzeitig kreativ zu arbeiten. - Automatisierte Tools statt Selbstgestricktes
Oft verwendet jede Abteilung eigene Anwendungen, um Entwicklungsschritte zu dokumentieren, zum Beispiel Excel. Automatisierte, vor allem einheitliche Tools beschleunigen hier die Abläufe erheblich. - Nicht nur am Ende testen
Zeitgemäße Entwicklungsumgebungen erlauben es, auch einzelne Module zwischendurch zu testen, um immer auf dem neuesten Stand zu sein.
"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.