Warum rein agile Softwareentwicklung nicht die Lösung für die meisten Softwareprojekte ist

... und Sie Ihre eigene hybride Projektmanagement-Methode entwickeln sollten

Heutzutage scheint es so, als ob bei Softwareprojekten nur noch zwischen zwei Methoden unterschieden wird: entweder die Arbeitsweise ist „agil“ oder nicht. Wenn Fragen zum Vorgehensmodell gestellt werden, ist die Argumentation häufig, dass „agil“ oder „nicht agil“ gearbeitet wird und deshalb die Arbeitsweise so ist, wie sie ist. Kurz gesagt, es entsteht der Eindruck als gäbe es lediglich zwei exklusive Arten des Projektmanagements in der Softwareentwicklung – „agil“ (oft Scrum) oder den Gegensatz „nicht agil“ (oft Wasserfall oder V-Modell).

Im Folgenden wird dargelegt, warum dies nicht stimmt und warum es wichtiger ist, die Methoden zu verstehen, um einen wahren Mehrwert aus einem projektspezifischen Management zu generieren. Abschließend erwartet Sie ein Lösungsvorschlag (Blaupause), der für die meisten Softwareprojekte geeignet sein dürfte (Phased Scrum).

Agile Softwareentwicklung

Schon vor der COVID-19-Pandemie war die agile Softwareentwicklung ein heiß diskutiertes Thema. Zahlreiche auf Agilität basierende Konzepte sind entstanden. Zu den bekanntesten zählen Extreme Programming (XP), Scrum, Scrumban und (Biz)DevOps.

Doch was bedeutet agile Softwareentwicklung eigentlich?

Was ist agile Softwareentwicklung

Agile Softwareentwicklung wurde durch das Manifest für agile Softwareentwicklung von 2001 ins Leben gerufen. Wird das Manifest aufmerksam studiert und der Inhalt kategorisiert, so lassen sich die folgenden Cluster erkennen:

1. Ermitteln, was zu lösen oder zu erfüllen ist.
2. Herausfinden, was zu entwickeln ist.
3. Entwickeln der richtigen Lösung, indem stets ein Mehrwert geschaffen wird.
4. Selbstorganisation, um die Punkte eins bis drei kontinuierlich umzusetzen.
5. Einige konkrete Entwicklungsinhalte.

Es fällt auf, dass sich diese Grundsätze nicht auf die eigentlichen Entwicklungstätigkeiten fokussieren. Vielmehr beschreiben diese die Schritte vor der Programmierung. Es geht darum, stetig herauszufinden, was es zu lösen gilt und folglich, was entwickelt werden muss. Daraus lässt sich ableiten, dass es bei der agilen Entwicklung vor allem um die Ermittlung und nicht um die eigentliche Entwicklung geht.

Warum liegt der Fokus auf der Ermittlung?

Der Grund zeigt sich, wenn das Wasserfallmodell betrachtet wird. Das Wasserfallmodell ist ein lineares (nicht iteratives) Prozessmodell. Die Struktur basiert auf vordefinierten Phasen, die in einer verbindlichen Reihenfolge durchlaufen werden müssen. In der Praxis wird das Modell durch Rückkopplungen in frühere Phasen erweitert. Diese Sprünge sollten jedoch minimiert werden und sind nicht Teil des eigentlichen Konzepts. Der Grundgedanke dieses Konzepts ist, dass sich mögliche Fehler durch eine genaue Planung vermeiden lassen. Das Wasserfallmodell lässt sich wie folgt skizzieren:

Wie Mohandas K. Gandhi sagen würde: „Ich denke, es wäre eine gute Idee“. Er verweist darauf, dass zwischen Theorie und Praxis Welten liegen können. Unter der Voraussetzung einer optimalen Planungsfähigkeit würde diese Methode funktionieren. Doch in der Praxis ist diese Voraussetzung oft nicht gegeben. Komplexität, Missverständnisse oder unvorhergesehene Ereignisse können diesen linearen und verbindlichen Entwicklungsprozess zerstören. Genau solche Ereignisse treten in Softwareprojekten häufig auf. Zudem pflanzen sich Fehler oftmals fort und führen zu versunkenen Kosten oder gar zum Scheitern des Projekts. Darüber hinaus fördert die Trennung verschiedener Verantwortungsbereiche (Abteilungen), die sich aus der strikten Phaseneinteilung ergibt, stark das Silo-Denken.

