Guide: Produktivität von AI Agents mit dem SPACE-Framework messen

In Teil eins der Reihe haben wir gelernt, wie man die Performance eines Produktentwicklungsteams nicht misst, damit wir häufige Fehler in der Beurteilung eines Entwicklungsprozesses vermeiden können. In Teil zwei haben wir die DORA-Metriken kennengelernt, mit denen wir die Delivery Performance eines Teams erheben können, ohne dabei Goodhart’s Law zum Opfer zu fallen.

Mit den Metriken können wir die Ergebnisse unserer Arbeit schon gut beurteilen und zwei zentrale Fragen beantworten:

1. Wie viel Durchsatz haben wir im Team, d.h., wie häufig veröffentlichen wir Änderungen?
2. Wie stabil sind diese Veröffentlichungen und wie viel Nacharbeit haben wir?

In Zeiten von Agentic Coding messen viele Teams, wenn überhaupt, nur die Metriken hinter Frage eins und vernachlässigen die Metriken hinter Frage zwei.

In Teil drei der Reihe erweitern wir die beiden Fragen oben um eine dritte, um ein wesentlich umfangreicheres Gesamtbild zu bekommen:

3. Wie sieht das Innenleben des Motors aus, der die Veröffentlichungen produziert?

Dazu bedienen wir uns in Teilen des SPACE-Frameworks.

Was ist das SPACE-Framework?

Die Kernidee des SPACE-Frameworks ist, dass Produktivität mehrdimensional ist und nicht anhand einer einzelnen Metrik erfasst werden kann. Es wurde im Jahr 2021 unter dem Titel „The SPACE of Developer Productivity“ von einer Reihe von Autorinnen und Autoren, u.a. von Microsoft, GitHub und der Universität von Victoria veröffentlicht.

Für unsere Zwecke hat das SPACE-Framework vor allem den Vorteil, dass es komplementär zu den DORA-Metriken ist, nicht konkurrierend. Durch die Erhebung der SPACE-Metriken erweitern wir unser Gesamtbild. Wir können:

• Zusätzliche Metriken erheben, die blinde Flecken beseitigen und
• Ursachen für die Symptome ableiten, die uns bei der Messung der DORA-Metriken aufgefallen sind.

SPACE ist eine Abkürzung für die fünf Metriken, die wir mit Hilfe des Frameworks erheben können:

• Satisfaction & Well-being (Zufriedenheit & Wohlbefinden)
• Performance (Ergebnis/Wirkung)
• Activity (Aktivität)
• Communication & Collaboration (Kommunikation & Zusammenarbeit)
• Efficiency & Flow (Effizienz & „Flow“)

Bevor wir uns die Metriken im Detail ansehen, drei wichtige Hinweise vorab:

1. Nicht jede Metrik ist so einfach messbar wie manche der DORA-Metriken.
2. Nicht jede Metrik ist für unsere Zwecke gleich relevant.
3. Wie auch bei DORA ist es wichtig, diese Metriken auf Teamebene zu erheben, nicht auf der Ebene eines einzelnen Engineers.

S: Satisfaction & Well-being

Was messen wir?

Wie zufrieden, engagiert und gesund (d.h. nicht ausgebrannt) sind Entwickler in Bezug auf ihren Arbeitsalltag, die Tools und die Unternehmens- und Teamkultur?

Wie messen wir das?

Direkt ist das nicht möglich. Der einfachste Ansatz sind regelmäßige anonyme Befragungen wie NPS (Net Promoter Score, „Wie wahrscheinlich ist es, dass ich mein Team weiterempfehlen würde?“), die du erhebst und auswertest.

Starte mit einer vierteljährlichen Befragung und sammle Feedback zur Häufigkeit. Vielleicht ergibt eine Erhebung alle sechs Monate für dein Team mehr Sinn. Die quantitativen und qualitativen Werte ergänzt du mit einem Blick auf die Fluktuation in deinem Team und hast einen soliden Eindruck, auf dem du aufbauen kannst.

Wie wichtig ist das?

Eine hohe Fluktuation schadet der Produktivität deines Teams und letztlich deinem Unternehmen. Zusätzlich verbringen wir sehr viel Zeit mit Arbeit; dementsprechend ist es allein auf menschlicher Ebene sehr wichtig, ein Umfeld zu schaffen, in dem Menschen gerne sind und das es ihnen ermöglicht, die beste Version von sich selbst zu sein.

