Agile Softwareentwicklung & Agentic AI Execution: Liefern mit Agenten

Von Code-Assistenz zu Agentic AI: vier Stufen

Die Entwicklung der Coding-Werkzeuge verlief in vier Stufen. Chat-Assistenten generieren Snippets auf Anfrage. Inline-Copilots vervollständigen Code im Editor. Autonome Agenten wie Claude Code oder Cursor lesen Projektdateien, führen Bash-Kommandos aus und erstellen Pull Requests. Orchestrierte Agenten-Systeme verteilen Arbeit auf spezialisierte Rollen mit dokumentierten Übergaben. Jede Stufe erhöht die Autonomie – und damit den Preis einer unklaren Vorgabe.

Für Product Manager ist die dritte Stufe der Wendepunkt: Ab hier führt die Maschine über Stunden aus, was du definiert hast. Ein Agent, der eine Stunde in die falsche Richtung baut, weil das Ziel unklar war, produziert eine Stunde Schaden. Die Tabelle unten ordnet die Stufen und die Rolle des Menschen in jeder davon.

Warum klassisches Scrum bei KI-Entwicklung bricht

Scrum setzt voraus, dass sich Arbeit in planbare Inkremente schneiden lässt: Story rein, Schätzung dran, am Sprint-Ende ist es fertig. Modell-Training und Feinabstimmung halten sich nicht daran – sie erfordern unvorhersehbare Iterationszyklen, in denen ein Experiment scheitern darf, ohne dass der Sprint scheitert. Wer KI-Arbeit in klassische Stories presst, bekommt entweder geplatzte Sprints oder Schätzungen, die niemand mehr ernst nimmt.

Die Lösung ist nicht weniger Disziplin, sondern eine angepasste: Spikes statt Stories für Experimente, Evaluationskriterien in der Definition of Done, Liefern und Lernen sauber getrennt. Frameworks wie CRISP-ML(Q) geben dem eine Struktur. Der Deep Dive «Agile für KI: Sprints, die Modell-Training aushalten» zeigt die Anpassungen im Detail – ohne die Lieferdisziplin zu opfern.

Live View: Echtzeit-Status statt Sprint-Ende-Überraschung

In klassischen agilen Prozessen ist der tatsächliche Stand einer Implementierung oft erst am Sprint-Ende sichtbar, und Schätzungen basieren auf Erfahrungswerten, die vom aktuellen Quellcode weit abweichen können. Eine Live View dreht das um: Echtzeit-Fortschritt mit Kontext zum tatsächlichen Code, Schätzungen, die aus der Codebasis begründet sind, Abhängigkeiten und architektonische Hürden, die sichtbar werden, sobald sie entstehen – nicht erst im Review.

Die Kontrolle bleibt dabei beim Team: Entwickler delegieren klar umrissene Aufgaben an Agenten, die gegen die Spec aus der Define-Phase bauen, und greifen bei Abweichungen sofort ein. Das Ergebnis ist eine kontrollierte Auslieferung geprüfter Software – ohne böse Überraschungen am Sprint-Ende.

Das Ticket wird zum Prompt: Anforderungen für Agenten schreiben

Ein Jira-Ticket im Agentic Engineering ist keine Arbeitsanweisung für Menschen mehr, sondern ein kontextvollständiger Prompt, der von KI-Agenten geparst wird. Der 100-Wort-Pointer «wie besprochen, siehe Meeting» funktioniert nicht, wenn der Adressat nicht im Meeting sass. Das Ticket operationalisiert die Spec aus der Define-Phase: Ziel, Kontext, Akzeptanzkriterien, Randfälle – vollständig genug, dass ein Agent ohne Rückfragen bauen kann.

Wie diese Anatomie im Detail aussieht – inklusive Story-Files und Context Engineering – zeigt «Die Anatomie eines Jira-Tickets für KI-Product-Management». Die Begriffsbasis dazu, von Epic bis Cycle, liefert das Product-Management-Glossar.