Im Folgenden ist das Wasserfallmodell auf eine praxisorientiertere Weise visualisiert:

Es wird deutlich, dass es bei diesem Modell an Interaktionen und Kooperationen zwischen den verschiedenen Parteien mangelt, die in den verschiedenen Phasen an der Entwicklung einer Lösung oder eines Produkts zusammenarbeiten. Genau hier kommt die Agilität ins Spiel. Um Missverständnissen, Komplexitäten und ungeplanten Ereignissen entgegenzuwirken, werden kleine Aufgabenpakete benötigt, die in kurzen Zeitabständen alle relevanten Bereiche und Parteien durchlaufen und folglich in direkten Feedbackschleifen resultieren. Mit diesem Ansatz kann schnell auf Hindernisse jeglicher Art reagiert werden. Auf diese Weise können die richtigen Lösungen in einer komplexen Welt, in der es ständig Missverständnisse gibt, entwickelt werden. Folglich sind dies Gründe für die agile Softwareentwicklung.

Extremistan

Wie die Kritik am Wasserfallmodell aufzeigt, ist Agilität in Softwareprojekten oft gefragt und notwendig. Außerdem sollte nicht verschwiegen werden, dass Unternehmen und Kunden zumeist nicht im Detail wissen oder fälschlicherweise zu wissen glauben, was sie eigentlich wollen. Kundenmeinungen können unpräzise oder fehlerhaft sein. Darüber hinaus kann es auch an methodischer Kompetenz im Projekt mangeln, hier schafft Agilität eindeutig Abhilfe.

Diese Punkte führen zur reinen (extremen) Agilität. Wenn zu Beginn des Projekts niemand weiß, was benötigt wird oder wie der Weg zum fertigen Produkt (Lösung) aussieht, kann es keine oder nur wenig Planung geben. In diesem Fall müssen die Anforderungen oder Entwicklungsaktivitäten während der Entwicklung ermittelt werden. Mit anderen Worten: Reine agile Softwareentwicklung ist das, was getan wird, wenn man nicht weiß, was man tut. Das folgende Video veranschaulicht die reine agile Softwareentwicklung sehr gut, indem es sich auf diese Ermittlung konzentriert:

Jedes Modell, ob agil oder klassisch, hat unterschiedliche Anwendungsfälle, in denen dessen Stärken zur Geltung kommen. Das Wasserfallmodell eignet sich für Projekte, die eher einen sich wiederholenden Prozess beschreiben. Der repetitive Bau von Einfamilienhäusern eignet sich exemplarisch sehr gut für ein Wasserfall-Projektmanagement. Reine Agilität ist die Lösung, um etwas zu realisieren, das extrem komplex oder anfangs schwer zu definieren ist. Im Grunde genommen handelt es sich bei diesen beiden Anwendungsfällen um zwei Extrempunkte. Die meisten Projekte liegen jedoch zwischen diesen beiden Extremen.

Wie eingangs erwähnt, macht es manchmal den Anschein, als gäbe es nur „agil“ und den Gegensatz „nicht agil“ – also nur zwei Möglichkeiten, wie ein boolesches Attribut. Das Problem mit diesem Schubladendenken ist, dass je nach Methode entweder alles starr oder sehr wenig geplant wird. Ich habe Softwareprojekte gesehen, die dem Scrum-Modell folgen und sich weigern, eine langfristige Planung durchzuführen. Oft wird argumentiert, dass eine langfristige Planung nicht in die agile Arbeitsweise passt und nicht klassisch entwickelt werden soll. In diesen Fällen wird oft der nächste Sprint im Detail geplant und die weiteren 2-3 Sprints werden grob nach der Reihenfolge der Product Backlog Items entworfen. Dennoch, die meisten Unternehmen, die so argumentiert haben, hätten von einer langfristigen Planung profitiert.

Die Notwendigkeit einer langfristigen Planung

