Zielgerichtete Team-Zusammenstellung statt Scrum für Softwareentwicklung mit Agenten

Unsere Ausgangsthese

Ein einzelner, sehr guter Softwareentwickler kann mit einem gut eingerichteten Agentensystem heute Arbeit bewältigen, für die vor kurzer Zeit mehrere Spezialisten und zahlreiche Übergaben erforderlich waren. Das System kann Architektur und Quellcode untersuchen, Varianten vergleichen, Änderungen umsetzen, Tests ausführen, Fehlerprotokolle auswerten, Dokumentation schreiben und unabhängige Teilaufgaben parallel bearbeiten.¹

Damit verschwinden jedoch nicht die menschlichen Aufgaben. Sie werden nur deutlicher. Jemand muss das richtige Ziel formulieren, fachliche Mehrdeutigkeit auflösen, ästhetische Qualität beurteilen, technische Risiken erkennen, Ergebnisse falsifizieren, rechtliche Grenzen einordnen und entscheiden, was tatsächlich veröffentlicht wird.

Ein modernes, agentenbasiertes Softwareentwicklungssystem kann nur noch von einem guten Team aus Menschen übertroffen werden ‒ wenn dieses Team das System gemeinsam steuert.

Der nächste Produktivitätssprung entsteht deshalb nicht durch einen weiteren Prozessrahmen. Er entsteht durch eine gezielte Team-Zusammenstellung rund um das Agentensystem.

Warum Scrum, SAFe und ähnliche Modelle nicht mehr unser Ausgangspunkt sind

Scrum und später SAFe haben reale Probleme gelöst. Sie strukturierten die Zusammenarbeit menschlicher Teams, machten Arbeit sichtbar und schufen feste Gelegenheiten für Abstimmung und Lernen. Scrum definiert dafür unter anderem Product Owner, Scrum Master, Developers, Sprints und mehrere wiederkehrende Ereignisse. SAFe ergänzt diese Logik um weitere Rollen und Koordinationsebenen wie Product Management, System Architect, Release Train Engineer und Agile Release Train.²

Nach APLICONUS-Ansicht passt diese Grundannahme nicht mehr zu einem agentenbasierten Entwicklungssystem:

• Die Rollen folgen der menschlichen Ausführung. Ein leistungsfähiger Agent bearbeitet dagegen in einem Arbeitslauf Anteile von Analyse, Entwicklung, Test, Review und Dokumentation. Die Verantwortung bleibt beim Menschen; die sichtbare Arbeit verteilt sich aber nicht mehr sauber entlang klassischer Rollen.
• Der Takt folgt dem Kalender. Agenten können innerhalb kurzer Zeit mehrere Lösungswege erzeugen und prüfen. Wenn die nächste fachliche Entscheidung erst im nächsten Termin oder Sprint fällt, wartet nicht mehr der Mensch auf die Umsetzung. Das gesamte System wartet auf Aufmerksamkeit.
• Klassische Kapazitätsmaße verlieren Aussagekraft. Story Points und Team-Velocity beschreiben menschlich geprägte Erfahrungswerte. Im Agentensystem werden Qualität des Kontexts, Laufzeit und Kosten der Agenten, Wartezeit auf Entscheidungen, Prüfbarkeit und Deployment-Fähigkeit zu den wichtigeren Größen.
• Zeremonien können zur Warteschlange werden. Planung, Review und Rückschau bleiben wichtig. Sie sollten aber stattfinden, wenn Unsicherheit, ein prüfbares Ergebnis oder ein wiederkehrendes Problem vorliegt ‒ nicht nur, weil der Kalender es vorsieht.

Das ist kein Urteil über jedes bestehende Scrum- oder SAFe-Team. In großen Organisationen können diese Modelle weiterhin eine äußere Koordinationsschicht bilden, etwa für Budgetierung, Verträge oder Abhängigkeiten zwischen Bereichen. Für den inneren Arbeitskern einer agentenbasierten Softwareentwicklung halten wir sie nicht mehr für das passende Leitmodell.

Beispiel: Codex mit GPT‑5.6

