Ein Treiber von Agilität ist die operative Exzellenz in der Entwicklung. Zu Recht, denn Entwicklungsprojekte können ewig dauern, bevor Anwender den ersten Nutzen daraus ziehen. Unvergesslich für mich die Lektüre von „Dreaming in Code“. Das Buch von Scott Rosenberg beschreibt in epischer Breite die Odyssee eines Softwareentwicklungsprojekts.
Mit ihrem Beharren auf fertige Produkinkremente fordert Agilität vom Entwicklungsprozess kontinuierliche Lieferfähigkeit. Wer das agile Manifest liest, merkt: Die Exzellenz in der Umsetzung und Fertigstellung ist wichtiger als die Exzellenz im Design. Denn wer schnell am Markt ist, kann danach kontinuierlich optimieren. Wer aber Perfektion im Lastenheft- und Pflichtenheft anstrebt, wird vermutlich in Schönheit sterben, ehe sein Produkt das Licht der Welt erblickt.
Stefan Willuda - Freidenker und agiler Coach bei idealo - hat auf Medium einen Beitrag geschrieben, der gut zum Thema passt. Er erklärt uns, warum wir darüber nachdenken sollten, der Priorisierung von Anforderungen nicht mehr, sondern weniger Beachtung zu schenken:
I think in the realm of product development and knowledge work (...), the way we handle prioritization is completely over-engineered. While there is no doubt about the mathematical correctness of the procedures, in an environment of very high uncertainty the assumptions feeding those procedures cannot be accurate enough to justify the work that teams put into.
Es stimmt ja: Unternehmen verbringen mitunter viel Zeit mit der Beantwortung der Frage, welche Dinge in welcher Priorität bearbeitet werden sollen. Jedoch ist Produktentwicklung keine exakte Wissenschaft - selbst eine noch so gut durchdachte und berechnete Entscheidung birgt das Risiko, von falschen Annahmen auszugehen. Ein Feature, das für den Anwender großen Nutzen stiften sollte, entpuppt sich nachträglich als Flop. Solche Enttäuschungen sind in der Produktentwicklung eher die Regel als die Ausnahme.
Heißt das nun, dass wir das Priorisieren von Anforderungen über Bord werfen und die Abarbeitungsreihenfolge dem Zufall überlassen sollen? Mitnichten! Dank des agilen Fokus auf Lieferfähigkeit besinnen wir uns vielmehr darauf, unter all den wertvollen Dingen, die wir umsetzen wollen, die kleinsten Dinge zuerst auszuwählen. Warum die kleinsten Dinge? Weil wir diese zuerst fertig stellen können. Können wir dann nicht ebenfalls falsche Entscheidungen treffen? Natürlich - aber zumindest finden wir dann früher heraus, dass es eine falsche Entscheidung war:
The team will make the wrong choice eventually. The selected work item will not generate the anticipated value. That is the same with big bets. But with tiny work items, the team learns fast and is certainly going to make a better decision next time.
Und einen schönen Nebeneffekt hat dieser Ansatz auch noch: Die agilen Teams lernen auf diese Weise, ihre Arbeit in kleine, schnell umsetzbare Elemente zu schneiden. Und richten damit den Entwicklungsprozess auf kontinuierliche Lieferfähigkeit aus.