KI-native Delivery: kleinere Salesforce-Teams

KI-native Delivery verkleinert ein Salesforce-Team auf kleine Pods: ein Architekt, ein Builder-Reviewer, der die Coding-Agenten steuert, und ein Fachexperte aus dem Fachbereich. Für Hersteller liegt die größere Änderung auf der eigenen Seite, weniger beim Partner. Jeder Pod braucht jemanden aus Service, Vertrieb oder After-Sales, der täglich über den Prozess entscheidet und in einer täglichen Demo laufende Software abnimmt. Kurze Intents ersetzen lange Lastenhefte, und jedes Artefakt hat einen benannten Verantwortlichen. Kann Ihre Organisation diese Personen nicht freistellen, machen kleinere Partnerteams das Programm nicht schneller.

Was ist KI-native Delivery?

KI-native Delivery bedeutet, den gesamten Lieferprozess um KI-Agenten herum zu gestalten und nicht dem alten Prozess einen Coding-Assistenten hinzuzufügen. Die klarste Beschreibung für Salesforce stammt aus der Praxis, nicht aus einer Studie: der Beitrag von Amit Chaudhary auf ApexHours1 vom 19. Oktober 2026. In seinem Framework entwerfen, bauen, testen und dokumentieren Agenten, während Menschen „set intent and guardrails, review output, own the outcome“: Absicht und Leitplanken vorgeben, Ergebnisse prüfen, das Resultat verantworten. Die Alternative nennt er „the old process with faster typing“, also den alten Prozess mit schnellerem Tippen.

Für die Programmorganisation zählen fünf Bausteine:

• Intents statt Lastenheft. Ein Intent ist eine ergebnisorientierte Anforderung: erwartetes Ergebnis, warum es zählt, betroffene Nutzer, Rahmenbedingungen und Leitplanken sowie Erfolgskriterien.
• Kleine Pods statt Pyramide. Die große Pyramide aus Junior-Entwicklern weicht kleinen Pods aus Architekt, Builder-Reviewer und Fach- oder BA-Lead.
• Tägliche Demo statt Status-Standup. Das Team zeigt dem Product Owner laufende Software, die seit dem Vortag entstanden ist.
• Benannte Verantwortung. „A named human owns every artifact“, jedes Artefakt hat also einen namentlich benannten Menschen als Verantwortlichen. Agenten arbeiten nur in freigegebenen Sandboxes und Scratch Orgs, nie in Produktion.
• Dieselben Prüfungen für alle. PMD, Code Analyzer und ApexGuru laufen in der CI für Menschen- und Agentencode gleichermaßen.

Ich stimme nicht jeder Zahl und nicht jedem Schritt in diesem Framework zu, aber die Richtung stimmt. Und eine Schablone passt nie hundertprozentig auf jeden Kunden.

Warum werden Salesforce-Teams kleiner?

McKinsey hat im Mai 2026 334 Führungskräfte aus Produkt und Engineering befragt und die Ergebnisse im August unter dem Titel Beyond the copilot2 veröffentlicht.

79 %

der Befragten aus Organisationen mit dem größten Tempogewinn melden kleinere Teams

7

Personen hat ein Team dort im Median, vorher etwa zehn

50 bis 80 %

kürzere Entwicklungszyklen meldet ein globales Technologieunternehmen

Dieses Technologieunternehmen ging von Produktteams mit 8 bis 10 Personen auf agentische Teams mit 4 bis 6 über und meldet etwa doppelte Kapazität. McKinsey sieht zwei Rollenfamilien entstehen: „Definers“, die Produkt und Design verbinden, und „Builders“, die Entwicklung, Test und Betrieb verbinden.

Zwei Einschränkungen aus derselben Quelle. Die Zahlen sind Selbstauskünfte von Führungskräften, und 30 Prozent der Befragten sagen, die Produktivität ihrer Teams sei gesunken. McKinsey schreibt außerdem, dass sich das Tempo schneller verbessert als die Qualität. Der DORA-Bericht 2025 fand weiter einen negativen Zusammenhang zwischen KI-Einsatz und Lieferstabilität3, und DORA zählt kleine Batches und Nutzerzentrierung4 zu den sieben Fähigkeiten, die den Nutzen von KI verstärken. Kleine Pods mit täglichem Feedback sind eine direkte Antwort auf beide Punkte. Wie Sie prüfen, ob Ihr eigenes Programm schneller wird, beschreibe ich in KI-Nutzen im Salesforce-Projekt messen.