Darüber hinaus ist Satisfaction & Well-being der wohl blindeste Fleck der DORA-Metriken und vielleicht sogar der blindeste Fleck aller Entwicklungen, die in den letzten Jahren in der Softwareentwicklung stattgefunden haben.

Wer sich hier Mühe gibt, hat es leicht, als guter Arbeitgeber herauszustechen.

Wie kann ich Satisfaction & Well-being verbessern?

Sechs Beispiele, die von den qualitativen Daten abhängen:

1. Meeting-Last und Kontextwechsel reduzieren.
2. On-Call-Last und Verantwortung fair verteilen.
3. Gemeinsame Ziele und Prioritäten definieren.
4. Mikromanagement reduzieren und Engineers befähigen, sich selbst zu managen.
5. Developer Experience verbessern und Toolchain-Reibung reduzieren.
6. Einen sicheren Raum für Feedback und Weiterentwicklung schaffen, z.B. durch regelmäßige 1-on-1s.

P: Performance

Was messen wir?

Welche Wirkung hat der Code auf die Qualität, Zuverlässigkeit, die Kunden und das Unternehmen?

Wie messen wir das?

Die Messung ist wieder nur teilweise oder über Proxies möglich. Indizien für eine niedrige Performance sind beispielsweise:

• eine hohe Change Fail Rate (siehe DORA-Metriken),
• ein hoher Anteil an Bugtickets pro Iteration (z.B. Sprint),
• eine sinkende oder niedrige Customer Satisfaction,
• eine geringe Nutzung neuer Features.

Hier ist es wichtig, dass du die Proxies definierst, die du ohne erheblichen Aufwand messen kannst, und dir eine einfache Methodik überlegst, wie du diese Messungen nutzt, um Rückschlüsse auf die Performance zu ziehen. Definiere niemals nur einen Proxy, besser drei oder vier.

Wie wichtig ist das?

Da der Preis einer Änderung (Cost of Change) durch Agentic Coding gefühlt gesunken ist, ist die Gefahr von „Busy Work“ stark gestiegen: Die Tools sind (noch) günstig und manche Engineers oder Teams verfallen nahezu in einen AI-Wahn. Ein Blick auf die Performance ermöglicht dir Rückschlüsse darauf, ob die Änderungen wirklich dein Unternehmen weiterbringen, oder ob sie nur entstehen, weil es so leicht ist. Auch im Jahr 2026 gilt: Der beste Code ist der, den du nicht schreibst (oder eben generierst).

Kurz: Sehr wichtig.

Wie können wir die Performance verbessern?

Drei Beispiele, die von deiner Wahl der Proxies abhängen:

1. Veröffentlichungen kleiner halten, um Fehlerrisiko zu reduzieren.
2. Nutzerinterviews führen und Umfragen einbauen, um Bedürfnisse besser zu erfassen.
3. A/B-Tests oder Fake-Door-Tests nutzen, um Feature-Bedarf einzuschätzen.

A: Activity

Was messen wir?

Wie hoch ist das Volumen der sichtbaren Handlungen deiner Engineers (Commits, Pull Requests, abgeschlossene Tickets, o. Ä.)?

Wie messen wir das?

Du kannst zum Beispiel die Zahl der abgeschlossenen Tickets oder die Zahl der Pull Requests erheben, die auf Main gemergt wurden. Bei dieser Metrik geht es lediglich um das Volumen der erledigten Arbeit (was sie auch so gefährlich macht).

Wie wichtig ist das?

Activity (Aktivität) ist die Metrik, die durch Agentic Coding am meisten an Bedeutung verloren hat: Wer AI Agents nutzt, erhöht das Volumen seiner Handlungen erheblich. Die Stabilität der Ergebnisse kann gleich bleiben oder gar sinken, und der Nutzen der Änderungen für den Kunden ist aus dieser Metrik ebenfalls nicht erkennbar.

Da die Metrik leicht zu erheben ist (via Jira oder GitHub), kannst du sie dazunehmen. Aussagekraft hat sie im Jahr 2026, wenn überhaupt, aber nur dann, wenn sie plötzlich stark abnimmt.

Wie können wir Activity erhöhen?

