Start / Seminare / Spec-driven & Agentic Software Development

Modul

Eigener Team-Workflow

3 Kapitel in diesem Modul-Video · Laufzeit

Vertonung mit synthetischer Stimme · Inhalte redaktionell verantwortet · © 2026 HECKER CONSULTING, alle Rechte vorbehalten

Transkript

Der gesprochene Text dieses Moduls zum Mitlesen, Überfliegen und Durchsuchen. Ein Klick auf einen Zeitstempel springt an die Stelle im Video.

Eigener Team-Workflow

0:00 Wir sind am letzten Modul angekommen, und es ist das einzige, in dem Sie fast ausschließlich selbst arbeiten. Zwei Tage lang haben wir Bausteine zusammengetragen: Kontext, Spezifikation, Architektur, Zerlegung, Build, Review, Subagents, Rechte. Jetzt bauen Sie daraus etwas, das zu Ihrem Team passt. Und weil das die Stelle ist, an der Seminare gern in Wunschdenken kippen, sage ich den wichtigsten Satz gleich zu Beginn: Der beste Prozess ist der kleinste, den Ihr Team tatsächlich einhält.

Eigener Team-Workflow

0:30 Drei Kapitel, dann sind wir durch. Zuerst das Prozessdesign mit neun Festlegungen, die einen Workflow tragen. Dann der Agentic Development Canvas — acht Felder auf einer Seite, das eigentliche Ergebnis dieses Seminars. Und zum Schluss die Frage, wie man so etwas einführt, ohne dass es nach vier Wochen wieder verschwunden ist.

0:50 Am Ende halten Sie ein Blatt in der Hand, mit dem Sie am Montag anfangen können.

Prozessdesign

0:55 Beginnen wir mit den Fragen, die ein Workflow beantworten muss. Es sind neun, und sie sind bewusst als Fragen formuliert — denn eine Frage, die Sie nicht beantworten, beantwortet später jemand anderes. Meistens der, der gerade unter Zeitdruck steht. Und dann fällt die Antwort selten so aus, wie Sie sie in Ruhe getroffen hätten.

1:15 Neun Fragen, vom Eingang einer Anforderung bis zur Eskalation. Das Entscheidende ist die Form der Antwort: Jede Antwort ist eine Festlegung, keine Absichtserklärung. Sie benennt ein Artefakt, eine Regel oder einen Namen. Der Unterschied klingt spitzfindig und ist er nicht. „Wir achten auf gute Tests" ist eine Absicht. „Je Akzeptanzkriterium ein Test, Sicherheitstests von Hand" ist eine Festlegung — man kann sie prüfen, man kann gegen sie verstoßen, und man kann sie später ändern.

1:45 Absichten kann man nichts davon. Neun Zeilen — gehen Sie sie einmal in Gedanken für Ihr Team durch, und achten Sie darauf, bei welchen Sie zögern. Wo geht eine Anforderung ein? Was steht mindestens in einer Spezifikation? Was darf ein Agent tun? Wer gibt frei? Wann wird abgebrochen? Die Fußzeile ist der Grund, warum diese Liste überhaupt existiert: Wo eine Antwort fehlt, entscheidet später der, der gerade dasitzt.

2:12 Das ist nicht per se schlimm — es ist nur nicht das, was Sie im Nachhinein als Ihren Prozess beschreiben würden. Vier Gründe für Bescheidenheit am Anfang. Ein knapper Prozess wird eingehalten, ein vollständiger umgangen — das ist die wichtigste Beobachtung aus Projekten. Jede Festlegung kostet Zeit im Alltag und muss sich rechnen. Lücken zeigen sich im Betrieb schneller als am Whiteboard, weshalb sich langes Vorabdesign selten lohnt.

2:38 Und der vierte Punkt ist der, den man aus Erfahrung lernt: Nachschärfen ist leichter, als eine Regel wieder abzuschaffen. Regeln haben eine Beharrungskraft, auch wenn ihr Grund längst weggefallen ist. Der erste Punkt beschreibt das häufigste Muster gescheiterter Prozesse: Er beschreibt den Idealfall und schweigt zum Eilfall.

2:57 Dabei entscheidet sich genau im Eilfall, ob ein Prozess trägt. Der zweite ist die Rollenfalle, die wir im Sicherheitsmodul schon hatten. Der dritte betrifft Regeln ohne Grund — sie fallen beim ersten Termindruck, weil niemand sie verteidigen kann. Und der vierte ist der, den ich am häufigsten sehe: Der Workflow lebt in einer Präsentation und nicht im Repository. Dort liest ihn niemand mehr.

Der Agentic Development Canvas

3:21 Kommen wir zum Ergebnis dieses Seminars. Der Canvas fasst alles, was wir zwei Tage lang besprochen haben, auf einer einzigen Seite zusammen. Acht Felder — und die Beschränkung auf eine Seite ist keine Kosmetik, sondern die eigentliche Disziplin. Denn was auf eine Seite passt, wird gelesen; was länger ist, wird abgelegt.

3:41 Acht Felder: Aufgabentypen und Risikoklassen, erforderliche Kontextartefakte, zugelassene Werkzeuge, Skills und Abläufe, Test- und Reviewregeln, Berechtigungsgrenzen, menschliche Verantwortlichkeiten und Messgrößen. Sie erkennen darin die zwölf Module wieder, verdichtet auf das, was man nachschlagen muss. Warum eine Seite?