Dwight Eisenhower hat gesagt: „Planung ist alles, der Plan ist nichts.“ Er meint damit, dass Pläne oft schon in dem Moment in dem sie erstellt werden veraltet sind. Wenn Pläne so schnell ihre Bedeutung verlieren, warum sollte überhaupt geplant werden? Eisenhower betont, dass der Wert der Planung in dem Verständnis und den Denkprozessen liegt, die bei den Menschen entstehen, die den Plan entwerfen. Genau dieses tiefgreifende Verständnis ermöglicht es ihnen, schnell und flexibel auf Veränderungen zu reagieren und sich dabei auf die relevanten Ziele und Rahmenbedingungen zu konzentrieren. An dieser Stelle sollte auch erwähnt werden, dass die Planung kein einmaliges Ereignis ist. Es handelt sich vielmehr um einen kontinuierlichen Prozess, der immer wieder angestoßen wird, wenn genügend neue Informationen zur Verfügung stehen. Im Grunde genommen ermöglicht dieser Planungsprozess den Teilnehmer*innen, auf agile Weise zu reagieren.

Je mehr man nach Plan arbeitet, desto mehr erhält man das, was geplant war, aber wahrscheinlich nicht das, was gebraucht wird. Diese Kritik am klassischen Projektmanagement bedeutet natürlich nicht, dass eine langfristige Planung nicht hilfreich oder unnötig für den Projekterfolg ist. Auf eine langfristige Planung zu verzichten, um agil arbeiten zu können, ist schlichtweg Unsinn. Kurz gesagt: Wenn etwas geplant werden kann, sollte es getan werden, doch es sei nicht strikt an der Planung festzuhalten, wenn neue Informationen zu einer besseren Lösung führen.

Lösungen, die sich weder abschätzen noch planen lassen, erfordern eine rein agile Softwareentwicklung. Daher stellt sich die Frage, warum die meisten nicht rein agilen IT-Projekte keine beginnende detaillierte Planung aufweisen. Natürlich gibt es das blinde Befolgen von Richtlinien wie bei Scrum etc., das eine detaillierte Planung zu Beginn eines Projektes verhindern kann. Dennoch ist der Vorteil einer durchdachten Planung so offensichtlich, dass dies eigentlich nicht der Grund für ihre Vernachlässigung sein sollte. Manchmal scheint es, als ob die rein agile Softwareentwicklung in den meisten Unternehmen nur eine Notlösung für andere Probleme darstellt.

Da Dwight Eisenhower bereits erwähnt wurde, noch ein kurzes Beispiel für einen solchen Workaround anhand der Eisenhower-Matrix. Die Eisenhower-Matrix unterscheidet in einer Vierfeldertafel zwischen wichtigen und dringenden Aufgaben. Was dringend ist, ist selten wichtig, vice versa. Außerdem sind in den meisten Unternehmen Überstunden vorzufinden. Dies deutet darauf hin, dass es mehr zu tun gibt, als innerhalb der regulären Arbeitszeit zu erreichen ist. Daraus lässt sich erschließen, dass der Schwerpunkt in den meisten Unternehmen auf dringenden Aufgaben liegt, wie z. B. täglichen Aktivitäten, Deadlines oder ungeplanten Aufgaben. Ferner ist es normal, dass sich die Menschen weniger um die Zukunft als um die Gegenwart kümmern. Folglich bleibt in den meisten Unternehmen wenig Zeit für wichtige und nicht dringende Aufgaben, wie z. B. echte Planung.

Wenn die Zeit für eine durchdachte Planung fehlt, ist die rein agile Softwareentwicklung zwar eine geeignete (passive), aber nicht optimale Lösung.

Dies ist jedoch nur ein Beispiel dafür, wie die rein agile Softwareentwicklung als Ausweg für ein ganz anderes Problem genutzt werden kann. Ein weiterer möglicher und häufig anzutreffender Grund ist das Missverstehen des eigentlichen Zwecks der Planung durch das Management. Wenn der Plan stets zu befolgen ist und Änderungen an diesem nur schwer durchzusetzen sind, ist es besser, keinen Plan zu erstellen, um anstrengende Auseinandersetzungen zu vermeiden. Kurz gesagt, wenn der tatsächliche Mehrwert der Planung nicht gelebt werden kann, besteht keine Notwendigkeit zu planen.

Phased Scrum – Eine mögliche Lösung für die meisten Softwareprojekte