Wenn du AI Agents in den Entwicklungsprozess deines Teams integrierst (was du tun solltest), erhöht sich das Volumen der sichtbaren Handlungen deiner Engineers automatisch. Das ist genug. Wie wir in Teil eins bereits gelernt haben, ist stark davon abzuraten, diese Metrik zum Ziel auszurufen. An dem Punkt fällt sie ohnehin Goodhart’s Law zum Opfer.

C: Communication & Collaboration

Was messen wir?

Wie gut ist der Informationsfluss im Team und wie gut koordinieren sich Teams bzgl. Wissensverteilung, Review-Kultur und Onboarding?

Wie messen wir das?

Viel passiert in privaten Kanälen, sodass eine direkte Messung schwer ist. Auch hier gibt es einige Proxies, die man nutzen kann, z.B.:

• Wie lange sind Pull Requests offen?
• Wie viele Reviewer gibt es pro Pull Request?
• Wie viel Zeit vergeht, bis ein neues Teammitglied zum ersten Mal eine Änderung mergen kann?

Zusätzlich können Kommunikation und Zusammenarbeit über regelmäßige Befragungen erfasst werden, durch Punkte wie „Ich finde schnell den richtigen Ansprechpartner“.

Wie wichtig ist das?

Informationsfluss und Wissenstransfer bestimmen, wie kaum ein anderer Mechanismus, was genau dein Team baut. Unklare Anforderungen sorgen dafür, dass die falschen Features gebaut werden. Fehlende Informationen erhöhen das Risiko schlechter Entscheidungen. Fehlende Ansprechpartner sorgen dafür, dass Ideen oder Probleme nicht zur Sprache kommen.

Wie können wir Communication & Collaboration verbessern?

Hier einige Beispiele, die wieder davon abhängen, welche Proxies du wählst:

1. Verteilung der Review-Last verbessert den Wissenstransfer.
2. Pairing- oder Mob-Sessions verteilen Wissen und führen zu besseren Entscheidungen.
3. Eine effiziente und aktuelle Dokumentation reduziert Abhängigkeiten und fördert unabhängiges Arbeiten.
4. Eine gut gepflegte Onboarding-Checkliste ermöglicht es neuen Teammitgliedern, schneller produktiv zu sein.
5. Ein fester Onboarding-Buddy für jedes neue Teammitglied reduziert die Hemmschwelle, Fragen zu stellen, und fördert die Integration ins Team.

E: Efficiency & Flow

Was messen wir?

Wie ungestört kommen Engineers voran (bzgl. Unterbrechungen, Wartezeiten und Übergaben)?

Wie messen wir das?

Efficiency und Flow lassen sich messen über Change Lead Time (DORA), Wartezeiten zwischen Workflow-Stufen oder die Anzahl der Übergaben pro Mitglied. Ebenso lohnt sich ein Blick in den Kalender der Entwickler: Wie viele Blöcke ungestörter Fokuszeit gibt es? Wie lang sind diese Blöcke durchschnittlich?

Untermauern kann man diese Eindrücke auch hier über Umfragepunkte wie „Ich hatte genug ununterbrochene Fokuszeit für meine Aufgaben.“

Wie wichtig ist das?

Kontextwechsel sind sehr teuer, und volle Kalender oder zu kurze Fokusblöcke reduzieren die Effizienz eines Entwicklers massiv.

In Zeiten von Agentic Coding gibt es jedoch eine neue Herausforderung: Wo ein Entwickler vor ein paar Jahren noch in eine Art „Flow-Zustand“ kommen konnte, in der er sehr effektiv schwierige Probleme lösen und Themen vorantreiben konnte, übernimmt heute oft Claude Code oder Codex. Diese neuen Workflows bringen Wartezeiten mit sich, die wir vorher so nicht hatten.

Wo man vorher mit Fokusblöcken im Kalender und meetingfreien Tagen helfen konnte, verschiebt sich die Verantwortung für den Flow-Zustand heute auf den einzelnen Menschen. Ich sehe immer häufiger, wie Entwickler in den Wartezeiten das Thema wechseln (und damit den Kontext) oder Short-Form-Videos schauen.

Ehrlicherweise ist dieses Problem Stand Juni 2026 nicht gelöst und es lässt sich mutmaßen, dass dieses Phänomen, ähnlich wie z.B. Burnout, zu einem der ungelösten Probleme unserer Branche werden wird.

Wie können wir Efficiency & Flow verbessern?