In der Programmorganisation wird der Fachbereich zum Engpass

Der Fachbereich wird zum Engpass

Im klassischen Programm schreibt der Fachbereich Anforderungen und wartet dann wochenlang auf den Abnahmetest. Im Pod sieht der Fachexperte jeden Tag laufende Software und entscheidet sofort. Für einen Maschinenbauer heißt das: eine Garantiesachbearbeiterin aus dem After-Sales, ein Disponent aus dem Außendienst oder jemand aus dem Händlervertrieb, der über seinen Prozess entscheiden darf. Nach meiner Einschätzung braucht diese Person rund die Hälfte ihrer Zeit für den Pod. Serviceleiter planen das selten ein, und genau das würde ich vor jedem Partnerangebot verhandeln.

Intents ersetzen den größten Teil des Lastenhefts

Ein guter Intent für eine Story im Händlerportal passt auf eine halbe Seite: Händler sehen den Liefertermin ihrer Ersatzteilbestellung, ohne anzurufen, gemessen an weniger Telefonanfragen; Rahmenbedingungen sind händlerspezifische Preise und Freigaben pro Account. McKinsey ergänzt, Spezifikationen sollten so klar sein, dass ein Agent danach handeln kann. Ich lese das als prüfbare Akzeptanzkriterien, nicht als mehr Prosa. Zwei Dinge behalten eine genaue Spezifikation: Schnittstellen zu SAP oder proALPHA, weil das ERP-Team einem eigenen Releaseplan folgt, und Regeln mit finanzieller Wirkung wie Garantieberechtigung oder Preisfreigabe.

Statusrunden werden zu Demos

Die tägliche Demo ersetzt das Standup und einen guten Teil des Statusberichts. Ein Lenkungsausschuss, der das Garantieantragsformular in der Sandbox laufen sieht, braucht weniger Ampeln. McKinsey nennt zweitägige Sprints als illustrativen Richtwert. Das würde ich nicht übernehmen, solange SAP-Transporte in festen Fenstern laufen; ein kurzer Zyklus in Salesforce mit einem Release-Rhythmus, der zum ERP passt, funktioniert besser.

Verantwortung muss aufgeschrieben werden

Mit weniger Personen trägt jede einzelne mehr Wissen, und ein Agent verantwortet nichts. Der benannte Verantwortliche pro Artefakt passt zur Object Ownership Matrix, die ich nutze, wenn sich mehrere Partner eine Org teilen: Ein Team verantwortet jedes Objekt, eine Person jeden Flow, jede Klasse und jeden Agenten. Dazu kommen die Prüfungen in der Pipeline, siehe Quality Gates für KI-Code in der Salesforce-Pipeline.

Rechenbeispiel: aus einem großen Partnerteam werden drei Pods

Nehmen wir einen Maschinenbauer mit Sales Cloud, Service Cloud, Field Service und einer SAP-Anbindung. Sein Partner arbeitet mit einem klassischen Team aus zwölf Personen: ein Architekt, eine Projektleitung, zwei Business Analysts, sechs Entwickler (davon vier Junior) und zwei Tester. Alle Zahlen sind Annahmen, die das Vorgehen zeigen sollen. Geplant sind drei Streams: Garantieanträge von Händlern, Ersatzteilbestellung im Händlerportal und Arbeitsaufträge im Außendienst mit Ersatzteilreservierung.

Der Partner schlägt drei Pods vor. Jeder Pod bekommt einen Architekten und einen Builder-Reviewer vom Partner; eine Person für Plattform und DevOps arbeitet für alle drei. Das sind sieben Personen beim Partner, vorher waren es zwölf. Die Fachexperten stellt der Hersteller: eine Garantiesachbearbeiterin, eine Koordinatorin aus dem Händlervertrieb und einen Disponenten aus dem Außendienst, jeweils zur Hälfte, also 1,5 Vollzeitstellen, die der Fachbereich bisher nicht gegeben hat.

Drei Entscheidungen tragen oder kippen dieses Setup:

• Kein Fachexperte, kein Pod. Kann die Serviceleitung den Disponenten nicht freistellen, wartet der Field-Service-Pod. Ohne tägliche Abnahme baut er auf Vermutungen, und die Demo wird zur Vorführung für den Partner.
• Ein leitender Architekt über alle Pods. Drei Pod-Architekten würden jeweils ihr eigenes Account- und Asset-Modell entwerfen. Datenmodell, Freigaben und die SAP-Schnittstelle würde ich bei einem Architekten auf Kundenseite halten.
• Formaler Test bleibt dort, wo SAP bucht. Garantiegutschriften gehen nach SAP, dieser Stream behält deshalb vor jedem Release einen End-to-End-Test. Der Portal-Stream geht nach täglicher Abnahme live.

Ob sieben Personen liefern, was vorher zwölf geliefert haben, bleibt offen, bis die Durchlaufzeiten gemessen sind. Der Preis des Partners für das neue Setup gehört ins kaufmännische Modell, siehe Festpreis statt Aufwand.

Wo passt das Pod-Modell noch nicht?

• Streams, in denen vor allem gewartet wird. Verbringt eine Story den größten Teil ihrer Durchlaufzeit mit Warten auf das SAP-Team oder eine Middleware-Änderung, ändert ein schnellerer Salesforce-Pod wenig.
• Fachbereiche, die niemanden freistellen können. Ohne tägliche Entscheidungen aus Service oder Vertrieb ist ein klassisches Team mit Product Owner und geplantem Abnahmetest die sicherere Aufstellung. Dessen Entwickler können trotzdem mit Coding-Agenten arbeiten.
• Teams ohne funktionierende Pipeline. Pods liefern mehr Änderungen pro Tag. Ohne Versionskontrolle, automatisierte Tests und Validierungsdeployments entstehen im höheren Tempo vor allem schneller Fehler.
• Dünne Seniorität beim Partner. Ein Pod hat keine Juniors, die nebenbei lernen. Geht der Builder-Reviewer, geht ein großer Teil des Wissens mit. Mindestverweildauern zählen hier noch mehr als in dem Setup, das ich in warum Nearshore-Teams höchstens acht Entwickler haben sollten beschreibe. Was sich für Nearshore-Teams mit KI-Agenten ändert, steht in Nearshore-Teams für Salesforce mit KI-Agenten.

Einen Stream mit klarem Prozess wählen

1. 01

   Einen Stream wählen

   Mit klarem Prozess, einer entscheidungsbefugten Person im Fachbereich und wenigen ERP-Abhängigkeiten. Stories im Händlerportal passen oft gut.

2. 02

   Fachexperten zuerst benennen

   Seine Zeit von der Führungskraft freigeben lassen, bevor der Partner umbaut.

3. 03

   Intents schreiben

   Für die ersten zehn Stories, mit prüfbaren Akzeptanzkriterien; genaue Spezifikationen bleiben für Schnittstellen und Regeln mit finanzieller Wirkung.

4. 04

   Leitplanken vereinbaren

   Mit dem Partner: benannter Verantwortlicher pro Artefakt, Agenten nur in Sandboxes und Scratch Orgs, dieselben Prüfungen für allen Code. Die Vertragsseite beschreibe ich in Partner mit KI-Coding: Regeln für den Vertrag.

5. 05

   Messen und entscheiden

   3 Monate

   Durchlaufzeit und Nacharbeit messen und erst dann über die anderen Streams entscheiden.

Die zehn Intents aus dem dritten Schritt sind zugleich der Maßstab für die Messung nach drei Monaten. Streams, Teamaufstellungen und die Fachbereichszeit dahinter zu planen, ist der Kern meiner Programmsteuerung für Salesforce-Programme.

Quellen4

1. 1Beitrag von Amit Chaudhary auf ApexHours (öffnet in einem neuen Tab)apexhours.com
2. 2Beyond the copilot (öffnet in einem neuen Tab)mckinsey.com
3. 3negativen Zusammenhang zwischen KI-Einsatz und Lieferstabilität (öffnet in einem neuen Tab)cloud.google.com
4. 4kleine Batches und Nutzerzentrierung (öffnet in einem neuen Tab)dora.dev