Um eine praktische und geeignete Methodik für den Softwareentwicklungsprozess zu schaffen, müssen die Vorteile der verschiedenen Ansätze kombiniert werden. Je mehr Vorgehensmodelle bekannt und verstanden sind, desto besser wird eine geeignete Projektmanagementmethode für das individuelle und  einzigartige Projekt gefunden. Wenn dieses theoretische Wissen mit ausreichender praktischer Erfahrung kombiniert wird, kann ein echtes Projektmanagement entstehen. Die letzte Zutat bildet das Verständnis über die vorherrschenden Rahmenbedingungen, an denen sich das Projektmanagement orientieren sollte. So wie mit jedem Menschen individuell umzugehen ist, so muss auch mit jeder Unternehmenskultur unterschiedlich umgegangen werden.

Angenommen, es handelt sich um ein Umfeld, in dem die Werte des Servant Leadership gelebt werden, die am Projekt beteiligten Personen über ausreichend Erfahrung verfügen und die Ziele und Funktionalitäten der gewünschten Softwarelösung weitgehend bekannt sind. Wie sollte dieses Projekt gemanagt werden?

Um ein solches Projekt zum Erfolg zu führen, bietet sich die Phased Scrum Methode kombiniert mit Management by Objectives (MbO) Techniken an. Bei dieser Methode gibt es größere Phasen, in denen ein leicht angepasstes Scrum Verwendung findet. Im Grunde genommen wird Scrum als Untermethode innerhalb der geplanten Phasen eingesetzt. Abgesehen von der initialen Planungsphase sind die Phasen nicht mit den Phasen vom Wasserfallmodell vergleichbar. Dies liegt daran, dass die Phasen durch eine logische Anforderungsaggregation erzeugt werden und folglich nichts mit den abstrakten Phasen des Wasserfallmodells gemein haben. Da die Phasen aus aggregierten Anforderungen gebildet werden, können diese unterschiedliche Laufzeiten besitzen und sind immer projektspezifisch. Anders als beim Wasserfallmodell sind die geplanten Phasen nicht in Stein gemeißelt. Es ist nicht das Ziel, sie ständig zu verändern. Um jedoch den wirklichen Nutzen der Planung auszuschöpfen, müssen sie sich bei neuen Informationen leicht anpassen lassen.

Erste Planungsphase

Um die Vorteile des Planungsprozesses nutzen zu können, muss geplant werden. Und zwar nicht nur ein wenig, sondern alles muss durchdacht sein. Sicherlich wird es zu Fehlern kommen, die später aufgedeckt werden, aber das ist nicht das Entscheidende. Es kommt darauf an, breit und tief über das nachzudenken, was zu schaffen ist. Es gibt keine Abkürzung, wenn die Vorteile des Planungsprozesses Wirkung entfalten sollen. Andernfalls erhöht sich das Risiko dem Dunning-Kruger-Effekt zu erliegen erheblich. Wenn alles gut durchdacht ist, tritt dieser Effekt nicht nur nicht auf, sondern es gelingt einem weiterhin viel besser, mit neuen Erkenntnissen umzugehen und den aktuellen Planungsstand anzupassen.

Um diese erste Planung abzuschließen, kann die Work-Breakdown-Struktur verwendet werden. Das Project Management Body of Knowledge (PMBOK 5) definiert die Work-Breakdown-Struktur als eine „hierarchische Zerlegung des gesamten Arbeitsumfangs, der vom Projektteam auszuführen ist, um die Projektziele zu erreichen und die erforderlichen Ergebnisse zu erstellen.“ Das Grundkonzept besteht aus einer Reihe von rekursiven Durchgängen, in denen Teile einer Idee in kleinere Stücke zerlegt werden, bis der Aufgabenbereich oder überschaubare Abschnitte erfasst wurden. Das Ergebnis ist eine Baumstruktur, die eine Unterteilung des zur Erreichung eines Ziels erforderlichen Aufwands zeigt. Die hierarchische Dekomposition kann durch eine funktionale oder objektorientierte Sichtweise geprägt sein.

Bei der Erstellung jedes Strukturelements sollten unter anderem die folgenden Fragen gestellt werden:

