Der agile Ansatz: Wie du dein Softwareprodukt in der Praxis wachsen lässt

In meinem vorherigen Artikel ging es um die Unterschiede zwischen Software, die man wachsen lässt, und Software, die man „baut“. Beim Wachsenlassen profitiert man im Gegensatz zum rigideren Konzept des Bauens von den Aspekten, die das Wesen von Software ausmachen – Vielseitigkeit, Flexibilität und leichte Aktualisierbarkeit. Im Folgenden möchte ich auf die praktische Umsetzung dieses Konzepts eingehen.

Software wachsen lassen: Wie fängt man an?

Schritt 1: Der Use Case

Zu Beginn jedes neuen Projekts liegt der Schwerpunkt darauf, einen einzelnen Use Case zu haben, der end-to-end funktioniert. Für maximale Effektivität sollte dein Anwendungsfall in die drei folgenden Kategorien fallen: vertikal, typisch und einfach.

Vertikal insofern, als er alle Software-Schichten durchkreuzt und jede Schicht beteiligt ist. Beispielsweise sollte der Use Case bei einer Webanwendung sowohl Frontend (Daten- und Präsentationsschicht) als auch Backend (Datenbank- und Datenverarbeitungsschicht) umfassen.

Typisch insofern, als die größten und häufigsten Herausforderungen getestet werden. Wenn die Software beispielsweise über eine Datenbank verfügt, sollte diese getestet werden, um sicherzustellen, dass die Risiken unter Kontrolle sind.

Und schließlich sollte der Use Case so einfach wie möglich strukturiert sein, damit möglichst wenige Variablen zu berücksichtigen sind. Ziel ist es, diesen Use Case schnell abzuschließen, um zeitnah Feedback zu erhalten.

Auf den ersten Blick bietet ein solcher Anwendungsfall nur minimale Funktionalität und wenig Mehrwert. Und doch:

• Er schafft einen Wert, wenn auch nur einen kleinen.
• Er ist nachweisbar, was bedeutet, dass der Wert für die Nutzer klar ist – und du entsprechend Feedback dazu erhalten kannst.
• Er hat durch Berücksichtigung der wesentlichen Aspekte und Kontrolle der Risiken zum Softwaredesign beigetragen und so eine reibungslose weitere Entwicklung ermöglicht.
• Ein solcher Mehrwert ist rasch realisiert und kompensiert den geringen tatsächlich geschaffenen Wert weitestgehend.

Schritt 2: Wir lassen die Software wachsen

Sobald diese minimale Funktionalität erreicht ist, kann man wie im vorherigen Artikel beschrieben zur Wachstumsphase übergehen. Das bedeutet:

• Ausschließlich kleine Anpassungen vornehmen, die stets einen Mehrwert bieten
• Sicherstellen, dass der Mehrwert der Anpassungen stets nachweisbar ist
• Stets die Integration der Anpassungen mit der restlichen Software gewährleisten
• Die Änderungen an verschiedenen Teilen der Software vornehmen, ohne den Build in seiner Gesamtheit zu gefährden

Dabei können wir jederzeit Fehler machen und schnell zu unserem vorherigen Stand zurückkehren. Das ist einfach, weil die Schritte klein sind. Es ist also kein Problem, Code wegzuwerfen. Schließlich ist immer nur ein kleiner Teil der Arbeit betroffen.

Produktmanagement: Entwicklung in kleinen Schritten

Wenn man Software wachsen lässt, ist eine inkrementelle Vorgehensweise entscheidend für den Produkt-Entwicklungsprozess. Dabei sind folgende Punkte wichtig:

Bereitstellung klarer Anweisungen zur Aufspaltung des Backlogs

• Die Software muss zu jedem Zeitpunkt einsatzfähig sein – nachweisbar und vollständig integriert.
• Alle Backlog-Elemente müssen einen Mehrwert bieten.
• Um schnellstmöglich Feedback zu erhalten, ist es notwendig, Elemente des Backlogs aufzuteilen bzw. herauszutrennen.

Die richtige Denkweise einnehmen

• In der ersten Phase der Entwicklungsarbeit soll ein Live-Build entstehen, aber auch sichergestellt werden, dass sich die Softwarearchitektur an das Projekt anpasst.
• Bei der Erstellung funktionaler Software nicht mehr als das absolute Minimum bereitstellen
• Bereit sein, Code zu verwerfen, der ein problemloses „Wachstum“ der Software verhindert

Befolge die Grundsätze des Produktmanagements

• Entwickle kleine Funktionen, teste sie und optimiere sie dann – das ist der Lean-Startup-Ansatz, den ich in einem früheren Artikel beschrieben habe.
• Wende ein inkrementelles Vorgehen und möglichst schnelle Iterationen an.
• Achte darauf, Risiken angemessen zu berücksichtigen, um das Produktentwicklungs-Tempo nicht zu gefährden.
• Vergeude keine Zeit mit Dingen, die keinen Mehrwert schaffen.

Risiken bei Nichtbeachtung der Wachstums-Denkweise

Wer an der Vorstellung des Bauens von Software festhält, beschränkt seine Möglichkeiten, Fortschritte im Hinblick auf eine wirklich agile Vorgehensweise zu machen. Noch schlimmer ist es, wenn man glaubt, bereits agil zu entwickeln, die Product Operations jedoch unverändert bleiben. Mit folgenden Konsequenzen ist dann zu rechnen:

• Die Möglichkeiten, das Produkt in die Produktion zu überführen, sind eingeschränkt. Release-Zeiten müssen explizit geplant werden, anstatt über eine jederzeit auslieferbare Code-Basis zu verfügen. Die unmittelbare Folge ist, dass jeder Produktions-Launch von unerwarteten und unangenehmen Überraschungen begleitet wird.
• Das Produkt ist für Anpassungen nicht ausgelegt. Je weiter die Code-Basis wächst, desto schwieriger wird es, sie zu verändern. Die Teamleistung wird immer schlechter einschätzbar. Gleichzeitig schnellen Produktionszeit-Schätzungen in die Höhe. Folglich beklagen sich die Entwickler bei jedem weiteren Request, der reinkommt.
• Das System rebelliert. Durch die mangelnde Flexibilität rebelliert das gesamte System gegen das Unternehmen und seine Nutzer, um jegliche Weiterentwicklung (und Aufwände) möglichst zu begrenzen. So wird beispielsweise die „Definition of Ready“ immer strikter und prozeduraler. Das Team beginnt vom „Scope Creep“ zu sprechen, ungeplanten Anforderungen, die den Launch verzögern, jedoch für die Endanwender wesentlich sind.
• Umsetzer versus Strategen. Dein Team befolgt eine Umsetzungsmentalität, anstatt über die eigentliche Bedeutung hinter dem Produkt und die Aufgabe nachzudenken, die es erfüllen soll.

Agil zu entwickeln, aber gleichzeitig an der Denkweise des Bauens statt des Wachsens festzuhalten, bedeutet, dass du wahrscheinlich genauso wie vorher arbeitest und eine Art Pseudo-Agilität betreibst. So kannst du keine echten, greifbaren Fortschritte machen.

Eine Analogie als Orientierung

Die Wachstumsprozesse der Natur als Analogie für die Softwareentwicklung zu benutzen ist also durchaus schlüssig. Die Natur ist so komplex, dass eine Analyse der Grundprinzipien, nach denen Leben gedeiht, zweifellos der richtige Weg ist, um der Komplexität von Software-Entwicklungsprojekten Rechnung zu tragen.