Model Context Protocol: Agenten an Werkzeuge anschliessen

Das Model Context Protocol (MCP) ist der offene Standard, über den Sprachmodelle direkt mit Werkzeugen wie Jira, Slack oder lokalen Datenbanken kommunizieren. Es eliminiert die fehleranfälligen manuellen Export-Import-Zyklen: Statt Tickets zu kopieren und Ergebnisse zurückzupasten, liest und schreibt der Agent selbst – mit definierten Berechtigungen.

Für die Build-Phase ist MCP der Hebel, der Agentic Execution praktikabel macht: Der Agent holt sich den Kontext, den er braucht, aus den Systemen, in denen er liegt. Für Product Manager heisst das aber auch: Berechtigungen, Datenzugriff und Audit gehören in die Spec – wer darf was lesen, was schreiben, was nie berühren.

Die Sandwich-Architektur: deterministische Käfige für probabilistische Systeme

Autonome Agenten im Unternehmenseinsatz brauchen Sicherheitsarchitektur, keine Hoffnung. Die Sandwich-Architektur flankiert das Kernmodell mit zwei Kontrollinstanzen: Ein Input-Guardrail prüft jede Eingabe auf Prompt Injections und versehentlich übermittelte personenbezogene Daten, bevor sie das Kernmodell erreicht. Ein Output-Guardrail verifiziert die Antwort – gegen Halluzinationen, gegen die Preisgabe vertraulicher Systeminformationen, gegen Verstösse gegen die eigenen Richtlinien.

Der Grundsatz dahinter: dem Modell nie blind vertrauen. Es ist keine sichere interne Logikkomponente, sondern ein System, das jede Eingabe als Handlungsanweisung interpretieren kann. Entscheidungen mit hoher Tragweite bleiben deshalb bei klassischem Code oder beim Menschen; regelmässige Angriffs-Simulationen durch das eigene Team decken Schwachstellen auf, bevor es andere tun.

Sicherheit kostet Latenz – jede Kontrollinstanz braucht Zeit. Dieser Trade-off ist eine Produktentscheidung, keine technische: Er gehört ins PRD, mit Schwellenwerten pro Anwendungsfall.

PM, Data Scientist, ML Engineer: Handovers entscheiden

KI-Features scheitern empirisch selten an der Modellarchitektur – sie scheitern an schlechten Übergaben, bei denen Verantwortlichkeiten zwischen Product Management, Data Science und Engineering verschwimmen. Die Build-Phase ist der Ort, an dem diese Reibung sichtbar wird: Wer definiert die Evaluationskriterien? Wer entscheidet, wann ein Modell gut genug ist? Wer trägt den Pager, wenn es driftet?

«PM, Data Scientist, ML Engineer: Wer macht was?» liefert die Rollenschnitte, die funktionieren – und die zwei Launch-Fragen, die jedes KI-Team schriftlich beantworten muss. Die Kurzform: Jede Übergabe braucht ein Artefakt, und jedes Artefakt braucht einen Eigentümer.

Autonomie braucht Standards: die Spotify-Falle

Das Spotify-Modell verspricht autonome Squads, die unabhängig liefern. Mit KI-Agenten wird aus dieser Autonomie ohne zentrale Standards architektonisches Chaos: Jedes Team promptet anders, jede Codebasis divergiert schneller, und Token-Budgets verbrennen in redundanter Arbeit. Agenten skalieren die Wirkung jeder Entscheidung – auch der schlechten.

Organisiertes Alignment ist deshalb Pflicht: gemeinsame Spec-Standards, geteilte Kontextdateien, zentrale Guardrails. «Warum das Spotify-Modell scheitert – mit KI-Agenten erst recht» zieht die Lehren aus den dokumentierten Fällen – als Warnung vor grenzenloser Agilität im KI-Zeitalter.

Häufige Fragen