Codex macht die Verschiebung greifbar. GPT‑5.6 ist für anspruchsvolle, mehrstufige Agentenarbeit mit Planung, Werkzeugeinsatz, Validierung und konsequenter Weiterarbeit ausgelegt. Codex kann Teilaufgaben an spezialisierte Agenten delegieren und die Ergebnisse wieder zusammenführen. OpenAI empfiehlt zugleich klare Ziele, Kontext, Randbedingungen und überprüfbare Fertigkriterien sowie Tests und menschliches Review.¹

GPT‑5.6 wird dadurch nicht zum Product Owner, Architekten, Designer, Juristen oder Teamleiter. Es übernimmt keine Verantwortung. Es übernimmt aber große Teile der Arbeit, mit der diese Funktionen bisher im Entwicklungsprozess beschäftigt waren. Genau deshalb muss das menschliche Team neu zugeschnitten werden.

Das Ziel: Maximum sustainable speed

Mit Maximum sustainable speed meinen wir nicht die höchstmögliche Zahl erzeugter Codezeilen und auch keinen Dauerbetrieb an der Belastungsgrenze. Gemeint ist die höchste Geschwindigkeit, die ein Team dauerhaft halten kann, ohne Qualität, Sicherheit, Wissen oder Gesundheit in die Zukunft zu verschieben.

Ein solches System ist schnell, wenn:

• zwischen einer Erkenntnis und einer verifizierten Änderung möglichst wenig Zeit vergeht,
• Qualität, Sicherheit und rechtliche Prüfung Teil des Arbeitsflusses bleiben,
• menschliche Aufmerksamkeit nicht durch unnötige Übergaben und Statusarbeit gebunden wird,
• aus Fehlern dauerhaft bessere Werkzeuge, Regeln, Tests und Arbeitsanweisungen entstehen,
• das Team technischen Fortschritt aufnehmen kann, ohne sich bei jeder Modellgeneration neu zu erfinden.

Kurzfristige Höchstleistung ist leicht zu erzeugen. Nachhaltige Geschwindigkeit verlangt ein System, das Menschen nicht mit der Taktzahl der Agenten verwechselt.

Rollen im Team

Die folgenden Rollen sind keine Forderung nach sieben Vollzeitstellen. Sie beschreiben Verantwortungen, die abgedeckt sein müssen. In einem kleinen Team kann eine Person mehrere Rollen übernehmen; bei einem größeren oder besonders regulierten Vorhaben kann eine Rolle auf mehrere Personen verteilt werden.

Dolmetscher zwischen Team und Agentensystem

Diese Rolle übersetzt Ziele, Randbedingungen und Architektur in eine Sprache, mit der Codex zuverlässig arbeiten kann. Sie kennt den Codebestand, erkennt tragende technische Entscheidungen und sorgt dafür, dass wiederverwendbares Wissen in Architekturregeln, Arbeitsanweisungen, Skills und Tests landet.

Zugleich verantwortet sie technische Innovation: neue Modelle, Werkzeuge und Entwicklungsansätze werden nicht nach Ankündigung, sondern anhand echter Aufgaben evaluiert. Ein Studium der Wirtschaftsinformatik kann für diese Verbindung aus Technik, Organisation und Wirtschaftlichkeit sehr gut passen. Entscheidend sind jedoch Architekturverständnis, Urteilskraft und die Fähigkeit, präzise mit Menschen und Agenten zu kommunizieren.

Dolmetscher zwischen Fachseite und Team

Die Fachseite liefert selten fertige, widerspruchsfreie Spezifikationen. Diese Rolle arbeitet heraus, welches Problem gelöst werden soll, welche Begriffe gelten, wo Ausnahmen liegen und welche Entscheidung wirtschaftlich sinnvoll ist.

Ein betriebswirtschaftlicher Hintergrund kann hilfreich sein. Wichtiger ist die Fähigkeit, Interessen, Prozesse und Daten in überprüfbare Ziele zu übersetzen, ohne fachliche Unsicherheit hinter Tickets oder Scheingenauigkeit zu verstecken.

Design-Spezialist für Ästhetik

Agenten können Oberflächenvarianten schnell erzeugen und bestehende Designsysteme anwenden. Ob ein Produkt souverän, verständlich und ästhetisch stimmig wirkt, bleibt eine menschliche Qualitätsentscheidung.

