Ein Team schafft heute an einem Tag, wofür es früher zwei Wochen gebraucht hat. Backlogs leeren sich, und etablierte Prozesse gehen über Bord, ohne dass klar wäre, was an ihre Stelle tritt.
Organisationen verfolgen einen Zweck, tragen ein Geschäftsmodell und erfüllen nebenbei Funktionen, die niemand geplant hat. Ändert sich eine Basistechnologie, geraten ihre etablierten Strukturen und Prozesse in eine Krise. Agentische Softwareentwicklung verschiebt den Engpass von der Umsetzung auf die Frage, wer überhaupt handeln kann. Wir nennen das Handlungsfähigkeit.
Handlungsfähigkeit hat drei Seiten: Was weiß ich, was darf ich, was kann ich? In der Organisation sind das keine Eigenschaften von Personen, sondern Ergebnisse der Struktur. Und Strukturen lassen sich ändern.
Wir beobachten das in der Softwareentwicklung. Dort bleibt es nicht. Diese Seite sammelt, was wir sehen, formuliert Hypothesen und skizziert ein Betriebsmodell.
Teil 1
Beobachtungen
Was wir sehen
1 KI-Agenten verschieben den Engpass.
Fachliche Entscheidungen fallen selten im Team. Die Entscheidungswege halten mit der Entwicklungsgeschwindigkeit nicht mit. Teams fragen jetzt: „Das Backlog ist leer, was bauen wir als Nächstes?“
2 Prozesse werden über Bord geworfen.
Teams verwerfen etablierte Prozesse, weil diese nicht mehr funktionieren. Was an ihre Stelle tritt, weiß niemand.
3 Produktivität wächst, Überblick geht verloren.
Bei gleicher Größe liefern Teams mehr. Was dabei entsteht, überblickt oft niemand mehr – weder fachlich noch technisch.
4 Rollengrenzen lösen sich auf.
Produktmanager schreiben Code, der einer normalen Qualitätssicherung oft nicht standhält. Die Arbeitsteilung zwischen Produkt und Entwicklung hat sich noch nicht neu eingespielt.
5 Teams überspringen die Ebene, die entscheiden soll.
Ein Produktmanager fragt die Geschäftsführung, was zu bauen ist, weil die Stakeholder erst in zwei Monaten das nächste Quartal planen. Die Teams brauchen neue Ziele schneller, als das Unternehmen sie setzt.
6 Führung baut solo.
Im inhabergeführten Mittelstand bauen Führungskräfte selbst mit dem Agenten, statt ihre Teams dorthin zu bringen, wo sie es können.
7 Die KI-Kluft spaltet Organisationen von innen.
Die einen probieren, die anderen erstarren. Vielen ist nicht mehr klar, was von ihrer Rolle jetzt erwartet wird.
8 Ein schnelles Team wird zum Maßstab für alle.
Ein Team zieht davon, und die Führung schließt daraus, alle müssten jetzt so schnell sein.
9 Das Tempo sprengt feste Review-Rhythmen.
Continuous Delivery hatten wir schon, neu ist die Schlagzahl. Das Gespräch mit dem Fachbereich alle zwei Wochen im Review kommt dafür zu spät.
10 Zwischen Idee und Code entsteht die Software Factory.
Wer entwickelt, baut zunehmend die Maschine, die das Programm baut. Sie hat ihre eigene Logik.
11 Vibe-Prototypen betreffen die Desirability, nicht die Feasibility.
Was im schnellen Prototyp entsteht, zeigt, ob etwas gewollt ist. Ob es in Produktion technisch und mit den Daten trägt, bleibt offen.
12 Fachleute bleiben nur auf Zeit im Team.
Fachlich führt sie ihre eigene Abteilung. Ins Produktteam kommen sie für ein Projekt und gehen, sobald die Software steht.
13 Die Nutzer kommen nicht mehr mit.
Die Teams liefern schneller, als ihre Nutzer die Software aufnehmen können. Vieles bleibt als 80-Prozent-Lösung liegen, im Fachbereich wie am Markt.
Die Diagnose
Was folgt aus dem, was wir sehen?
Die Bauzeit war der heimliche Taktgeber, ohne dass jemand sie dazu bestimmt hätte. Planung, Reviews, Rollenzuschnitte, Entscheidungswege sowie die Aufnahmefähigkeit des Fachbereichs und der Kunden haben sich an dieser einen Größe ausgerichtet. Die Größe ist verschwunden, die Ausrichtung ist geblieben. Jeder dieser Teile funktioniert prinzipiell weiterhin für sich, im Zusammenspiel passt keiner mehr.
Die Crux: Kein Teil lässt sich allein verstellen. Wer die Planung beschleunigt, überfährt den Fachbereich. Wer das Review streicht, verliert den Überblick, der nebenbei darin entstand. Wer Handlungsfähigkeit ins Team gibt, verlangt von den Fachleuten eine Verfügbarkeit, die ihre Linie oft nicht hergibt. Verstellen muss man mehrere Teile gleichzeitig. Wer das könnte, bräuchte Information über die Zusammenhänge, Entscheidungsfreiheit über Planung, Freigaben, Teamzuschnitt und Fachbereich, und das Können, die Folgen abzusehen. Also Handlungsfähigkeit, angewendet nicht auf das Produkt, sondern auf die Organisation.
Teil 2
Hypothesen
Was wir glauben
Wir haben noch keine Antworten, aber Hypothesen.
H1 Richtet eure Organisation auf Handlungsfähigkeit aus, nicht auf Umsetzung.
Wer nur die Umsetzung beschleunigt, verschiebt den Engpass, statt ihn aufzulösen.
H2 Handlungsfähigkeit muss sich verteilen.
Die eigentliche Aufgabe ist, Teams selbst handlungsfähig zu machen und ihnen Verantwortung für ihr Produkt zu geben.
H3 Frustration ist ein Signal.
Wo Menschen sich aufreiben, liegt meist ein Engpass. Frustration zeigt euch, wo Handlungsfähigkeit fehlt.
H4 Führt die Factory wie ein Produkt.
Das interne Produkt braucht dieselbe Führung wie das äußere: klare Verantwortung, eigene Rhythmen, einen Blick auf den Nutzen für das Team.
H5 Bindet die Fachlichkeit asynchron ein.
Fachleute gehören nie ganz zum Team. Ihr Wissen erreicht euch in kurzen, entkoppelten Schleifen besser als in festen Terminen.
H6 Die Ziele der agilen Praktiken bleiben, ihre Form ändert sich.
Was Daily, Retro und Review erreichen sollen, ist weiter richtig.
H7 Der Überblick entsteht nicht mehr nebenbei.
Früher hielt ihn die Langsamkeit aufrecht. Jetzt muss ihn jemand herstellen, fachlich wie technisch.
H8 Ein Team muss den nächsten Schritt selbst wählen können.
Je schneller gebaut wird, desto weniger hält eine Detailplanung, und desto deutlicher hinkt die Kadenz von Instrumenten wie OKR hinterher.
Teil 3
Framework
Ein Betriebsmodell zeichnet sich ab: wer welche Rolle hat, welche Rhythmen gelten, welche Artefakte den Takt vorgeben. Eine Skizze, locker gehalten und rigoros geprüft. Keine Methode.
Zielgruppe
hycle richtet sich an Produkt- und Tech-Organisationen, die selbst Software bauen und unter Druck geraten, weil kleine, stark gehebelte Wettbewerber sie einholen. An Mittelstand und Großunternehmen, die schon etwas haben und es selbst verändern können.
Wir steigen über die Prozesse rund um die Softwareentwicklung ein, nicht über das Geschäftsmodell. Dort ist der Umbruch am größten, und dort sitzt unsere eigene Erfahrung. Wir fragen, wie eine bestehende Organisation sich verändert, damit agentisches Arbeiten möglich wird.
Gemeint ist Produktarbeit mit offenen Fragen. Reine Auftragsarbeit, die eine fertige Spezifikation abarbeitet, fällt nicht darunter.
Factory
Die Factory hat drei Teile: Ideation, Execution, Validation. Heute decken wir agentisch vor allem die Execution ab, und auch die nicht durchgängig. Wie weit sich die anderen beiden mitziehen lassen, ist offen. Der Begriff passt am ehesten auf die Execution, wo immer dasselbe herauskommen soll. Die Ideation ist divergent und weniger fließbandartig, auch wenn Agenten sie schneller machen.
Ideation
Herausfinden, welches Problem zu lösen ist und woran sich messen lässt, dass es besser wird.
Execution
Überlegen, was genau dafür zu bauen ist, und es bauen. Hier steckt unsere Erfahrung. Einfach ist auch das nicht.
Validation
Prüfen, ob das Ziel erreicht ist und ob die Software genutzt wird und wirkt.
Der Nordstern für die Execution ist eine Factory, die im Hintergrund läuft und vorne nur noch Richtung und Aufgaben bekommt. So weit sind wir nicht: heute braucht ihr Aufbau viel Engineering-Wissen. Aus einem nicht-deterministischen System ein deterministisches zu machen, ist der eigentliche Kern, und erst das rechtfertigt das Wort Factory.
Ein Team hat damit zwei Produkte: eines für außen und die Factory als internes Produkt. Ihr Nutzer ist das Team selbst, und geführt wird sie wie das äußere Produkt.
Erst wird lokal gelöst, dann herausgezogen und abstrahiert, was für alle taugt. Die gemeinsame Plattform ist das Ergebnis, nicht der Ausgangspunkt.
Die Factory bleibt Teil einer Produktorganisation: Wir bauen, um zu lernen.
Rollen
Diese Rollen sind Bündel von Erwartungen und Fähigkeiten. Sie müssen im Team vorhanden sein, nicht in einzelnen Personen. Eine Person kann mehrere abdecken, aber genau hier hakt es in der Praxis: Menschen kleben sich ein Rollen-Label an, und mehrere Rollen in einer Person gehen oft schief.
Product Lead
Verantwortet die Epics und spricht mit Stakeholdern und Fachbereich. Er klärt, was gebaut wird und warum, und steckt tiefer in der Domäne als ein klassischer Produktmanager. Er treibt auch Einführung und Distribution.
Product-Engineer
Verantwortet die Story und füttert die Factory. Seine wichtigste Fähigkeit ist klare Sprache, denn er führt mehrere Agenten parallel.
Factory-Engineer
Baut und pflegt die Factory. Das ist eine abstraktere Art, Software zu entwickeln. Er sorgt dafür, dass sie deterministische, wiederholbare Ergebnisse liefert. Mit der einzelnen Story hat er nichts zu tun: er ist der Mechaniker, der an der Factory schraubt, wenn das Ergebnis nicht stimmt.
Kunde vor Ort
Keine Rolle, sondern eine Bedingung. Stakeholder müssen verfügbar sein, in kurzer Schleife, nicht erst im Review nach zwei Wochen. Fehlt dieser Draht, trägt das Modell nicht.
Offen bleibt, wo der Schnitt zwischen Product Lead und Product-Engineer verläuft und ob der Product Lead eine eigene Rolle bleibt oder in der Fachlichkeit aufgeht. Ebenso offen: wie weit die Factory-Rolle reicht und ob Factory- und Product-Engineer dieselbe Person sind.
Kadenzen
Natürliche Rhythmen: einmal am Tag, einmal in der Woche. Kleine Teams brauchen davon weniger, vieles läuft bei ihnen informell.
Tägliche Synchronisation
Einer am Tag reicht. Aus dem alten Daily wird ein sozialer Sync, vor allem remote. Der Austausch läuft über das interne Produkt: was die Agenten gestern gebaut haben, wie gut sie geführt waren, wo nachzujustieren ist. Ein Status-Report ist das nicht.
Wöchentliche Retro
Die Retro nimmt bei hohem Tempo bewusst Geschwindigkeit heraus und schaut auf den Arbeitsprozess: was geklappt hat und was nicht. Je paralleler gearbeitet wird, desto wichtiger wird dieser eine Termin, der das Team wieder zusammenführt.
Review
Das klassische Review am Ende eines Zwei-Wochen-Zyklus funktioniert nicht mehr. An seine Stelle tritt ein Validation-Loop, ein tieferes Innehalten mit dem Charakter einer Retro: Er fragt, was wir erreicht haben, nicht nur, was ausgeliefert wurde.
Die wichtigen Rückkopplungen und Entscheidungen folgen keinem Takt. Sie passieren mehrmals am Tag, immer dann, wenn sie anstehen, und lassen sich nicht ritualisieren.
Das interne Produkt, die Factory, läuft in festen Kadenzen wie bei Scrum, das äußere Produkt eher im Durchfluss wie bei Kanban: fertig ist fertig. Wie der äußere Rhythmus genau aussieht, ist offen. Auch ein Durchfluss kennt Punkte zum Innehalten.
Artefakte
Die Artefakte werden gröber. Was früher eine Story war, ist jetzt ein Epic. Was ein Task war, ist jetzt eine Story. Die Tasks macht der Agent. Fehlt eine Antwort aus dem Fachbereich, arbeitet das Team auf einer Annahme weiter und hält sie in einem Annahmenregister fest. Solche Blocker müssen schnell weg, nicht in zwei Wochen.
Epic
Das tragende Artefakt, auf der Ebene der Benutzeroberfläche. Hier stimmt sich der Product Lead mit dem Fachbereich ab, und das Epic trägt Intent, Ziel und Kennzahlen. Lange war es eher ein Nice-to-have, jetzt ist es Pflicht: nichts kommt ohne Epic und klaren Intent in den Prozess. Oft erzeugt erst das Epic den gewünschten Outcome, die Stories darin sind nur Schritte dorthin.
Story
Die Schnittstelle zur Factory. Anders als ein Task muss eine Story für sich Wert stiften, ein eigenständiges Feature. Sie ist zugleich klein genug geschnitten, dass ein Agent sie ganz überblickt, denn nur in einem begrenzten Kontext liefert er verlässlich. Ihre Akzeptanzkriterien entstehen mit ihr, am besten als ausführbare Tests aus Sicht des Endkunden. Der Schnitt vom Epic zur Story liegt jetzt im Engineering. Auch das Refinement wandert dorthin: aus dem Meeting zwischen Menschen wird ein Wechselspiel aus Entwickler und Agent – eine Sache von Minuten.
Task
Den macht der Agent. Für die Menschen spielt diese Ebene keine Rolle mehr.
Oft dreht sich die Reihenfolge um: erst ein Prototyp, an Nutzern validiert, daraus ein PRD, daraus die Epics und Stories. Und weil der Agent jede Lücke mit eigenen Annahmen füllt, muss der Input noch klarer sein als früher.
Sonstiges
LLMs sind Mustererkenner. Wo der Code wenige, konsistente Muster zeigt, bauen sie sauber weiter. Wo er chaotisch ist, vervielfältigen sie das Chaos. Konsistente Muster und Tests sind deshalb eine große Hilfe.
Kleine, klar geschnittene Aufgaben senken das Risiko: je enger der Auftrag, desto eher kommt heraus, was gemeint war. Die technische Detailplanung überlässt man dem Agenten bewusst erst spät, sonst läuft der Plan der Realität davon.
Ohne schnelle Rückkopplung zum Fachbereich wird agentische Entwicklung leicht zum bloßen Rationalisierungswerkzeug.
Offen bleibt, ob Pflichtenhefte (PRDs) wirklich zurückkommen sollten.
Es gibt keinen Masterplan. Es geht Engpass für Engpass, und der nächste ist in jedem Team ein anderer. Wer ihn benennen kann, gibt die Richtung vor.
Was hycle nicht ist
Kein Rollout am Montagmorgen. Das lässt sich nicht von oben verordnen. Es braucht weiter Rhythmen und menschlichen Austausch, und wie die aussehen, wissen wir noch nicht.
Kein Technologie-Framework. Tools und Plattformen wählt ihr selbst.
Nicht gegen Agile. Die Werte werden wertvoller, die Artefakte ändern sich.
Nicht präskriptiv. Wir liefern Prinzipien, Diagnose und Referenzmuster. Wie daraus ein Vorgehen wird, ist eure Arbeit.
Nicht universell. Uns geht es um die Prozesse rund um die Software, nicht um die Software selbst. Die ganz Kleinen machen das ohnehin schon. Die ganz Großen lassen sich kaum steuern, da passen unsere Antworten oft nicht. Wir zielen auf die dazwischen.
Nicht fertig. Eine Einladung, gemeinsam zu suchen, was funktioniert.
Mitwirken
Call for Participation
Wo wir stehen
Wir setzen dieses Modell gerade bei mehreren Kunden auf. Was ankommt: dass Bauen und Entscheiden zusammensitzen, dass das Backlog Features gegen Annahmen tauscht. Offen ist, wie die menschliche Abstimmung hält, wenn die Factory ihre eigene Geschwindigkeit hat. Daten liefern wir nach.
Was wir suchen
hycle ist eine Hypothese, kein Produkt. Was wir aufgeschrieben haben, hat in unserer Praxis Anker, aber keinen Beweis. Was uns fehlt, ist eure Praxis.
Drei Fragen
Was klappt bei euch?
Welche Rolle trägt, welcher Rhythmus hält, welche Zusammenarbeit mit dem Fachbereich funktioniert? Schreibt es so, dass es jemand kopieren kann.
Was klappt nicht?
Wo holt die Organisation euch ein? Wo bricht das Modell? Sagt es, bevor ihr aufgebt.
Wo seid ihr auf die Nase gefallen?
Misserfolge sind die teuersten Daten. Wenn ihr sie teilt, macht sie ein anderer nicht noch einmal.
Schreibt uns, was bei euch passiert. Wir lesen mit.
Die Autoren
Der Name
Gemeint ist ein Zyklus, der sich so stark beschleunigt, dass er dabei eine neue Qualität gewinnt. Dafür steht hycle, der hyper cycle.
Im Deutschen klingt das Wort nach heikel. Das ist beabsichtigt.
Und ja, hype cycle steckt auch darin. Uns geht es um das, was bleibt, wenn der Hype vorbei ist.