Erfolgreiche Softwareentwicklung – starte mit dem Skateboard

Etwas von einer Idee so weiterzuentwickeln, bis ein tolles Produkt entsteht, ist eine Herausforderung. Je komplexer die Idee, desto schwieriger ist es, sich nicht in den Details zu verlieren. Aus unserer Erfahrung in der Softwareentwicklung kennen wir diese Herausforderung. Es gibt jedoch eine Lösung und die heisst Agilität.

Agilität ist ein häufig verwendetes Schlagwort, welches allerdings oft falsch verstanden wird. Die nachfolgende Illustration zeigt bildlich auf, was Agilität in der Produktentwicklung ist und was nicht.

Im Kontext von der Softwareentwicklung wird zusammen mit der Agilität auch das Konzept vom MVP (Minimal viable product) häufig im gleichen Atemzug genannt. Zu diesen beiden Konzepte kursieren aber zahlreiche falsche Vorstellungen. Am besten wird das an einer fiktiven Geschichte klar.

Die Ausgangslage ist häufig ähnlich, der Auftraggeber weiss ungefähr, was seine Zielgruppe haben möchte bzw. was er glaubt, das sie brauchen. Häufig sind aber bei weitem nicht alle Details geklärt, der Aufwand alles bis ins kleinste Detail abzuklären wäre viel zu hoch. Involviert sind nebem dem Auftraggeber noch weitere Stakeholder, z.B. die potenziellen Nutzer dieses Produktes, das interne Management oder Mitarbeitende. Das Ziel in unserer Beispielgeschichte ist es, ein neues Auto für eine urbane Zielgruppe zu entwickeln.

Bei der falsch verstandenen Agilität wird nun das Auto von Anfang an möglichst genau skizziert, beschrieben und dokumentiert. Die Teile bis zum Endprodukt werden dann Schritt für Schritt geliefert. Zuerst das Rad, dann zwei Räder verbunden mit einer Achse, das Chassis, und am Schluss auch noch ein Dach mit Interieur. Weder der Auftraggeber noch ein echter Kunde aus der Zielgruppe kann bei den Schritten 1, 2 oder 3 das Produkt testen. Es ist schlicht nicht nutzbar. Im besten Fall erhält der Auftraggeber im letzten Schritt das bestellte Produkt und ist glücklich.

Leider ist das aber in der Praxis nur selten die Realität. Speziell grosse Projekte in der Softwareentwicklung, die auf eine grosse Veröffentlichung hinarbeiten, schlagen häufig fehl. Beispiele gibt es dazu dutzende, z.B. kürzlich ein fehlgeschlagenes IT Projekt vom Kanton Zürich für 25 Millionen. Wir nennen das bei uns, etwas «todentwickeln». Je länger entwickelt wird, desto höher ist das Risiko, das etwas programmiert wird, dass nicht oder nicht mehr den Anforderungen der Zielgruppe gerecht wird und am Schluss ein Misserfolg wird.

Wie geht es besser? Mit korrekt verstandener Agilität in der Softwareentwicklung!

Agilität ist nach unserem Verständnis eine Art zu denken und die erste Frage, die sich bei einem solchen Projekt immer stellt, ist «warum?». Warum wird das neue Auto entwickelt und welches Problem lösen wir den ganz genau für unsere Zielgruppe.

In diesem Beispiel geht es darum, von A nach B zu kommen. Wenn das eigentlich zu lösende Problem klar ist, suchen wir im zweiten Schritt den einfachsten Weg, mit welchem wir dieses Problem lösen können. Das Ziel in diesem Schritt ist es nicht, den Kunden glücklich zu machen, sondern wir möchten mehr über das genaue Problem erfahren und Rückmeldungen erhalten. Ein Weg könnte sein, dass wir ein einfaches Skateboard bauen und es einem Testkunden zur Verfügung stellen. Vielleicht hasst der Testkunde das Produkt. Vielleicht stört ihm aber auch nur die Farbe und mit einer anderen Farbe hätten wir das Ziel bereits erreicht aber zu deutlich tieferen Kosten. Wenn es um die Neuentwicklung von einer Idee geht, braucht es eine grosse Vision, aber der Start sollte so einfach wie möglich erfolgen, damit möglichst früh Rückmeldungen von den Kunden zurückkommen, die das Produkt dann effektiv auch nutzen.

Die nächste Verbesserung im Schritt 2 könnte z.B. ein Griff sein. Vom Kunden kam as Feedback, dass das Skateboard viel zu wackelig ist. Diese Verbesserung mit einem neuen Griff erfolgt rasch und der Kunde erhält wiederum das überarbeitete Produkt. Wirklich glücklich ist der Kunde noch immer nicht, allerdings wird das Produkt effektiv verwendet und wir erhalten wertvolles Feedback.

Ein Feedback kritisiert, dass das Skateboard mühsam ist für grössere Distanzen in der Stadt. Im nächsten Überarbeitungsprozess entwickelt sich das Skateboard deshalb zum Velo. Der Kunde kann damit nun auch grössere Distanzen fahren. Vielleicht stellt sich nun heraus, dass das Velo das perfekte Produkt für unsere urbane Zielgruppe ist, da die Strassen sowieso zu eng wären für ein Auto. Häufig wird argumentiert, dass so etwas bei einer eingangs erfolgten Analyse hätte erkannt werden müssen, und ja, Analysen am Anfang sind wichtig, allerdings wird nie alles am Anfang gefunden und unsere Erfahrung ist, dass besser nicht zu viel Zeit mit Analysen verschwendet werden, am Schluss kommt es sowieso dann wieder leicht anders.

Die weitere Entwicklung könnte nun ein Motorrad sein, damit der Fahrer einfacher in die andere Stadt wechseln kann. Die Rückmeldung von den Kunden in diesem Schritt ist, dass sie das Motorrad super finden, vor allem die frische Luft, die in die Haaren zischt. Deshalb wird beim letzten Schritt ein Cabriolet entwickelt. Der Auftraggeber hat nun das gewünschte Produkt, ein Auto, allerdings ist es auf dem Weg besser geworden durch die zahlhreichen Kundenrückmeldungen und die Chance besteht, dass das eigentliche Kernproblem bereits beim Velo für die Zielgruppe zur vollen Zufriedenheit gelöst wurde.

Das Fazit aus der Geschichte leuchtet ein, auch wenn wir am Schluss beim Auto landen, haben wir auf dem Weg dahin viel gelernt, sodass das resultierende Produkt deutlich besser ist, als das am Anfang geplante. Die laufenden Kundenfeedbacks haben dabei gelhofen, die Entwiclkung in die korrekte Richtung zu lenken. Bei der nächsten Idee oder beim nächsten grösseren Entwicklungsprozess, stellen Sie sich die Frage «Was könnte unser Skateboard sein?». Diese Frage hilft, sich am Anfang auf den Kern zu fokussieren, sowohl in der Softwareentwicklung als auch allgemein in der Produktentwicklung.

Speziell in der Softwareentwicklung ist es entscheidend, von Anfang an die grosse Vision vor Augen zu haben. Die erste Umsetzung sollte sich aber immer auf das Kernproblem konzentrieren und diese Lösung möglichst früh den Endkunden zur Verfügung stellen. So werden Projekte erfolgreich umgesetzt innerhalb von einem definierten Zeit- und Budgetrahmen.

Dieser Beitrag wurde inspiriert von dem Blogpost von Henrik Kniberg von 2016. Eine etwas ausführlichere Version dieses Beitrags wurde an einem IHK Lunch im 2021 von Noah Menzi vorgetragen.