This blog post is also available in English
Teams, die das Paradigma der agentischen Softwareentwicklung adoptiert haben, erzeugen mehr Code in weniger Zeit. Studien von DORA und Faros AI zeigen konsistent, dass diese Teams in gleicher Zeit mehr Aufgaben und Epics erledigen, mehr und größere Pull Requests erstellen und auch mehr Pull Requests mergen.
Es stellt sich die Frage, was tun mit der frei gewordenen Kapazität? Die nahe liegende Reaktion wäre es einfach in gleicher Zeit mehr zu bauen. Es gibt Unternehmen, die sich als AI-native vermarkten und bereits ihre gesamte Pipeline in diese Richtung optimieren: Da wird dann aus einer Slack-Nachricht, in der ein Stakeholder sich ein Feature wünscht, ein Pull Request, dieser geht durchs Review und wird deployt. Alles voll automatisiert durch verschiedene Agenten.
Das ist ein verständlicher Reflex, aus verschiedenen Gründen. Erstens klingt es erstmal sehr sympathisch, dass man versucht die vorhandenen Entwickler:innen weiter zu beschäftigen anstatt Entwicklungsteams aufgrund der höheren Produktivität zu verkleinern. Und zweitens haben viele Unternehmen riesige Backlogs, aus denen man scheinbar unendlich nachziehen kann, und Stakeholder, insbesondere aus der Geschäftsführung, haben ja sowieso ständig neue Ideen oder Feature-Wünsche.
Manchmal braucht die Fachseite trotzdem zu lange um ihre Anforderungen aufzubereiten. Sie wird zum Flaschenhals. Also muss auch das Requirements Engineering beschleunigt werden. BMAD und ähnliche Ansätze versprechen „Stunden statt Wochen” für Spezifikationen. Spec-driven Development und AI-unterstütztes Requirements Engineering sollen dafür sorgen dass die Entwickler:innen und ihre Agenten keinen Slack bekommen, sondern stets beschäftigt sind, stets und in höchstem Tempo Features in Produktion bringen. Was entsteht ist eine perfekte Output-Tretmühle.
Zwei Probleme
Doch dieser Ansatz hat zwei Probleme. Zum einen zeigen die Daten von DORA und Faros AI nicht nur dass mehr Code erzeugt wird, sondern auch dass Code-Reviews deutlich länger dauern und dass die Qualität der Software in agentisch arbeitenden Teams deutlich abnimmt. Der Faros AI Report zeigt dass Entwickler:innen in AI-assistierten Teams eine deutlich höhere Anzahl an Bugs erzeugen. Im Vergleich zur Zeit als die AI-Nutzung noch wenig verbreitet war, hat sich die Anzahl der Incidents etwa verdreifacht. Der DORA Report zeigt einen Anstieg an Incidents im Vergleich zu den vorherigen Jahren, auch in Teams, die DORA als High Performer einstuft.
Das andere Problem besteht darin dass Features pro Zeiteinheit keine sinnvolle Metrik ist, mit der man messen kann ob man auf dem richtigen Weg ist. Die spannenden Fragen sind doch diese: Bringen diese Features einen Wert für die Nutzenden und das Unternehmen? Befriedigen sie konkrete Nutzerbedürfnisse? Tragen sie zu einem gewünschten strategischen Outcome bei?
Wenn ein Feature einfach nur eine Idee eines Stakeholders war, sei es ein Manager, ein Geschäftsführer oder ein Kunde, dann kann die Antwort auf diese Fragen zwar ja sein, es handelt sich dann aber eher um einen Zufallstreffer.
Product Discovery als bessere Antwort
Diese Unsicherheit zu reduzieren ist das Ziel von Product Discovery. Durch systematische Methoden wie Opportunity Mapping, regelmäßige kurze Interviews mit (potenziellen) Nutzer:innen, Solution Ideation und Assumption Testing. Idealerweise gibt es einen kontinuierlichen Zyklus aus Discovery und Delivery, die wieder zu neuer Discovery führt.
In vielen Organisationen findet systematische Discovery jedoch nicht statt. Die Zahl der ungenutzten Features, die für teures Geld gebaut wurden, weil jemand eine vermeintlich tolle Idee hatte, ist beachtlich: Laut einer Studie von Pendo aus dem Jahr 2019 werden 80% der Features in durchschnittlichen Softwareprodukten selten oder nie genutzt.
Warum also reagieren wir auf die gestiegene Produktivität in der Delivery nicht, indem wir es als Chance begreifen die essenzielle Arbeit der Product Discovery ernst zu nehmen? Statt im gleichen Zeitraum mehr Features zu liefern, die niemand nutzt, könnten wir das alte Tempo einfach beibehalten und die frei gewordene Zeit nutzen, um systematisch zu testen, ob unsere Annahmen hinter dem Feature überhaupt zutreffen. Gibt es das Problem, das wir lösen wollen, wirklich? Interviews oder Beobachtungen von potenziellen Nutzer:innen verschaffen Klarheit. Ist das Feature überhaupt eine Lösung für das Problem? Auch da wollen wir gerne unsere Unsicherheit reduzieren bevor wir in die Umsetzung gehen.
Ja, AI ändert auch in der Product Discovery die Ökonomie, und sie erlaubt es den Zyklus von Discovery und Delivery schneller zu durchlaufen. Manche Annahmen aber kann ich immer noch schneller und einfacher testen, ohne dass ein Agent auch nur eine Zeile Code generieren muss, und ohne diesen in Produktion zu deployen.
Dass sich da gerade massiv etwas ändert, zeigt sich auch daran, dass etwa IBM WatsonX ein Verhältnis von einem Produktmanager zu einer halben Entwickler:in diskutiert, ausgehend von einem traditionellen Verhältnis von einem Produktmanager zu acht Entwickler:innen, wie Melissa Perri in einem LinkedIn-Post berichtet.
Produkt-Management ist also der neue Flaschenhals. Und die Antwort besteht nicht darin die Discovery-Phase mit BMAD oder ähnlichen Tools auf wenige Stunden zu komprimieren, sondern den Raum, der durch schnellere Delivery entsteht, für mehr und bessere Discovery-Arbeit zu nutzen. Weniger Features in der Pipeline bedeutet auch weniger Pull Requests, weniger Review-Druck, und weniger Incidents.
So eine Umkehrung des Verhältnisses von Produktmanagern zu Entwicklern wird Konsequenzen haben. Für Teamstrukturen, für Rollen, und für die Frage was wir als Entwickler:innen eigentlich tun.