4:01 Weil ein Dokument, das man scrollen muss, nicht mehr überflogen wird — und ein Prozess, den man nicht überfliegen kann, wird nicht benutzt. Die Beschränkung erzwingt außerdem Entscheidungen. Es passt nicht alles hin, also muss etwas wichtiger sein als anderes. Sie sehen hier das Gerüst — acht Zeilen, jede mit einem Doppelpunkt und einer knappen Antwort.

4:23 Das ist kein Formular, das man ausfüllt, sondern eine Struktur, die man mit den eigenen Entscheidungen füllt. Achten Sie auf die vorletzte Zeile: Menschen. Dort stehen Namen, nicht Rollen — dieselbe Regel wie in der Freigabematrix. Und beachten Sie die Fußzeile: Der Canvas gehört ins Repository, nicht in eine Präsentation.

4:43 Neben die Regeldatei, wo ihn liest, wer im Projekt arbeitet. Alles andere ist gut gemeinte Ablage. Über Messgrößen wird viel Unsinn geschrieben, deshalb hier vier, die tatsächlich etwas aussagen. Der Anteil der Änderungen, die nach dem Merge nachgebessert werden — er misst, ob Ihre Prüfung greift. Die Zeit vom Eingang bis zur Freigabe — sie misst, ob der Prozess trägt oder bremst.

5:07 Der Anteil der Reviewbefunde, die sich als echter Defekt bestätigen — er misst die Qualität der Prüfung selbst. Und der Anteil der Sitzungen ohne Rückfrage — er misst, wie gut Ihre Vorbereitung ist. Was Sie nicht messen sollten: erzeugte Codezeilen. Jetzt sind Sie dran, und das ist die Hauptübung dieses Seminars. Füllen Sie alle acht Felder mit konkreten Festlegungen statt mit Absichten.

5:31 Nehmen Sie sich die Zeit, denn dieses Blatt nehmen Sie mit. Der Hinweis auf der Folie ist die eigentliche Qualitätsprüfung: Gehen Sie am Ende ein echtes Vorhaben der letzten Wochen durch und fragen Sie sich, ob der Canvas es abgedeckt hätte. Wenn nicht — wo hat er geschwiegen? Genau dort fehlt eine Festlegung, und Sie haben sie gefunden, bevor es darauf ankam.

Einführung im Team

5:52 Bleibt die letzte Frage, und sie entscheidet über alles andere: Wie führt man so etwas ein, ohne dass es nach vier Wochen wieder verschwunden ist? Die Antwort ist unspektakulär und hat sich in vielen Teams bewährt. Sie besteht vor allem darin, nichts anzukündigen, sondern etwas auszuprobieren — und danach ehrlich hinzusehen.

6:12 Ein Workflow wird nicht angekündigt, sondern an einem echten Vorhaben erprobt. Das ist der ganze Kern. Eine Ankündigung erzeugt Widerstand und Diskussion über Hypothesen; ein Durchlauf erzeugt Erfahrung, über die man reden kann. Danach entscheidet ein kurzer Rückblick, welche Festlegung bleibt, welche wegfällt und welche gefehlt hat. Beachten Sie den letzten Teil: Auch das Streichen gehört dazu.

6:35 Ein Prozess, aus dem nach dem ersten Durchlauf nichts entfernt wird, wurde nicht ernsthaft geprüft. Fünf Schritte, und der erste ist eine Weichenstellung: ein Vorhaben mittlerer Größe. Nicht das riskanteste, denn dort ist kein Platz zum Lernen. Aber auch nicht das kleinste, weil dort der Prozess nichts zu tun bekommt. Dann kommen Canvas und Artefakte ins Repository, das Vorhaben wird vollständig nach dem Workflow durchgezogen, und danach der Rückblick: was half, was störte, was fehlte.

7:06 Erst danach ausweiten. Die Fußzeile sagt es deutlich: Der erste Durchlauf dient dem Lernen, nicht dem Beweis, dass der Prozess stimmt. Vier letzte Fallen. Die Einführung startet mit dem riskantesten Vorhaben — dann steht der Prozess unter Erfolgsdruck und wird beim ersten Problem als Ursache verdächtigt. Der Rückblick entfällt, weil das Ergebnis ja gestimmt hat; damit verlieren Sie genau die Erfahrung, für die Sie den Durchlauf gemacht haben.

7:32 Der Canvas wird zentral vorgegeben statt vom Team erarbeitet — dann ist es eine Vorschrift und kein Werkzeug. Und Regeln werden ergänzt, aber nie gestrichen. Am Ende steht ein Prozess, den niemand mehr überblickt.

Danke!

7:45 Damit sind wir am Ende. Drei Dinge, die ich Ihnen mitgeben möchte. Der Workflow gehört ins Repository, nicht in die Ablage — dort wirkt er, sonst nirgends. Fangen Sie klein an, an einem echten Vorhaben, und schärfen Sie danach nach. Und die menschliche Freigabe bleibt der Kern des Ganzen, nicht die Ausnahme davon. Die Werkzeuge werden sich ändern, vermutlich schneller, als uns lieb ist.

8:09 Der Prozess, den Sie heute gebaut haben, hängt aber nicht an ihnen — sondern an Artefakten und an Entscheidungen, die Menschen treffen. Vielen Dank für zwei intensive Tage.

Lieber mit Trainer? Dieses Modul ist Teil unserer Team-Schulungen — mit Übungen, Ihrem eigenen Code und Fragen, die ein Video nicht beantwortet. Mehr erfahren →