Der Design-Spezialist beurteilt nicht erst am Ende Farben und Abstände. Er prägt Informationshierarchie, Interaktion, Barrierefreiheit und visuelle Haltung von Beginn an. Seine Aufgabe ist Auswahl und Kritik, nicht die manuelle Produktion jedes Pixels.

Moderator und Teamleiter

Diese Rolle hält Ziel, Zusammenarbeit und Belastung im Blick. Sie sorgt für offene Konflikte statt verdeckter Reibung, schützt den gemeinsamen Fokus und erkennt, wenn Einzelne versuchen, mit der Geschwindigkeit des Agentensystems mitzuhalten.

Kompetenz in Wirtschaftspsychologie oder Psychologie kann dafür wertvoll sein. Der Moderator ist jedoch kein Verwalter von Zeremonien. Er stärkt den Team-Zusammenhalt, verbessert die Feedback-Kultur und entscheidet mit dem Team, wann eine Unterbrechung, ein Richtungswechsel oder bewusste Ruhe notwendig ist.

Recherche- und Legal-Spezialist

Agenten können große Mengen an Quellen finden und verdichten. Sie ersetzen weder Quellenkritik noch rechtliche Verantwortung. Diese Rolle prüft Herkunft, Aktualität und Belastbarkeit von Informationen, verfolgt Lizenzen und erkennt, wann Datenschutz, Urheberrecht, Vertragsrecht oder KI-Regulierung eine qualifizierte Einordnung erfordern.³

Sie muss nicht jede Rechtsfrage selbst beantworten. Sie muss verhindern, dass ein plausibel formulierter Agententext mit einer belastbaren Aussage verwechselt wird.

Debugging-Experte

Agenten erzeugen schnell Hypothesen. Der Debugging-Experte sorgt für belastbare Nachweise. Er reproduziert Fehler, verbessert Instrumentierung, trennt Ursache und Symptom und entwirft Tests, die eine Erklärung widerlegen können.

Diese Rolle ist besonders wichtig, weil hohe Implementierungsgeschwindigkeit auch falsche Annahmen schnell vervielfacht. Gutes Debugging bremst das System nicht. Es verhindert, dass es sehr schnell in die falsche Richtung fährt.

DevOps-Spezialist

Ohne verlässlichen Build, automatisierte Tests, beobachtbare Laufzeit, sichere Bereitstellung und Rückfallstrategie bleibt Agentenleistung eine Demo. DevOps gestaltet die Strecke von der Änderung bis zum Betrieb.

Der Spezialist hält Entwicklungsumgebungen reproduzierbar, macht Qualitätsgrenzen maschinenprüfbar und sorgt dafür, dass Agenten nur innerhalb klarer Berechtigungen handeln. Sicherheit ist dabei keine nachgelagerte Abnahme, sondern eine gemeinsame Verantwortung mit Recherche, Legal, Architektur und Debugging.

Anforderungen an das Team

Ein Agentensystem verstärkt die Arbeitsweise des Teams. Präzision wird produktiver; Unklarheit skaliert ebenfalls. Deshalb sind folgende Eigenschaften keine weichen Ergänzungen, sondern Teil der technischen Leistungsfähigkeit.

