Ein Hausbau ist komplex? Softwareentwicklung ist komplexer. Meistens jedenfalls. Das liegt nicht nur daran, dass zahlreiche Schnittstellen, verschiedene Endgeräte und die Anforderungen unterschiedlichster Stakeholder zu berücksichtigen sind. Zu allem Überfluss verändert sich all das auch noch ständig und in einer solchen Geschwindigkeit, dass so manches klassisch entwickelte Softwareprojekt schon beim Launch veraltet ist. Oder gar nicht erst fertig wird, wie zum Beispiel das groß angelegte FISCUS-Projekt der Finanzbehörden, das 2006 nach 13-jähriger Entwicklungszeit abgebrochen werden musste. Als Antwort auf diese Herausforderung hat sich in den vergangenen Jahren die agile Softwareentwicklung etabliert. Im Unterschied zur klassischen Wasserfall-Methode, die an den Anfang der Entwicklung lange Konzeptphasen und dicke Lasten- und Pflichtenhefte setzt, arbeitet agile Softwareentwicklung flexibel und in iterativen Schritten, für die überschaubare, gut abgegrenzte und schnell umsetzbare Komponenten identifiziert und geplant werden. Auf dieser Unterscheidung aufbauend hat sich in der Unternehmenspraxis zuletzt eine agile Methode besonders durchgesetzt, die diese kurzfristige Planung in den Mittelpunkt stellt und daraus ein recht enges Modell ableitet: Scrum.

Scrum und agile Softwareentwicklung: Ist das dasselbe?

Klare Antwort: Nein.

Das in den 1990ern entwickelte Scrum-Modell gab es schon lange, bevor 17 Entwickler 2001 in einem Skihotel in den Bergen von Utah das Agile Manifest verfassten und damit der neuen Art, Software zu entwickeln, einen Namen gaben. Neben Extreme Programming, Pragmatic Programming oder DSDM gehörte Scrum dabei zu den Methoden, aus deren Erfahrungsschatz die Grundprinzipien der agilen Softwareentwicklung abgeleitet wurden. Zu diesen Grundprinzipien zählt das Reagieren auf Veränderungen ebenso wie die enge Zusammenarbeit mit dem Kunden und die Interaktion zwischen Menschen. All dies sind eher Orientierung vermittelnde Werte und Prinzipien. Scrum hingegen basiert auf einem recht fixen Modell. Vermutlich ist genau das der Hauptgrund, warum sich Scrum in vielen Unternehmen geradezu als Synonym für Agile Softwareentwicklung durchgesetzt hat. Denn sich an konkreten Modellvorgaben entlangzuhangeln ist häufig schlicht einfacher, als abstrakte Werte umzusetzen.

Was ist agile Softwareentwicklung denn dann?

Im Kern ist agile Softwareentwicklung eigentlich ein Baukasten und eine Inspirationsquelle. Ihr Prinzip regt dazu an, einmal eingeschlagene Wege nicht diskussionslos bis zum bitteren Ende zu verfolgen, sondern sie regelmäßig zu hinterfragen und bei Bedarf anzupassen. Das gilt aber nicht nur für funktionale Softwareanforderungen oder gar den dahinterstehenden Code, sondern auch für Methoden, Vereinbarungen und Zuständigkeiten. Agile Softwareentwicklung ist also keine klar definierte Methode, sondern ein Set von Werten und sehr elementaren Konzepten.

Passt Scrum überhaupt zu den Werten der agilen Softwareentwicklung?

Richtig eingesetzt, ist Scrum eine sehr gut geeignete Methode, um komplexe Softwareprojekte erfolgreich zu bewältigen. Wenn dabei dennoch Probleme entstehen, liegt das weniger am Modell selbst, sondern am praktischen Umgang damit. Denn was viele Unternehmen angesichts der Modellhaftigkeit des Scrum-Konzepts schnell vergessen, ist, dass agile Softwareentwicklung nicht ohne Flexibilität funktioniert. Und dass diese Flexibilität eben auch auf das Scrum-Modell angewendet werden sollte, wenn das Ziel darin besteht, wirklich agile Prozesse zu etablieren. Einer klassischen Abteilungsstruktur ein starres Scrum-Modell überzustülpen, löst keine Probleme. Im schlimmsten Fall werden sie dadurch sogar größer. Scrum setzt voraus, dass Softwareentwicklung und angrenzende Rollen sich nach Themen organisieren. Bei einem Online-Shop kann dies zum Beispiel eine Abgrenzung zwischen Produktseiten und Bezahlprozess sein. In vielen Organisationen ist es jedoch so, dass zwar die fachlich Verantwortlichen, etwa Produktmanager, thematisch (vertikal) organisiert sind, die weiteren Rollen aber nach technischen Gesichtspunkten “horizontal” verteilt werden (z. B. UX, UI, Frontend und Backend). Dies führt zwangsläufig zu Reibung und Effizienzverlusten.

