Der Flaschenhals war nie der Code

Ich habe in den (kleinen) Teams, in und mit denen ich in den letzten 15 Jahren gearbeitet habe, immer versucht, jedem einzelnen meiner Entwickler:innen möglichst viel Freiheit bei der Umsetzung zu geben und sie, wo möglich, in Entwurfs- und Entscheidungsprozesse mit einzubinden bzw. sie diese selbst gestalten zu lassen. Denn eins war mir immer klar: Ausgeliefert wird, was der Entwickler aus dem mentalen Modell in seinem Kopf in Code umsetzt und nicht, was sich irgendwelche Wichtigtuer oberhalb in der Nahrungskette vorher ausgedacht haben.

Im Augenblick beobachten wir, wie KI Software(-Entwicklung) frisst und dabei liegt der Fokus stark auf Entwicklern selbst. Leuten, denen in klassischen Organisationen, wie ich sie in meinen Projekten oft erlebt habe, nicht unbedingt viel Wertschätzung zuteilwurde. Sie waren halt da, sie waren teuer, also hat man sie machen lassen. Aber ins Requirements Engineering einbinden oder gar mit Kunden sprechen lassen? Das war nicht so selbstverständlich immer der Fall.

Stattdessen habe ich Abstimmungsrunden erlebt, bei denen allein durch die Externen im Raum am Ende fünfstellige Kosten aufgelaufen sind, nur damit wir am Tisch saßen und diskutieren konnten. Feature-Entwicklung lief dann meist klassisch top-down: Irgendwer kam mit einem Impuls, sei es Kunde oder Mitarbeiter. Dieser landete im Backlog und irgendwann im Confluence des Product Owners/Product Managers/Product Wasauchimmer-Menschen. Es wurden Abstimmungsrunden organisiert, ein Konzept geschrieben und gereviewed, Mockups erstellt und erste Designs kreiert. Das alles erforderte viel Koordination zwischen den Beteiligten und am Ende naturgemäß auch viel Zeit. Und egal wie "agil" die Firma war, irgendwie lief es doch recht wasserfallartig. Jedenfalls bis es dann gut vorgeplant im Sprint landete, noch mal geschätzt und schließlich umgesetzt wurde. Ich hab's nicht selten erlebt, dass allein für den Requirements Engineering-Part des Prozesses Monate draufgingen, wohingegen die Entwicklung nachher nur ein paar Tage dauerte. Vor KI wohlgemerkt.

Selbst in meinen eigenen kleinen Teams war der Prozess im Grunde derselbe – nur eben mit weniger Leuten am Tisch. Das hat sich stark geändert. Heute arbeite ich – etwas vereinfacht – so: Ich nehme meinen Impuls, mache mir meine Gedanken und werfe Claude Code darauf. Nach spätestens einer Stunde steht ein Konzept, es existieren klickbare Mockups und ich habe eine gute Idee davon, was zu tun ist. Dann wird sie umgesetzt. Und wenn ich mittendrin merke: Hoppla, das würde aber so doch anders besser funktionieren, als ich mir das anfangs gedacht habe, dann drehe ich einmal alles auf links und mache weiter. Spätestens nach ein paar Tagen für sehr komplexe Dinge bin ich fertig.

Stellt sich die Frage: Wenn ich das heute so umsetzen kann, also im wohl wahrsten ursprünglich mal angedachten agilen Sinne: Warum sollten auch größere Unternehmen und Entwicklungs-Teams überhaupt weiter an ihren alten Prozessen wie oben beschrieben festhalten? Ja, es gibt oft externe Abhängigkeiten und Stakeholder, die man managen muss und auch sonst noch einiges an Corporate-Besonderheiten, die man nie ganz wegbekommen wird. Aber wenn Code jetzt zu großen Teilen von der KI geschrieben wird und die Entwickler mehr Zeit bekommen: Muss man dann den in der Pipeline davor sitzenden Produkt-Menschen noch mehr zum Flaschenhals machen, als er oder sie es nicht ohnehin schon immer war?

Oder könnte man nicht gar auf diese Rolle verzichten und die Verantwortlichkeit der Planung, Konzeption und Stakeholder-Kommunikation in die Hände der Entwickler:innen legen? Das dürfte nicht für alle und jeden geeignet sein, das ist klar. Dafür sollte es jedoch in den meisten Fällen besser funktionieren, Entwickler in diese hybriden neuen Rollen zu setzen, als "klassische POs" ohne Entwickler-Hintergrund.

Die mentalen Modelle der Entwickler waren schon immer das, was am Ende wirklich zählt – jetzt haben wir endlich die Werkzeuge, diese zu heben, um mal im Business-Kasper-Sprech zu enden.