AI Practice Sprints

Was den Sprint tatsächlich trägt, ist eine strukturierte Wissensarchitektur. Wir nehmen das Wissen, auf dem ein Arbeitsablauf beruht, und ordnen es in vier Ebenen, die ein führendes KI-Modell verlässlich nutzen kann.

Semantisch. Das Fachwissen, das sich nicht von Fall zu Fall ändert: die Prinzipien, die Regeln, die Definitionen, die regulatorischen Rahmen, in denen die Arbeit stattfindet.

Prozedural. Wie das Team eine Aufgabe tatsächlich ausführt, Schritt für Schritt: die Reihenfolge der Handgriffe, die Abfolge der Entscheidungen, das Prozesswissen, das zwischen den Zeilen jeder Richtlinie lebt.

Referenzen. Die Vorlagen, Formate, Standardklauseln, Checklisten und unternehmenseigenen Artefakte, mit denen das Team ohnehin arbeitet.

Episodisch. Was vorher passiert ist: frühere Fälle und Entscheidungen, die Sammlung der Präzedenzfälle, vergangene Ergebnisse und die Überlegungen dahinter.

Das meiste davon existiert bereits irgendwo im Team, teils schriftlich, teils nur in den Köpfen. Der Sprint holt es heraus, strukturiert es und macht daraus etwas, das ein Modell im ganzen Team gleichbleibend nutzen kann.

Ein Sprint läuft in einem von zwei Zuschnitten, je nachdem, was das Team braucht.

Ein breiter Sprint. Das Material sind die täglichen Abläufe des ganzen Teams. Alle erfassen die Aufgaben, Prozesse und Entscheidungen, die ihre Woche füllen, und wir arbeiten das gemeinsam mit dem Team durch. Wo Abläufe sich überschneiden, deckt eine semantische Ebene alle ab; wo sie auseinandergehen, baut jede Person die eigene prozedurale Ebene darauf. Am Ende steht ein gemeinsames Betriebssystem, das das ganze Team nutzt, pflegt und weiter ausbaut.

Ein gerichteter Sprint. Das Material ist ein konkretes Problem oder ein konkreter Use Case: ein Ablauf mit bekannter Qualitätslücke, ein Prozess mit bekanntem Engpass, ein Entscheidungsmuster, das auf mehr Menschen skalieren muss. Die Arbeit läuft in zwei Teilen. Die ersten ein bis zwei Wochen gehen in die Kartierung des Ablaufs mit denen, die ihn heute betreiben, in das Zusammentragen der relevanten Richtlinien und Prozessdokumente, in das Sichtbarmachen der Entscheidungslogik, die erfahrene Menschen tatsächlich anwenden, in die Designentscheidungen, die den Bau prägen, und in einen Bauplan. Die folgenden zwei bis vier Wochen gehen in das Bauen der Komponenten, das Iterieren mit dem Team, das Testen an echten Fällen und einen strukturierten Pilotbetrieb. Heraus kommt ein funktionierender Ablauf, nachweislich end-to-end an echtem Material.

So oder so dauert die Zusammenarbeit drei bis sechs Wochen. Das schnellere Ende funktioniert, wenn das Team früh konzentriert Zeit investieren kann. Das längere Ende rechnet mit der Realität konkurrierender Prioritäten und ist das häufigere Tempo.

Ein Kickoff-Workshop eröffnet den Sprint: mindestens zwei Stunden, vier Stunden, wenn ein größerer Kreis zum selben Auftakt dazukommt. Alle verlassen diesen Kickoff mit einer strukturierten Erfassungsaufgabe und einer Frist.

Woche eins ist Erfassung und Architektur. Alle füllen ihre Erfassung aus, selbst gebaut oder mit unserer Vorlage, und halten Aufgaben, Prozesse und Entscheidungsmuster in einer Form fest, die sich zerlegen lässt. Die erste Bausitzung zeigt dem Team live, wie aus den eigenen Erfassungen strukturierte KI-Abläufe werden, am eigenen Material. Wir sehen uns bestehende Prompts und Assistenten an: Was funktioniert, bleibt. Was brüchig ist, wird sauber neu gebaut.

Woche zwei und drei sind Bau und Integration: strukturierte Wissensdateien für jede Ebene der Architektur, Prompt-Frameworks und Qualitätschecklisten für die priorisierten Abläufe. Jeder Ablauf entsteht an echten Fällen aus der tatsächlichen Arbeit des Teams, nicht an hypothetischen Übungen. Unterstützung läuft durchgehend: Bausitzungen mit dem ganzen Team, Einzelcoaching für alle, die hängen, asynchrones Feedback auf Zwischenstände.

Durchgehend lernt das Team, den Kreis zu schließen. Wenn ein KI-Ergebnis falsch ist, lernen sie herauszufinden, wo das Problem tatsächlich sitzt: in der semantischen Ebene (falscher Fachkontext), der prozeduralen Ebene (falsche Reihenfolge), der Referenzebene (falsche Vorlage) oder der episodischen Ebene (ein fehlender Präzedenzfall). Diese Diagnosefähigkeit macht aus dem Betriebssystem statt einer einmaligen Lieferung etwas, das das Team ohne uns pflegen, verfeinern und erweitern kann.

Wir vermitteln die Methodik vollständig. Alle im Team verstehen am Ende, wie eine Erfassung funktioniert, wie eine Zerlegungsvorlage entsteht, warum Wissensdateien so strukturiert sind, wie sie strukturiert sind, und wie man das alles von Grund auf selbst erstellt.

Dann geben wir dem Team die Wahl: das Gerüst selbst bauen oder die vorbereiteten Vorlagen nutzen. Beide Wege führen zum selben Betriebssystem. Die meisten Teams nehmen die Vorlagen, weil das Tagesgeschäft nicht stillsteht, nur weil ein Sprint läuft, und weil der eigentliche Wert im Betriebssystem liegt, nicht in den Stunden, die man mit dem Nachbau des Gerüsts verbringt. Die Vorlagen sind vollständig transparent: Das Team kann sie öffnen, jede Zeile lesen, genau sehen, wie sie funktionieren, und sie an den eigenen Kontext anpassen. Mit der Zeit werden daraus die eigenen Werkzeuge des Teams.

Der Sprint ist intensiv. Er funktioniert, weil das Team echte Zeit und Aufmerksamkeit in etwas steckt, das es danach täglich benutzt: die Erfassung fristgerecht ausfüllen, bei den Bausitzungen dabei sein, zwischen den Sitzungen an den übernommenen Aufgaben arbeiten.

Rückhalt aus der Führung ist die andere Hälfte. Wenn die Teamleitung klarmacht, dass das Priorität hat und dass die investierte Zeit erwartet und geschätzt wird, bewegt sich etwas. Ohne das bleibt selbst die beste Methodik stehen.