Wenn man Auto fährt und das Gas bzw. Strompedal drückt, wird man für gewöhnlich beschleunigen. Der Motor dreht schneller, die ganze Mechanik gibt das Drehmoment auf die Straße, das Auto wird beschleunigt. Wir als Person am Steuer beobachten die Umgebung, schätzen die Umweltbedingungen ab: Ist die Straße glatt? Steht mir etwas im Weg? Fahre ich in die richtige Richtung?
Welches Problem löst eigentlich der Motor? Naja, Drehmoment erzeugen, das Auto beschleunigen. Interessiert mich als Nutzer das? Isoliert betrachtet wohl kaum (sorry Petrolheads). Ok, welches Problem löst das Auto? Von A nach B kommen, etwas transportieren. Aha, damit kann ich schon mehr anfangen. Dafür bezahle ich als Nutzer auch Geld. Wobei für von A nach B transportieren ich auch alternative Produkte nutzen könnte. Stärkerer Motor, mehr Drehmoment – haben zwar unter Umständen Einfluss auf die Lösung des eigentlichen Problems, aber nur wenn alle andere Faktoren ebenfalls passen (ich kann schnell in die falsche Richtung fahren, juhu).
Führt agile Entwicklung zum Erfolg? Ja, wenn alle anderen Faktoren passen. Wie mit dem Auto: Auf passendem Untergrund, klarem Ziel und Ortskenntnis, könnte ich mein Problem des Transports von A nach B schneller lösen, wenn ich schneller fahre. Ich kann auch agil auf die kleinen Hindernisse reagieren, situativ entscheiden, nachsteuern. Das bringt aber rein gar nichts, wenn ich nicht verstanden habe, wohin ich fahren soll. Die agile Entwicklung bringt nur dann Erfolge, wenn die Lösungen, die man entwickelt, auch tatsächliche Probleme der Kunden löst.
Damit ist die agile Entwicklung nur eine Voraussetzung, um ein erfolgreiches Produkt zu entwickeln. Vor allem bei größeren Produkten und in größeren Organisationen. Leider wird oft der Fokus der Agilität lediglich auf diesen Ausschnitt gelegt. Und es kann sein, dass man ein Produkt entwickelt, was qualitativ hochwertig ist, in kleinen Chargen, getestet und ausgeliefert. Vielleicht haben sich sogar die Stakeholder das Produkt im Review angeschaut und für gut befunden. Aber am Ende des Tages nehmen die Kunden es nicht an, die versprochenen Einnahmen bleiben aus. Fehlen vielleicht Features? Ist die Applikation zu langsam? Brauchen wir mehr Marketing? Wer stellt sich schon die Frage, ob man in Wirklichkeit keine Kundenprobleme löst..
Kundenzentrierung! Da war doch was.. Jetzt wird alles besser. Irgendwo wird mehr mit dem Kunden gesprochen, bevor man mit der Entwicklung startet. Man versteht ja den Kunden auch, wir sind ja vom Fach. Features zusammenschreiben und an die Entwicklung weitergeben. In kurzen Zyklen prüfen, was da so entwickelt wird. Ab und zu dem Kunden zeigen, nachsteuern, neue Funktionen einbauen. Was der Kunde wollte, haben wir auch umgesetzt. Früher haben wir uns selbst die Features ausgedacht, heute denkt sich die der Kunde aus. Und ist am Ende.. wie war das? Schon wieder unzufrieden?
Kundenzentrierung löst nicht unbedingt auch Kundenprobleme. Unser Produkt löst angeblich ein Kundenproblem, was der Kunde uns als Auftrag oder Featurewunsch mitgibt. Der Kunde kommt eigentlich mit einer Lösung zu uns, die wir dann umsetzen. Egal wie gut wir sie umsetzen, wenn sie nicht das eigentlich Problem löst, ist der Kunde unzufrieden.
„Ich als Fahrer des Autos wünsche mir einen starken Motor, um schnell beschleunigen zu können“. Bauen wir also einen starken Motor, Sportfahrwerk, optimieren die Reifen und so weiter. Wenn ich als Fahrer um von A nach B zu kommen, im Stau stehe, wie löst die Beschleunigung mein Problem? Vielleicht wäre eine intelligente Routennavigation sinnvoller? Wie viel Zeit darf ich in der Entwicklung damit verschwenden am falschen Problem zu arbeiten?
* = Affiliate-Links
Schreibe einen Kommentar