• Präzise, gemeinsame Sprache: Zentrale Begriffe, Ziele, Verbote und Qualitätsmerkmale müssen für Fachseite, Technik und Agentensystem dasselbe bedeuten. Gute Sprache wird im Repository, in Modellen, Tests und Arbeitsanweisungen wiederverwendbar.
• Zielorientierung und Fokus: Das Team arbeitet auf ein sichtbares Ergebnis hin. Neue Möglichkeiten werden bewertet, aber nicht automatisch zu neuen Baustellen.
• Exzellente Kommunikation: Entscheidungen, Zweifel, Fehler und Überlastung werden früh benannt. Statusdarstellung ohne Konsequenz gilt nicht als Kommunikation.
• Kreativität: Agenten erweitern den Lösungsraum. Menschen müssen weiterhin ungewohnte Fragen stellen, Widersprüche aushalten und entscheiden, welche Variante überhaupt wertvoll ist.
• Team-Zusammenhalt: Hohe individuelle Produktivität darf nicht zu sieben privaten Agentensystemen führen. Wissen, Ziele und Erfolge gehören dem Team.
• Belastbarkeit ohne technologische Plateaubildung: Auf absehbare Zeit entsteht kein ruhiges Plateau, auf dem alle Werkzeuge für Jahre stabil bleiben. Lernen, Erproben und Verwerfen müssen deshalb eingeplant werden, statt zusätzlich zur eigentlichen Arbeit stattzufinden.
• Hinauswachsen über klassische Spezialisierungen: Jede Rolle behält ihre Tiefe, muss aber die Sprache der angrenzenden Rollen verstehen. Architektur ohne Fachlichkeit, Design ohne Technik und DevOps ohne Produktverständnis erzeugen neue Übergaben.
• Feedback-Fähigkeit: Ergebnisse und Annahmen müssen hart kritisiert werden können, ohne Personen abzuwerten. Das gilt auch für Agentenausgaben: freundlich klingende Sicherheit ist kein Qualitätsnachweis.

Die Brückenbesatzung der USS Enterprise D als Analogie

Eine gute Analogie ist die Brückenbesatzung der USS Enterprise D. Entscheidend ist dabei die Zusammenstellung der Charaktere. Die Besatzung besteht nicht aus mehreren Ausführungen desselben Idealprofils. Unterschiedliche Stärken, Temperamente und Blickwinkel sind bewusst miteinander verbunden.

Data steht für ChatGPT beziehungsweise Codex mit GPT‑5.6 ‒ nicht der Bordcomputer. Data ist Teil der Besatzung. Er verarbeitet Informationen mit außergewöhnlicher Geschwindigkeit, verbindet Fachgebiete und liefert häufig den entscheidenden Lösungsvorschlag. Trotzdem bestimmt er weder Ziel noch Werte der Mission. Seine Stärke entsteht im Zusammenspiel mit den Menschen um ihn herum.⁴

Captain Picard zieht. Er gibt Richtung, entscheidet und übernimmt Verantwortung. Ein agentenbasiertes Team braucht diese vorwärtsgerichtete Kraft. Sonst werden aus vielen schnell erzeugten Möglichkeiten nur ebenso viele offene Optionen.

Deanna Troi bremst, falls erforderlich. Als Counselor nimmt sie Spannungen, Zweifel und Überlastung wahr, die in einem rein technischen Lagebild fehlen. Sie verhindert nicht Geschwindigkeit. Sie verhindert, dass das Team Geschwindigkeit mit Selbstüberforderung verwechselt. Für Maximum sustainable speed ist dieses Korrektiv genauso wichtig wie Picards Zug.

Geordi La Forge ist der Chef-Debugger. Der Chief Engineer steigt in das System hinab, wenn eine Erklärung an der Oberfläche nicht trägt. Er sucht die tatsächliche Ursache, probiert Gegenmaßnahmen aus und stellt den verlässlichen Betrieb wieder her. Genau diese Hartnäckigkeit braucht ein Team, dessen Agentensystem sehr schnell auch eine falsche Annahme vervielfachen kann.

Auch die weiteren Charaktere ergänzen das System: Riker übersetzt die gesetzte Richtung in operative Zusammenarbeit und widerspricht dem Captain, wenn es notwendig ist. Worf hält Risiken, Sicherheit und klare Grenzen sichtbar. Dr. Crusher verbindet Forschung und fachliche Sorgfalt mit der Frage, welche Folgen eine Entscheidung für Menschen hat.

Die Analogie muss nicht jede reale Fachrolle eins zu eins abbilden. Der Design-Spezialist oder eine qualifizierte juristische Prüfung bleiben im Softwareteam eigenständige Aufgaben. Entscheidend ist die Mischung der Charaktere: Zug und Bremse, Analyse und Zweifel, Erfindungsgeist und Fehlersuche, Risikobewusstsein und Verantwortung für Menschen.

Der Arbeitstakt folgt der Lage, nicht einer Zeremonie. Die Brücke wartet nicht auf das nächste Daily, wenn sich der Kurs ändern muss. Genau diese Verbindung aus klarer Verantwortung, gemeinsamer Sprache und bewusst verschiedenen Charakteren beschreibt das von uns gemeinte Teammodell.