Abgesehen von der individuellen Ebene, die ich gerade kurz angerissen habe, kannst du auf Team-Ebene folgende Lösungsansätze ausprobieren:

1. Feste Fokusblöcke fördern, indem Meetings z.B. grundsätzlich vormittags stattfinden müssen.
2. Meetingfreie Tage sind oft nur schwer umsetzbar, aber zumindest einen Versuch wert.
3. Schnellere Build-Pipelines reduzieren das Risiko unnötiger Wartezeiten.

Auf persönlicher Ebene kann es sich lohnen, sich gegen heftige Automatisierung und Parallelisierung auszusprechen und stattdessen zu schauen, ob der Performancegewinn durch AI Agents auch ohne Multitasking schon spürbar ist.

Welche der SPACE-Metriken sind im Jahr 2026 am wichtigsten?

Wie der Deep Dive oben zeigt, kannst du die SPACE-Metriken nicht so direkt erheben wie die DORA-Metriken. Entsprechend höher ist der Mehraufwand. Wichtig vorab: Ich kenne kein Team, das alle fünf DORA-Metriken und alle fünf SPACE-Metriken erhebt.

Die Autorinnen und Autoren selbst empfehlen, mindestens drei Metriken zu erheben. In Zeiten von Agentic Coding ist meine absolute Empfehlung, die folgenden drei Metriken regelmäßig zu erheben und auszuwerten:

1. Satisfaction & Well-being
2. Communication & Collaboration
3. Performance

Du wirst sehen, dass sich Efficiency & Flow in Teilen aus dem qualitativen Feedback zu Satisfaction & Well-being und deinen Beobachtungen in Communication & Collaboration ergibt. Activity halte ich im Jahr 2026 für hochgradig gefährlich und mit Abstand am wenigsten aussagekräftig.

Der einzige Fall, in dem die Messung der Aktivität wertvoll würde, ist, wenn sie unerwartet stark zurückginge. Doch selbst dann lässt sie die Frage nach dem „Warum“ offen, weshalb du spätestens dann wieder auf die anderen Messwerte aus SPACE und DORA zurückgreifen müsstest.

Abschluss

Mit dem Ende dieser Reihe hast du nun alle Werkzeuge, die du brauchst, um sowohl die Delivery Performance als auch die Produktivität deines Teams und seiner Entwicklungsprozesse zu messen. Du kennst jetzt die Gefahren, die durch falsche oder zu wenige Messwerte entstehen, und weißt, wie du Goodhart’s Law umgehst, sodass deine Messungen effizient bleiben.

Mit diesem Wissen hast du deiner Konkurrenz etwas Wichtiges voraus: Sobald du regelmäßige Messungen durchführst, kannst du beurteilen, wie sich Veränderungen in deinem Team oder deinem Unternehmen auswirken, und fundiert Antworten auf die Fragen geben, die im Jahr 2026 alle umtreiben:

Machen AI Agents uns schneller? Wird unsere Software instabil? Wie geht es meinen Mitarbeitern mit den Veränderungen? Sind die Agents ihr Geld wirklich wert?

Wie mache ich am besten weiter?

Alles, was zu tun bleibt, ist, die notwendigen Grundstrukturen zu schaffen, um die Werte erheben zu können:

1. Finde heraus, welche DORA-Metriken du aus deiner vorhandenen Infrastruktur ablesen kannst, und schaue dir z.B. ergänzend Apache DevLake an.
2. Entwickle ein Formular für eine Mitarbeiterbefragung, um die wichtigsten SPACE-Metriken zunächst vierteljährlich zu erheben.
3. Sammle die qualitativen und quantitativen Daten an einem Ort, z.B. einem Dashboard, sodass du alles auf einen Blick sehen und beurteilen kannst.
4. Warte, bis du genug Daten hast; miss mindestens drei Monate, bevor du irgendwelche Rückschlüsse aus den Ergebnissen ziehst.
5. Verbessere dich und dein Team kontinuierlich. Sei experimentierfreudig. Sei offen für Veränderungen.

Falls dir die Reihe geholfen hat, freue ich mich, wenn du den Artikel-Link an deine Kollegen sendest. Solltest du Hilfe bei der Umsetzung benötigen, schreib mir an hi@martinzoeller.com oder buch dir einen Slot für ein unverbindliches Gespräch.