Präambel
Worum es geht
Die Eröffnung
Sprachmodelle sind ein technischer Umbruch in der Software- und Produktentwicklung. Etablierte Arbeitsweisen, Rollen und Artefakte verlieren ihre Selbstverständlichkeit. Niemand weiß im Detail, was davon tragfähig bleibt.
Wir überspielen diese Verunsicherung nicht. Was hier steht, sind erste Vorschläge, die sich in unserer eigenen Praxis als gangbare Wege abzeichnen. Keine Heilsversprechen, keine Antworten. Hypothesen.
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.
Entscheidung
Das Was und Warum, nicht das Wie. An der Entscheidung wird Handlungsfähigkeit sichtbar. 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. Die Lücke zwischen formaler und gelebter Autorität fällt schnell auf, ist aber schwer in Worte zu fassen. Sie ist das erste Symptom.
Teil 1
Was wir sehen
Beobachtungen aus unserer Praxis in der Software-Entwicklung. Jede steht für eine Hypothese, die im Framework wirksam wird.
1 Bauen ist billig geworden.
Eine Entwicklerin liefert an einem Tag, wofür ein Team früher zwei Wochen gebraucht hat. Der Engpass liegt nicht mehr in der Umsetzung.
2 Die Arbeit verschiebt sich vom Code zur Umgebung.
Die meiste Zeit fließt nicht mehr ins Schreiben von Code, sondern ins Konsistenthalten der Umgebung, aus der die Agenten bauen.
3 Agenten folgen Mustern.
Sie liefern verlässlich, wo klare Muster und Tests sie führen, und driften, wo der Code uneinheitlich ist. Schlechter Code braucht mehr Steuerung.
4 Die Beschreibung wird zum Nadelöhr.
Unscharf beschriebene Stories erzeugen unscharfe Ergebnisse. Was am Eingang ungenau ist, wird am Ausgang nicht besser.
5 Wer Stakeholder nicht erreicht, baut am Bedarf vorbei.
Teams ohne erreichbare Fachlichkeit bauen schneller das Falsche als je zuvor. Das Tempo deckt den Fehler nicht zu, es vergrößert ihn.
6 Rollengrenzen lösen sich auf.
Product-Engineers analysieren Bugs im Code, Entwickler sprechen mit Usern. Die alte Trennung zwischen Produkt und Entwicklung trägt nicht mehr.
7 Teams schrumpfen, Verantwortung wächst.
Eine Person verantwortet Scope, für den früher ein ganzes Team stand. Karrierepfade und Vergütung berücksichtigen das bisher nicht.
8 Tasks verschwinden, die Story bleibt.
Die kleinteilige Umsetzung wandert in die Agenten. Was als Artefakt zählt, ist die Story und ihr Wert, nicht der Task.
9 Ohne Rückkopplung kippt Tempo in Abbau.
Fehlt die schnelle Schleife zur Fachabteilung, wird das gewonnene Tempo zum Rationalisierungsinstrument statt zum Hebel.
Teil 2
Was wir glauben
Locker gehalten und rigoros geprüft. Jede Hypothese stützt einen Eckpfeiler im Framework; sie ist geordnet nach dessen Schnitt: Factory, Rollen, Kadenzen, Artefakte.
H1 Baut die Factory, nicht das Feature.
Wer agentisch entwickelt, baut zuerst die Umgebung, die eine Story selbständig umsetzt. Das Feature fällt dann ab.
H2 Konsistenz steuert die Factory stärker als Vorgaben.
Sprachmodelle vervielfältigen, was sie vorfinden. Klare Muster und Tests lenken sie, uneinheitlicher Code treibt sie auseinander.
H3 Wer baut, kümmert sich um die Factory, nicht um die einzelne Story.
Der Entwicklerfokus verschiebt sich von der Umsetzung zur Maschine, die umsetzt. Dorthin gehört das tiefe Engineering-Wissen.
H4 Klare Sprache wird zur Kernkompetenz.
Wer die Factory füttert, gewinnt oder verliert an der Präzision der Beschreibung. Im Zeitalter der Sprachmodelle ist Sprache das Werkzeug.
H5 Ohne Kunde vor Ort trägt das Modell nicht.
Die Stakeholder müssen erreichbar sein. Sonst beschleunigt die Factory nur den Irrweg.
H6 Die Rollen schneiden sich um die Factory neu, nicht entlang der alten Grenzen.
Entwicklung und Produkt rücken zusammen, und weniger Menschen tragen mehr Scope. Die Strukturen drum herum, Karrierepfade und Vergütung, müssen nachziehen.
H7 Bei hohem Tempo ist Tempo herausnehmen der wertvollere Schritt.
Die Reflexion über die Agentenläufe schlägt die nächste Runde Geschwindigkeit. Kleine Teams brauchen dafür weniger formale Rhythmen.
H8 Die Artefakte werden gröber, nicht feiner.
Was früher Task war, wird Story. Das Epic steigt vom Nice-to-have zum tragenden Artefakt auf.
H9 Die Rückkopplung zur Fachabteilung entscheidet, ob Tempo nützt.
Ohne schnelle Schleife zum Bedarf wird agentische Entwicklung zum Rationalisierungsinstrument. Mit ihr wird sie zum Hebel.
Teil 3
Das Framework
Hier liegt der Schwerpunkt. Das Framework ist eine Sammlung von Referenzmustern, keine vorschreibende Methode. Wo uns noch Substanz fehlt, lassen wir den Platz leer, statt ihn mit verfrühten Antworten zu füllen.
Der aktuelle Stand bezieht sich auf die Software-Entwicklung. Dort ist der Umbruch am größten, und dort liegt unsere tiefste Erfahrung.
Zielgruppe
Produkt- und Tech-Organisationen mit Software-Legacy. Mittelständische und große Unternehmen. Globale Konzerne und Startups schließen wir aus.
Der Einstieg führt über die Software-Entwicklung, nicht über das Geschäftsmodell. Die Frage „Wie baue ich heute ein Unternehmen auf?“ beantwortet hycle nicht. Die Frage „Wie organisiere ich den Prozess rund um die Software-Entwicklung?“ schon.
Factory
Aus Produktsicht sehen wir drei Factories: eine Ideation Factory, eine Software Factory und eine Validation Factory. Wir arbeiten zuerst an der Mitte.
Software Factory
Der Nordstern ist eine Factory, die eine Story selbständig implementiert. Sie ist das eigentliche Bauwerk; das einzelne Feature fällt daraus ab. Das ist nicht trivial, und hier sind unsere Erfahrungen am weitesten.
Ideation und Validation
Beide Factories rahmen die Software Factory ein. Wir beschreiben sie später, wenn wir mehr dazu sagen können. Die folgenden Rollen, Kadenzen und Artefakte beziehen sich vorerst auf die Software Factory.
Rollen
Factory-Engineer
Baut und wartet die Factory, Plattform und Enabling. Mit der einzelnen Story hat er nichts zu tun: stimmt das Ergebnis nicht, ändert sich etwas an der Factory, nicht an der Story. Er sorgt dafür, dass dasselbe herauskommt, egal wer baut. Das verlangt viel Engineering-Wissen und Applikationsarchitektur, eine abstraktere Art, Software zu entwickeln. Die Rolle wandert: anfangs in die Teams vervielfältigt für Tempo, später als Plattform extrahiert, langfristig nur noch in besonderen Situationen konsultiert.
Product-Engineer
Füttert die Factory und verantwortet die Implementierung der Story samt ihrer technischen Teile. Kernkompetenz ist klare Kommunikation; Sprache wird im Zeitalter der Sprachmodelle immer wichtiger.
Produkt-Verantwortlicher
Führt die Kommunikation mit Stakeholdern und Fachbereich und verantwortet die Epics.
Kunde vor Ort
Grundvoraussetzung, wie schon in XP. Ohne diesen Bezug funktioniert das Modell nicht. Mindestens müssen die Stakeholder verfügbar sein.
Kadenzen
Natürliche Rhythmen. Kleinere Teams brauchen weniger starke Synchronisation; vieles läuft informell.
Tägliche Synchronisation mit der Fachlichkeit
Zwei feste Punkte pro Tag funktionieren gut.
Wöchentliches Retro-Treffen
Technisch-fachliche Reflexion des Arbeitsprozesses: Was hat geklappt, was nicht, was haben wir gelernt, was ausprobiert. Bei hoher Geschwindigkeit nehmen wir hier bewusst Tempo heraus.
Review
Etablieren wir bewusst nicht. In dieser Form ergibt es für uns keinen Sinn.
Artefakte
Die Granularität wächst. Was früher fein zerlegt wurde, fasst sich jetzt gröber. Pflichtenhefte kommen wieder in Mode.
Epic
Die Schnittstelle zwischen Produkt und Engineering, auf der die Kommunikation mit dem Fachbereich läuft, auf Ebene der Oberfläche. Das Epic wird aufgewertet: vom Nice-to-have zum echten Artefakt im Prozess.
Story
Die Schnittstelle zur Factory. Sie verschiebt sich zum Entwickler: Was vorher ein Task war, wird jetzt zur Story, ein eigener Story-Breakdown entsteht. Anders als ein Task muss eine Story wertstiftend sein, und ihre Akzeptanzkriterien entstehen mit ihr.
Task
Die Tasks macht der Agent.
Sonstiges
Sprachmodelle sind komplexe Mustererkenner. Gibt es wenige konsistente Muster im Code, vervielfältigen sie diese. Schlechter Code braucht entsprechend mehr Steuerung; Musterkonsistenz und Tests sind die größte Hilfe.
Ohne schnelle Rückkopplungsschleife zur Fachabteilung kann agentische Software-Entwicklung zum Rationalisierungsinstrument werden, statt zum Hebel.
Offene Frage. Pflichtenhefte (PID): finden wir das gut?
Die Sprache (das operative Vokabular) und Walk the Talk folgen, sobald die Substanz steht. Weitere Bausteine kommen dazu.
Abgrenzung
Was hycle nicht ist
Kein Rollout am Montagmorgen. Es braucht weiter Zyklen und menschlichen Austausch. Wie das konkret aussieht, wissen wir noch nicht. Verordnen lässt es sich nicht.
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, entwickeln Menschen und KI in ihrem Kontext. Das ist eure Arbeit.
Nicht fertig. Eine Einladung, gemeinsam zu suchen, was funktioniert.
Call for Participation
Was wir suchen
hycle ist aus unseren eigenen Erfahrungen entstanden. Es ist ein Diskussionsangebot, kein abgeschlossenes Modell, Work in Progress. Eure Erfahrungen sind dabei wichtig, und wir wollen sie hören.
Drei Fragen
Was hat bei euch funktioniert?
Welches Muster trägt, welche Kadenz hält, welche Rolle greift? Schreibt es so, dass es jemand übernehmen kann.
Wo erkennt ihr Keimformen neuer Muster?
Wo zeichnet sich etwas ab, das noch keinen Namen hat? Auch ein halber Befund hilft.
Was hat nicht geklappt?
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.