Wann ist Softwareentwicklung agil?

Um zu verstehen, was agile Softwareentwicklung tatsächlich ausmacht, lohnt es sich, noch einmal einen Blick in das oben genannte Agile Manifest zu werfen. Denn die Verfasser haben die entscheidenden Eigenschaften agiler Organisationen sehr präzise auf den Punkt gebracht:

Individuen und Interaktionen (vor Prozessen und Werkzeugen)

Im Mittelpunkt der agilen Softwareentwicklung steht nicht die Software, sondern der Mensch. Gegenseitige Unterstützung, gemeinsamer Wissensaufbau und transparente Kommunikation bilden die Basis agiler Teams. Durch Methoden wie Pair Programming und klares Commitment auf gemeinsame Coding- und Dokumentationsstandards wird es möglich, Zuständigkeiten nicht personenabhängig, sondern teamweise zu definieren und dadurch den Druck vom einzelnen Teammitglied zu nehmen. So gelingt es auch bei Krankheit oder in der Urlaubszeit, auch schwierige Situationen gut zu meistern.

Funktionierende Software (vor umfassender Dokumentation)

Natürlich werden auch agile Softwareprojekte dokumentiert – alleine schon, um sie für alle Teammitglieder nachvollziehbar und zugänglich zu machen. Wichtiger als ein dickes Lastenheft, in dem meist nur theoretische Anforderungen fein säuberlich dokumentiert sind, ist aber eine funktionierende Software. Deshalb werden agile Softwareprojekte in kleine Komponenten aufgeteilt, die sich schon nach kurzer Zeit testen und sogar direkt einsetzen lassen. Zum Beispiel braucht ein Endkundenprodukt nicht immer in der allerersten Version eine effiziente Verwaltungsoberfläche für den Anbieter, so dass sich diese Komponente in einen zweiten Schritt realisieren lässt. Auf diese Art stellt sich schon früh im Projekt heraus, ob die Anforderungen für die jeweilige Einzelkomponente richtig umgesetzt wurden und das Ergebnis in der Praxis funktioniert.

Zusammenarbeit mit dem Kunden (vor Vertragsverhandlung)

Echte agile Softwareentwicklung ist bei Kunden manchmal unbeliebt, weil sie ihnen mehr abverlangt. Mehr Mitdenken, mehr Umdenken und nicht zuletzt mehr Zeiteinsatz. Denn im Unterschied zur klassischen Wasserfall-Methode, in der der Kunde am Anfang einmal seine Anforderungen niederschreibt und das Projekt dann in die Hände des IT-Dienstleisters gibt, bezieht agile Softwareentwicklung den Kunden über den gesamten Entwicklungsprozess hinweg mit ein. Auch wenn dieses Vorgehen nach mehr Aufwand aussieht, zahlt es sich immer aus, denn der Markt nimmt Lösungen aus der Praxis viel besser an und das Ergebnis entspricht genauer dem, was der Kunde tatsächlich braucht. Kunden sind meist keine IT-Experten - was kostengünstig, passgenau und effizient in der Nutzung ist, findet man nur gemeinsam heraus. So braucht die interne Produktverwaltung möglicherweise eine gänzlich andere Suchfunktion als der Online-Shop. Und es kann sich auch im 21. Jahrhundert lohnen, eine Anwendung auf die Bedienung mit der Tastatur zu optimieren, wenn sehr viele Eingaben nötig sind und ein kleiner Nutzerkreis die Anwendung intensiv einsetzt. Pauschale gute Lösung gibt es nicht - jedes Projekt ist einzigartig.

Reagieren auf Veränderung (vor dem Befolgen eines Plans)

