Die Kernbeobachtung
Alle paar Jahrzehnte eliminiert eine neue Technologie Beschränkungen, um die Organisationen ihre Strukturen und Prozesse gebaut haben. Das sehen wir gerade wieder: Agentische Softwareentwicklung verschiebt den bisherigen Engpass von der Execution zu der 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. Damit verbergen sie das Problem, statt es zu lösen.
Der Name
Manfred Eigen hat 1971 die Hyperzyklen beschrieben: gekoppelte Kreisläufe, die sich gegenseitig tragen. An der Grenze zwischen chemischer und biologischer Evolution schaffen sie die Voraussetzungen für Leben, also Replikation, Variation und Selektion. Sie erzeugen das Leben nicht, sie machen es möglich.
Wir vermuten, dass Organisationen vor einem ähnlichen Übergang stehen: von prozessgetrieben hin zu entscheidungsgetrieben. Wir nennen das hycle, den hyper cycle.
Im Deutschen klingt das Wort nach heikel. Das ist beabsichtigt.
Und ja, hype cycle steckt auch darin. Wir nehmen das als Erinnerung daran, worum es bei hycle geht: um das, was bleibt, wenn der Hype vorbei ist.
Einen Namen haben wir verworfen: MURCS, Scrum rückwärts. Im Deutschen liest sich das wie Murks. Heikel war die ehrlichere Wahl.
Die Begriffe
Handlungsfähigkeit
Handeln kann, wer drei Dinge zusammen hat: er weiß genug, er darf und er kann (Kompetenz, Autorität, Information). Fehlt eine der drei, hilft auch das schnellste Werkzeug nichts. International läuft das unter Agency; wir nennen es Handlungsfähigkeit.
Ein Inhaber baut am Wochenende mit KI-Agenten Lösungen, an denen seine Teams unter der Woche scheitern. Er weiß genug, er darf, er kann. Seine Teams können das eine oder andere, selten alles zusammen.
Entscheidung
Das Was und Warum, nicht das Wie. An der Entscheidung wird Handlungsfähigkeit sichtbar, aber sie entsteht davor: dort, wo Kompetenz, Autorität und Information zusammenkommen. Wo das Was aufhört und das Wie anfängt, ist in den meisten Organisationen offen, und genau das ist eine der ersten Entscheidungen, die jemand bewusst 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, ist nicht automatisch, wer es auch tut. Autorität ist eine der drei Dimensionen von Handlungsfähigkeit, und 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 ist nicht mehr Execution-Geschwindigkeit, sondern 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 werden volatil.
Sprint, Daily, Retro, Backlog werden volatil, wenn die Execution sofort geschieht. Werte und Haltung dahinter bleiben, und sie tragen jetzt den Wandel.
3 Teams schrumpfen. Verantwortung wächst.
Eine Person verantwortet heute Scope, für den früher acht Leute gebraucht wurden. Die Strukturen drum herum berücksichtigen das bisher aber weder bei Karrierepfaden noch bei der Vergütung.
4 Rollengrenzen lösen sich auf.
Entwicklung und Produktrollen überlappen: PMs analysieren Bugs im Code, Entwickler sprechen mit Usern. Domänenwissen und Raum für Experimente sind dafür die Voraussetzung.
5 Die Koordinationsebene 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 naive Reflex: Führung baut Solo.
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.
In derselben Organisation spalten sich die Mitarbeitenden: die einen probieren, die anderen erstarren. Das liegt selten am Charakter, meist fehlt eine der drei Dimensionen oder die alte Rolle trägt nicht mehr.
Die Diagnose
Eine Beobachtung ist noch keine Diagnose. Was folgt aus dem, was wir sehen?
Wenn Bauen billig wird, entscheidet, was davor liegt: zu wissen, was zu bauen ist, und handeln zu können. Der Druck dazu kommt von außen. Kleine, stark gehebelte Teams bauen einen großen Teil etablierter Produkte zu einem Bruchteil des Preises nach, und Burggräben, die jahrelang gehalten haben, bröckeln. Zugleich automatisiert der Fachbereich seine eigenen Probleme, am offiziellen Prozess vorbei.
Das trifft auch uns. Die Sonderkonjunktur, in der Digitalagenturen und Softwarehäuser am Ende genug auslieferten, um ihr Budget zu verdienen, ist vorbei. Derselbe Druck, der die Kunden zur Veränderung zwingt, gilt für die, die ihnen Software bauen.
Die Reaktionen laufen weit auseinander. Die einen stellen offensiv um, die anderen warten ab. Ein einzelnes Modell gibt es nicht, eher ein Spektrum, und die Frage ist, welche Antwort zur eigenen Lage passt.
Ehrlich bleibt: 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 hin steuern. Für viele heißt der erste Schritt deshalb: erst die Basis, dann die Agenten.
Ob dieser Druck neu ist oder derselbe wie bei früheren Umbrüchen, nur größer, darüber sind wir uns nicht einig.
Teil 2
Hypothesen
Was wir glauben
Wir haben noch keine Antworten, aber wir haben erste Hypothesen.
H1 Richtet eure Organisation auf Handlungsfähigkeit aus, nicht auf Execution.
An Entscheidungen sieht man, wer handlungsfähig ist. Die Handlungsfähigkeit entsteht dort, wo Kompetenz, Autorität und Information zusammenkommen. Wer nur bestehende Prozesse umbaut, optimiert am Symptom, nicht an der Ursache.
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, fährt das Unternehmen auf Sicht dieser Einen. Teams dahin zu bringen, wo sie selbst handlungsfähig sind, ist die eigentliche Aufgabe.
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.
Verantwortung sitzt dort, wo die Wirkung zuerst über die eigene Einheit hinausreicht. Wer den größten Teil der Folgen trägt, muss auch die Entscheidung tragen.
H5 Frustration ist ein Signal.
Hört hin. Wo Menschen sich aufreiben, liegt meist ein Engpass, den die offizielle Geschichte verleugnet. Frustration zeigt euch, wo eine der drei Dimensionen 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.
Teil 3
Framework
Die agilen Werte tragen weiter, die Artefakte ändern sich. Darunter zeichnet sich ein Betriebsmodell ab: wer welche Rolle hat, in welchen Rhythmen gearbeitet wird, 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. 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. Die Frage ist nicht, wie man heute ein Unternehmen aufbaut, sondern 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. Wo Produkt- und Tech-Organisation genau anfängt, ist noch nicht scharf umrissen.
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 die offene Frage.
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, und auch die ist nicht trivial.
Validation
Prüfen, ob das, was erreicht werden sollte, auch wirklich erreicht wurde.
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, denn ein nicht-deterministisches System muss erst lernen, sich verlässlich zu verhalten.
Eine Organisation will, dass dieselbe Aufgabe dasselbe Ergebnis bringt, egal wer sie baut. Also konsolidiert und standardisiert sie die Factory, während sich darunter noch alles bewegt. Sie sitzt dabei auf beiden Ebenen: zentrale Vorgaben wie Zertifizierungen gehören in den kodifizierten Prozess, die Teams brauchen trotzdem eigenen Spielraum. Die gemeinsame Plattform entsteht durch Extraktion, erst lokal gelöst, dann herausgezogen, was für alle taugt.
Rollen
Drei Rollen zeichnen sich ab, dazu eine Voraussetzung.
Product Lead
Verantwortet die Epics und spricht mit Stakeholdern und Fachbereich. Er klärt, was gebaut wird und warum.
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, eine abstraktere Art, Software zu entwickeln. Er sorgt dafür, dass identisch gebaut wird, egal wer baut. Mit der einzelnen Story hat er nichts zu tun: er ist der Mechaniker, der an der Factory schraubt, wenn das Ergebnis nicht stimmt. Anfangs geht er in die Teams, später zieht er sich heraus und wird nur in besonderen Fällen gerufen.
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.
Wo der Schnitt zwischen Product Lead und Product-Engineer verläuft und wie weit die Factory-Rolle reicht, ist noch nicht ausverhandelt.
Kadenzen
Die Rhythmen sind natürliche Rhythmen: einmal am Tag, einmal in der Woche. Kleine Teams brauchen davon weniger, vieles läuft bei ihnen informell.
Tägliche Synchronisation
Zwei Punkte am Tag funktionieren gut. Aus dem alten Daily wird die Reflexion über die Agentenläufe von gestern, also was sie gebaut haben, wie gut sie geführt waren und wo man nachjustieren muss.
Wöchentliche Retro
Bei hohem Tempo nimmt es bewusst Geschwindigkeit heraus und schaut auf den Arbeitsprozess, was geklappt hat und was nicht. Je paralleler gearbeitet wird, desto wichtiger wird dieser eine Punkt, der das Team wieder zusammenführt.
Review
Das klassische Review am Ende eines Zwei-Wochen-Zyklus trägt nicht mehr. Was an seine Stelle tritt, ist offen: mehrmals täglich ein Blick mit denen, die das Problem verstehen, oder das Ritual ganz streichen. Darüber sind wir uns noch nicht einig.
Artefakte
Die Artefakte werden gröber. Was früher eine Story war, ist jetzt ein Epic; was eine Task war, 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 arbeitet der Product Lead mit dem Fachbereich. Lange war das Epic ein Nice-to-have, jetzt ist es die kanonische Form: nichts kommt ohne Epic in den Prozess. Oft erzeugt erst das Epic den Outcome, die Stories darin sind Schritte dorthin.
Story
Die Schnittstelle zur Factory. Anders als eine Task muss eine Story für sich Wert stiften, ein eigenständiges Feature. Ihre Akzeptanzkriterien entstehen mit ihr, am besten als ausführbare Tests aus Sicht des Endkunden. Wo der Schnitt vom Epic zur Story fällt, im Produkt oder im Engineering, ist noch offen.
Task
Die macht der Agent. Für die Menschen spielt diese Ebene keine Rolle mehr.
Oft dreht sich die Reihenfolge um: erst ein aus Nutzersicht validierter Prototyp, daraus ein PRD, daraus die Epics und Stories. Und weil der Agent alles Unspezifizierte mit eigenen Annahmen füllt, muss der Input 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. Musterkonsistenz und Tests sind deshalb eine große Hilfe.
Kleine, klar geschnittene Aufgaben sind Risikomanagement: je enger der Auftrag, desto eher kommt heraus, was gemeint war. Die technische Detailplanung überlässt man dem Agenten bewusst 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 (PID) zurückkommen sollten.
Was hycle nicht ist
Kein Rollout am Montagmorgen. Wir glauben, dass es weiter Rhythmen und menschlichen Austausch braucht. Wie das konkret aussieht, wissen wir noch nicht. Inhalte lassen sich nicht von oben verordnen.
Kein Technologie-Framework. Keine vorgeschriebenen Tools, keine vorgeschriebenen Plattformen.
Nicht gegen Agile. Die Werte werden wertvoller, die Artefakte ändern sich. hycle baut auf agilen Werten auf, nicht gegen sie.
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 wie ein Tanker kaum steuern, da passen unsere Antworten oft nicht. Wir zielen auf die dazwischen: die schon etwas haben und selbst etwas ändern können.
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 im Pitch hängen bleibt: dass Bauen und Entscheiden zusammensitzen, dass das Backlog Features gegen Annahmen tauscht. Was offen bleibt: wie die menschliche Abstimmung stabil bleibt, 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.
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, die wir haben. Wenn ihr sie teilt, spart ihr anderen die gleiche Mauer.
Schreibt uns, was bei euch passiert. Wir lesen mit.