Alle paar Jahrzehnte räumt eine neue Technologie Beschränkungen ab, um die herum Organisationen ihre Strukturen und Prozesse gebaut haben. Das sehen wir gerade wieder: Agentische Softwareentwicklung verschiebt den Engpass von der Execution auf die Frage, wer überhaupt handeln kann, wer darf und wer genug weiß. Wir nennen das Handlungsfähigkeit.
Eine Entwicklerin schafft jetzt an einem Tag, wofür ein Team früher zwei Wochen gebraucht hat. Backlogs leeren sich, und die erste Reaktion vieler Organisationen ist, Scrum abzuschaffen. Das verbirgt das Problem, statt es zu lösen.
Der Name
Manfred Eigen beschrieb 1971 die Hyperzyklen, gekoppelte Kreisläufe, die sich gegenseitig tragen. An der Grenze zwischen chemischer und biologischer Evolution schaffen sie die Voraussetzungen für Leben: Replikation, Variation und Selektion. Sie erzeugen das Leben nicht, sie machen es möglich.
Wir vermuten, dass Organisationen vor einem ähnlichen Übergang stehen: von prozessgetriebener zu entscheidungsgetriebener Arbeit. Diesen Übergang nennen wir hycle, den 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.
Die Begriffe
Handlungsfähigkeit
Handlungsfähig ist, wer drei Dinge zusammen hat: er beherrscht sein Fach, er darf entscheiden und er weiß genug (Kompetenz, Autorität, Information). Fehlt eines davon, hilft auch das schnellste Werkzeug nichts. International heißt das Agency.
Ein Inhaber baut am Wochenende mit KI-Agenten Lösungen, an denen seine Teams unter der Woche scheitern. Er kann, er darf und er weiß genug. Seinen Teams fehlt meist etwas davon.
Entscheidung
Das Was und Warum, nicht das Wie. Handlungsfähigkeit zeigt sich an der Entscheidung, entsteht aber davor: dort, wo Kompetenz, Autorität und Information zusammenkommen. Wo das Was aufhört und das Wie anfängt, ist in vielen Organisationen offen. Diese Grenze zu ziehen, ist selbst eine Entscheidung, die jemand treffen muss.
Strategie
Keine Vision-Statements. Strategie heißt: ehrlich diagnostizieren, eine Politik wählen, die Kräfte bündelt, und daraus Handlungen ableiten, die zusammenpassen.
Autorität
Wer entscheiden darf, tut es nicht automatisch auch. Die Lücke zwischen formaler und gelebter Autorität fällt schnell auf, ist aber schwer in Worte zu fassen.
Teil 1
Beobachtungen
Was wir sehen
1 KI-Agenten verschieben den Engpass.
Der Engpass heißt nicht mehr Execution-Geschwindigkeit, er heißt Handlungsfähigkeit. Kompetenz, Autorität und Information liegen aber aktuell selten bei derselben Person oder im selben Team.
2 Agile Werte werden wertvoller, agile Artefakte ändern sich.
Sprint, Daily, Retro und Backlog werden volatil, wenn die Execution sofort geschieht. Die Werte dahinter bleiben und tragen jetzt den Wandel.
3 Teams schrumpfen. Verantwortung wächst.
Eine Person verantwortet heute Scope, für den früher acht Leute nötig waren. Karrierepfade und Vergütung sind dem bisher nicht gefolgt.
4 Rollengrenzen lösen sich auf.
Entwickler- und Produktrollen überlappen: Product Manager analysieren Bugs im Code, Entwickler sprechen mit Nutzern. Domänenwissen und Raum für Experimente sind dafür die Voraussetzung.
5 Führung steht vor einer existenziellen Frage.
Wenn Teams sich schneller bewegen, als die Hierarchie sie steuern kann, muss Führung etwas anderes werden, als sie war. Was genau, weiß noch niemand.
6 Der Chef baut alleine.
Unter Druck greifen Führungskräfte zum KI-Agenten und bauen alleine, statt ihre Teams dorthin zu bringen, wo sie es selbst können. Was passiert, wenn diese eine Person Urlaub macht, fragt niemand.
7 Die KI-Kluft spaltet Organisationen von innen.
Die einen probieren, die anderen erstarren. Das liegt selten am Charakter: meist fehlt eines der drei oder die alte Rolle trägt nicht mehr.
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. Die Voraussetzungen anderswo tragen das nicht.
9 Das Tempo sprengt feste Review-Rhythmen.
Continuous Delivery hatten wir schon, neu ist die Schlagzahl: Sie steigt so weit, dass ein Review alle zwei Wochen zu spät kommt.
10 Zwischen Idee und Code entsteht eine neue Artefaktebene.
Diese Ebene hat ihre eigene Logik. Wer entwickelt, baut zunehmend die Maschine, die das Programm baut.
11 Vibe-Prototypen treffen die Desirability, nicht die Feasibility.
Was im schnellen Prototyp entsteht, zeigt, ob etwas gewollt ist. Ob es technisch und an den Daten trägt, bleibt offen. Dieses Wissen muss auf anderem Weg in den Prozess.
12 Der Fachexperte bleibt nur auf Zeit im Team.
Fachlich führt ihn seine eigene Abteilung. Ins Produktteam kommt er für ein Projekt und geht, sobald die Software steht. Auf so eine Bindung passt kein fester, synchroner Termin.
13 Der Fachbereich kommt nicht mehr mit.
Die Teams liefern schneller, als der Fachbereich die Software aufnehmen kann, und vieles bleibt als 80-Prozent-Lösung liegen. Der Engpass entsteht so auch am anderen Ende: bei Adoption und Distribution.
Die Diagnose
Was folgt aus dem, was wir sehen?
Wenn Bauen billig wird, entscheidet der Schritt davor: zu wissen, was zu bauen ist, und handeln zu können. Der Druck kommt aus mehreren Richtungen. Kleine, stark gehebelte Teams bauen einen großen Teil etablierter Produkte zu einem Bruchteil des Preises nach. Was diese Produkte jahrelang geschützt hat, reicht nicht mehr. Dazu kommen ein verunsicherter Markt und die vielen vermarkteten Erfolgsgeschichten, die den Eindruck verstärken, alle anderen seien schon weiter. Zugleich baut sich der Fachbereich eigene Lösungen, am offiziellen Prozess vorbei.
Das trifft auch uns. Vorbei ist die Sonderkonjunktur, in der Digitalagenturen und Softwarehäuser am Ende immer gerade genug auslieferten, um ihr Budget zu verdienen.
Die einen stellen nun offensiv um, die anderen warten ab. Ein einzelnes Modell gibt es nicht, entscheidend ist, welche Antwort zur eigenen Lage passt.
Agentische Entwicklung hebelt vor allem die, die ihre Hausaufgaben gemacht haben. Wo Tests, klare Muster und sauberes Produktverständnis fehlen, vervielfacht sie den Schaden. Und wer nicht messen kann, wo er steht, kann nicht auf ein Ergebnis hinsteuern. Für viele heißt der erste Schritt deshalb: erst die Basis, dann die Agenten.
Wir sind uns nicht einig, ob dieser Druck neu ist oder derselbe wie bei früheren Umbrüchen, nur größer.
Teil 2
Hypothesen
Was wir glauben
Wir haben noch keine Antworten, aber Hypothesen. Jede stützt einen Punkt im Framework.
H1 Richtet eure Organisation auf Handlungsfähigkeit aus, nicht auf Execution.
An Entscheidungen sieht man, wer handlungsfähig ist. Wer nur bestehende Prozesse umbaut, kuriert am Symptom.
H2 Handlungsfähigkeit muss sich verteilen, sonst hängt die Organisation an einer Person.
Wenn Kompetenz, Autorität und Information nur in einer Person zusammenkommen, sieht das Unternehmen nur so weit wie diese eine Person. Die eigentliche Aufgabe ist, Teams selbst handlungsfähig zu machen und ihnen Verantwortung für ihr Produkt zu geben.
H3 Autonomie ohne klaren Rahmen erzeugt nur schnelleres Durcheinander.
Den Rahmen setzt die Strategie: ehrliche Diagnose, leitende Politik, kohärente Handlungen. Ohne ihn bewegen sich Teams zwar schnell, aber nicht in dieselbe Richtung.
H4 Wenn eine Entscheidung mehrere Bereiche berührt, muss klar sein, wer sie trägt.
Die Entscheidung gehört in die kleinste Einheit, die alle Folgen noch überblickt. Reicht die Wirkung weiter, muss jemand sie ausdrücklich übernehmen.
H5 Frustration ist ein Signal.
Wo Menschen sich aufreiben, liegt meist ein Engpass, den die offizielle Geschichte nicht sehen will. Frustration zeigt euch, wo eines der drei fehlt.
H6 Der Weg ist iterativ, von unten nach oben.
Es gibt keinen Masterplan. Es geht Engpass für Engpass, und wer den nächsten benennen kann, gibt die Richtung vor.
H7 Die Chance heißt Wachstum.
Mit denselben Menschen ein Vielfaches erreichen. Das ist eine Lernreise: wir sammeln neue Erfahrungen und verbessern unser Vorgehen Stück für Stück.
H8 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.
H9 Bindet die Fachlichkeit asynchron ein.
Der Fachexperte gehört nie ganz zum Team. Sein Wissen erreicht euch in kurzen, entkoppelten Schleifen besser als in festen Terminen.
H10 Treibt die Einführung und prüft ihre Wirkung.
Fertige Software ist noch kein Wert. Wer schneller baut, muss sie bewusst zu den Nutzern bringen und prüfen, ob sie ankommt.
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 Product Manager. 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 im Fachexperten 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.
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.