Pläne sind gut. Allerdings nur solange, wie sie auch zur Wirklichkeit passen. Wenn sich Markt- oder Wettbewerbsbedingungen ändern, neue Technologien am Horizont heraufziehen oder Kunden plötzlich ganz neue Erwartungen haben, können zu starre Pläne ein massives Erfolgshindernis sein. Agile Softwareentwicklung zeichnet sich dadurch aus, dass sie flexibel auf Veränderungen reagieren kann. Egal, ob diese von außen oder von innen kommen – zum Beispiel, wenn sich während der Entwicklung neue Abhängigkeiten oder andere technische Anforderungen ergeben. Softwareprojekte, die über mehrere Jahre auf ein vorher definiertes Ziel hinarbeiten, arbeiten fast zwangsläufig an der Wirklichkeit vorbei, denn die Welt dreht sich weiter und mit ihr verändern sich auch die Anforderungen.

Also alles planlos?

Nein, natürlich nicht. Wie gesagt: Pläne sind gut. Und einfach drauflos zu programmieren, führt wohl nur in den seltensten Fällen zum Erfolg. Unserer Erfahrung nach ist eine mittelfristige Planung für agile Softwareprojekte am besten geeignet. Sich vom Scrum-Guide auf zweiwöchige Sprints festnageln zu lassen, kann sich schnell wie ein zu enges Korsett anfühlen. Ein kleines Projekt zu definieren, das über 3 bis maximal 6 Monate läuft, und an dessen Ende ein MVP (Minimal Viable Product), also die Minimalvariante eines Produktes steht, hat sich in unserer Entwicklungserfahrung als sehr effizient erwiesen. Was nicht bedeutet, dass der Kunde 3 Monate lang nichts von uns hört – natürlich wird er in die Zwischenstände mit einbezogen und hat meist nach 2 Monaten schon fast alles gesehen, bevor es dann in den Feinschliff geht.

Die größten Vorteile solcher Einzelprojekte mit kurzer Laufzeit: Sie bergen ein geringes Risiko, bringen schnelle Resultate bei überschaubaren Investitionen und holen dadurch auch das Management schnell an Bord.

Der goldene Mittelweg

Mit Methoden aus der agilen Softwareentwicklung lassen sich auch komplexe Softwareprojekte sehr gut handhaben. Agil zu arbeiten muss aber nicht bedeuten, dass man sich vom aktuellen Scrum-Hype in ein zu kleinteiliges Konzept zwängen lässt. Wer Scrum nicht als Dogma, sondern als inspirierenden Baukasten an Möglichkeiten sieht, kann tatsächlich alle Vorteile des agilen Arbeitens nutzen und auf die Nachteile einfach verzichten. Dann wird Softwareentwicklung durch agile Methoden tatsächlich besser – motivierender für die Mitarbeiter, erfolgreicher für den Kunden und effizienter im Ergebnis. Wie so oft liegt das Glück deshalb auch hier in der goldenen Mitte: Projekte inspiriert von Scrum kleinschrittig und flexibel zu planen und auf einem so erarbeiteten Grundstein dann sukzessive weiter aufzubauen, hat sich in unserer Praxis sehr bewährt. 3-Monats-Zyklen liefern dabei erfahrungsgemäß genau den richtigen Rahmen, damit sich alle Beteiligten genau nach ihren Vorstellungen einbringen können. Das Management kann die Richtung vorgeben, ohne sich mit den vielen Details beschäftigen zu müssen. Der Produktmanager hat die Möglichkeit, innerhalb der Zyklen selber zu steuern und Entscheidungen zu treffen. Und wir als Dienstleister können unser Know-how und unsere Erfahrung einbringen, um Details gemeinsam mit dem Produktmanager zu gestalten‥

So kann Zeit, die sonst in unnötigen Abstimmungen über viele Ebenen verloren geht, konstruktiv dort genutzt werden, wo die Fähigkeiten aller Projektbeteiligten am effizientesten wirken. Selbst bei einem umfangreichen Entwicklungs-Marathon kann es auf diese Weise gelingen, Rekordzeiten zu erzielen, und dabei mit einem zufriedenen, ausgeglichenen Team die Ziellinie zu überqueren.

Dr. Katja Flinzner & Pablo Beyen