Ein Arbeitsmodell ohne neuen Methodenapparat

Scrum abzuschaffen und die Lücke mit ungeregelten Prompts zu füllen wäre der falsche Schluss. Ein agentenbasiertes Team braucht weniger Zeremonie, aber mehr explizite Betriebsregeln.

1. Ein gemeinsames Ziel festlegen. Fachliches Ergebnis, Grenzen und Fertigkriterien werden sichtbar formuliert.
2. Kontext ausführbar machen. Architektur, Konventionen, Build- und Testwege sowie Verbote liegen dort, wo Agenten und Menschen sie tatsächlich verwenden.
3. Arbeit nach Risiko zuschneiden. Agenten bearbeiten unabhängige, prüfbare Aufgaben. Für jede Aufgabe ist klar, wer die menschliche Verantwortung trägt.
4. Prüfbare Ergebnisse früh erzeugen. Tests, Screenshots, Protokolle, Messwerte und kleine produktionsnahe Schritte ersetzen Meinungen über vermeintlichen Fortschritt.
5. Entscheidungen ohne Kalenderwartezeit treffen. Sobald ein Ergebnis prüfbar ist, geben die zuständigen Menschen Feedback oder ändern die Richtung.
6. Das System aus Fehlern lernen lassen. Wiederkehrende Missverständnisse werden zu besseren Modellen, Regeln, Werkzeugen oder Tests.
7. Teamgesundheit ausdrücklich prüfen. Nicht als Ritual, sondern regelmäßig und zusätzlich immer dann, wenn Tempo, Konflikte oder technischer Wandel die Belastung erhöhen.

Der Arbeitsvorrat bleibt dynamisch. Ein aktuelles Ziel ersetzt nicht jede Planung, verhindert aber, dass Planung zum Selbstzweck wird.

Einstieg in der Praxis

Beginnen Sie nicht mit einer unternehmensweiten Methodentransformation. Wählen Sie ein reales Produkt und einen klar begrenzten Entwicklungsbereich. Ordnen Sie die genannten Verantwortungen konkreten Personen zu und machen Sie sichtbar, wo eine Rolle fehlt oder überlastet ist.

Messen Sie anschließend nicht nur Durchsatz. Beobachten Sie die Zeit von einer fachlichen Entscheidung bis zur verifizierten Bereitstellung, die Wartezeit auf Reviews, Fehler nach der Freigabe, notwendige Nacharbeit, Kosten der Agentenläufe und die Belastung im Team.

Nach einigen echten Änderungen zeigt sich, welche Rollen kombiniert werden können, welche Regeln fehlen und wo das Agentensystem noch keine verlässliche Entlastung liefert. Das Teammodell soll lernen. Es soll nicht das nächste starre Vorgehensmodell werden.

Häufige Fragen

Ist Scrum damit grundsätzlich falsch?

Nein. Scrum kann weiterhin für menschlich geprägte Teams oder als gemeinsame Sprache in einer bestehenden Organisation funktionieren. Unsere These ist enger: Für ein konsequent agentenbasiertes Entwicklungssystem sollte Scrum nicht mehr automatisch das innere Betriebssystem sein.

Braucht agentenbasierte Entwicklung weniger Menschen?

Für reine Ausführung häufig ja. Für ein sehr gutes Produkt kann die frei werdende Kapazität aber sinnvoller in Fachlichkeit, Ästhetik, Forschung, Qualität und Betrieb investiert werden. Das Ziel ist nicht die kleinstmögliche Mannschaft, sondern die wirksamste.

Können mehrere Rollen von einer Person übernommen werden?

Ja. Rollen sind Verantwortungsbereiche, keine zwingenden Stellen. Problematisch wird die Kombination erst, wenn wichtige Perspektiven nicht mehr unabhängig geprüft werden oder eine Person zum dauerhaften Engpass wird.

Wer trägt die Verantwortung für Fehler des Agentensystems?

Die verantwortlichen Menschen und die Organisation. Agenten können analysieren, Vorschläge machen, implementieren und prüfen. Produktentscheidungen, Freigaben und die Folgen des Einsatzes bleiben menschliche Verantwortung.