1. Löst die Komponente ein Problem, das gelöst werden muss?
2. Gibt es Abhängigkeiten zu anderen Komponenten?
3. Ist die Anordnung der Komponente richtig?
4. Aus welchen Teilen ist die Komponente zusammengesetzt?
5. Sind ausreichend Kenntnisse vorhanden, um die Realisierbarkeit des Bauteils zu beurteilen?

Während dieses ersten Planungsprozesses kann das Planungsteam auf Themengebiete stoßen, die es nicht vollständig bewerten kann. In diesem Fall wird frühzeitig erkannt, wo es an notwendigem Wissen oder Erfahrung für die Projektumsetzung mangelt. Je nach Relevanz der Planungslücke und der Verfügbarkeit von Ressourcen, um diese zu schließen, sollte eine frühzeitige Überprüfung der (wirtschaftlichen) Realisierbarkeit vorgenommen werden. Im Grunde ist jede neue Idee auf diese Weise zu prüfen, mit Ausnahme einiger reiner F&E-Projekte.

Ausgehend von der (initialen) Baumstruktur können anschließend die Phasen gebildet werden, in denen nach Scrum gearbeitet wird. Um diese Phasen zu entwerfen, muss für jedes überschaubare Element am unteren Ende des Projektstrukturplans die erforderlichen Fähigkeiten, Ressourcen, Aufwände und Zeiten sowie die Abhängigkeiten zwischen diesen Elementen Berücksichtigung finden.

Scrum-basierte Phasenausführung

Nachdem die erste Planungsphase abgeschlossen ist und der Projektplan steht, beginnt die Umsetzung. Es ist möglich jede Phase aufeinanderfolgend zu implementieren. Wenn es die Abhängigkeiten und die Kapselung der Phaseninhalte zulassen, ohne zu viel Risiko einzugehen, können auch mehrere Phasen gleichzeitig realisiert werden.

Bei der Phasenrealisierung wird Scrum eingesetzt. An dieser Stelle soll nicht erläutert werden, wie Scrum funktioniert. Nichtsdestotrotz, der Fokus sollte darauf liegen, abteilungsübergreifend zusammenzuarbeiten, Herausforderungen jeglicher Art frühzeitig aufzudecken und kontinuierlich einen validierten Mehrwert zu liefern. Es handelt sich jedoch nicht um eine rein agile Softwareentwicklung, da alle Anforderungen und Umsetzungspläne zu jeder Zeit auf einem (angemessenen) tiefreichenden Niveau ausgearbeitet sind. Lediglich neue Informationen können zu einer Umstrukturierung des Planungsansatzes führen.

Fazit

Bei der Softwareentwicklung geht es meistens nicht um das Schreiben von Quellcode an sich. Es geht im Wesentlichen darum, herauszufinden, was zu tun ist, wie es zu tun ist und wie es auf eine erweiterbare und effiziente Weise implementiert werden kann. Aus diesem Grund ist es sinnvoll, sich darüber sehr genau Gedanken zu machen, bevor die erste Zeile Quellcode geschrieben wird. Dementsprechend wichtig ist die erste Planungsphase für die meisten Projekte. Natürlich muss nicht vom ersten bis zum letzten Schritt am anfänglichen Plan festgehalten werden. Vielmehr ist der Plan im Lichte neuer Erkenntnisse anzupassen, damit optimale Lösungen entwickelt werden können (Rollierende Planung).

Bei der Realisierung von logisch gebündelten Aufgabenpaketen (Phasen) muss sich die Entwicklung sehr nahe an Scrum oder vergleichbaren Methodiken orientieren, um deren Komplexität zu bewältigen. Grundsätzlich werden aus einem Projekt viele Teilprojekte erstellt und geplant. Die Ergebnisse eines jeden Teilprojekts beeinflussen sich gegenseitig, wobei diese gekapselt voneinander abgegrenzt sind, sodass die beste Lösung flexibel als Ganzes entwickelt werden kann. Es handelt sich um eine agilitätsorientierte „Teile und Herrsche“-Methodik. In gewisser Weise wird das Scaled Agile Framework (SAFe) auf nur ein Projekt angewandt, wobei der Schlüssel zum Erfolg in einer tiefgreifenden und breit angelegten kontinuierlichen Planung liegt. Abschließend noch ein Buchtipp: Projekt Phoenix: Der Roman über IT und DevOps.