Entwicklerproduktivität neu denken: Das SPACE-Framework für nachhaltigen Wert und Zusammenarbeit

Wenn über Softwareentwicklerproduktivität gesprochen wird, wird es schnell unangenehm schlicht.

Mehr Tickets abgeschlossen? Produktiver.
Mehr Story Points geliefert? Produktiver.
Mehr Pull Requests? Produktiver.
Mehr Commits? Auch produktiver.

Klingt erstmal schön messbar. Ist aber ungefähr so, als würden wir die Qualität eines Restaurants daran bewerten, wie viele Teller pro Stunde aus der Küche kommen. Kann ein Hinweis sein. Kann aber auch bedeuten, dass am Ende kalte Pommes, genervte Gäste und ein brennender Herd übrig bleiben.

Softwareentwicklung ist keine Fließbandarbeit. Auch wenn viele noch das Bild vom einsamen Entwickler im Kellerbüro im Kopf haben: Die Realität ist deutlich mehr Teamsport als Einzelkämpfer-Romantik.

Es geht um Problemlösung, Qualität, Zusammenarbeit, Lernen, Fokus, technische Entscheidungen, Nutzerwirkung und manchmal auch darum, bewusst etwas nicht zu bauen.

Genau hier setzt das SPACE-Framework an.

Warum „mehr Output“ nicht automatisch bessere Produktivität bedeutet

Die klassische Produktivitätslogik kommt oft aus einer sehr industriellen Denke: Wenn hinten mehr rauskommt, war vorne mehr Produktivität drin.

In der Softwareentwicklung funktioniert das aber nur bedingt. Ein Team kann viele Tickets schließen und trotzdem am eigentlichen Problem vorbeiarbeiten. Es kann viele Features liefern, die kaum jemand nutzt. Es kann jede Woche deployen, aber dabei technische Schulden aufbauen wie andere Leute Payback-Punkte.

Und andersherum kann ein Team auf dem Papier „langsamer“ wirken, weil es gerade ein Architekturproblem sauber löst, Wissen verteilt, Abhängigkeiten reduziert oder ein Produktproblem wirklich verstanden hat. Kurzfristig sieht das vielleicht nicht nach Output-Feuerwerk aus. Langfristig kann genau das aber der produktivste Schritt überhaupt sein.

Deshalb ist die bessere Frage nicht:

Wie bekommen wir mehr aus Entwicklerinnen und Entwicklern raus?

Sondern:

Was hilft Teams, wirksam, nachhaltig und mit guter Qualität Wert zu liefern?

Das ist ein kleiner Satz für ein Meeting – aber ein großer Schritt für unser Verständnis von Produktivität.

SPACE als Gegenentwurf zur Metrik-Monokultur

SPACE steht für fünf Dimensionen von Entwicklerproduktivität:

• Satisfaction and Well-being
• Performance
• Activity
• Communication and Collaboration
• Efficiency and Flow

Die Grundidee: Produktivität lässt sich nicht sinnvoll mit einer einzelnen Kennzahl erfassen. Weder Velocity noch Story Points noch Pull Requests noch Deployments erzählen allein die ganze Geschichte.

Sie erzählen Ausschnitte. Manchmal hilfreiche. Manchmal auch ziemlich irreführende.

SPACE ist deshalb kein fertiges KPI-Dashboard, das man irgendwo ausrollt und danach sind alle klüger. Es ist eher eine Denkhilfe. Ein Framework, das uns zwingt, Produktivität aus mehreren Perspektiven zu betrachten.

Und genau das macht es spannend für agile Arbeit.

Denn am Ende geht es nicht darum, Teams besser zu kontrollieren. Es geht darum, gemeinsam sichtbar zu machen, was produktive Arbeit ermöglicht – und was sie gerade blockiert.

S – Satisfaction and Well-being

Die erste Dimension klingt für manche vielleicht erstmal weich: Zufriedenheit, Wohlbefinden, Arbeitsumfeld, Autonomie, Tools, Überforderung, Work-Life-Balance.

Also dieses ganze „Menschenzeug“.

Blöd nur: Ohne Menschen wird Softwareentwicklung überraschend schwierig. Auch mit AI!

Ein Team kann kurzfristig sehr viel liefern, wenn alle dauerhaft am Anschlag arbeiten. Abends länger, morgens früher, zwischendurch noch schnell ein Hotfix, dann ein paar Meetings, dann noch „kurz“ ein Review.

Sieht auf dem Dashboard vielleicht sogar gut aus. Bis es das nicht mehr tut.

Dann kommen sinkende Motivation, mehr Fehler, längere Durchlaufzeiten, innere Kündigung, Wissensträger, die gehen, und Menschen, die nur noch Dienst nach Vorschrift machen.

Satisfaction and Well-being fragt deshalb:

Können Menschen in diesem Umfeld dauerhaft gute Arbeit leisten?

Mögliche Signale können sein:

• Wie zufrieden sind Entwicklerinnen und Entwickler mit ihrer Arbeitssituation?
• Wie gut funktionieren Tools und Prozesse?
• Gibt es genug Fokuszeit?
• Wie hoch ist die empfundene Belastung?
• Haben Teams genug Autonomie, um sinnvolle Entscheidungen zu treffen?
• Gibt es Frustquellen, die immer wieder Energie ziehen?

Das ist keine Feelgood-Dimension. Es geht nicht um Obstkorb-Romantik. Es geht um die Arbeitsfähigkeit des Systems.

Wenn Menschen dauerhaft gegen schlechte Tools, unklare Prioritäten, zu viele Meetings oder permanente Unterbrechungen kämpfen, dann ist das kein individuelles Resilienzproblem. Dann ist das ein Produktivitätsproblem.

P – Performance

Performance klingt erstmal nach Leistung. Und genau hier wird es gerne schief.

Es geht bei SPACE nicht darum, welche Person am meisten arbeitet. Nicht darum, wer die meisten Tickets schließt oder am spätesten noch Teams-Nachrichten schreibt.

Performance meint:

Welche Wirkung erzeugt unsere Arbeit?

Also zum Beispiel:

• Wird das Produkt besser?
• Lösen wir echte Kundenprobleme?
• Werden Features genutzt?
• Sinken Kosten oder manuelle Aufwände?
• Steigt Zuverlässigkeit?
• Werden Bugs weniger?
• Verbessert sich Kundenzufriedenheit?
• Zahlen wir auf strategische Ziele ein?

Das ist die vielleicht wichtigste Verschiebung: weg von Output, hin zu Outcome.

Ein Feature ist nicht erfolgreich, weil es live ist. Es ist erfolgreich, wenn es ein relevantes Problem löst. Ein Projekt ist nicht wertvoll, weil viele Menschen lange daran gearbeitet haben. Es ist wertvoll, wenn es Wirkung erzeugt.

Das klingt banal. Wird aber im Alltag gerne vergessen, sobald Roadmaps, Quartalsziele und Ticketlisten übernehmen.

Performance hilft, diese Frage wieder nach vorne zu holen:

Was ist durch unsere Arbeit tatsächlich besser geworden?

A – Activity

Activity ist die Dimension, die viele Organisationen instinktiv zuerst messen.

Anzahl Tickets. Anzahl Pull Requests. Anzahl Commits. Anzahl Deployments. Anzahl Code Reviews. Dokumentation. Bearbeitete Aufgaben.

Das ist nicht grundsätzlich falsch. Diese Daten können hilfreich sein. Sie zeigen Aktivität im System. Sie können Engpässe sichtbar machen. Sie können helfen zu verstehen, ob Arbeit fließt oder irgendwo hängen bleibt.

Aber: Activity ist gefährlich, wenn man sie isoliert betrachtet.

Mehr Commits bedeuten nicht automatisch mehr Wert. Mehr Pull Requests bedeuten nicht automatisch bessere Produktivität. Mehr Tickets können auch bedeuten, dass Arbeit künstlich kleingeschnitten wurde. Mehr Story Points können heißen, dass das Team besser schätzt – oder einfach großzügiger.

Activity-Metriken sind außerdem leicht manipulierbar. Wenn Menschen daran gemessen werden, wie viele Tickets sie schließen, werden mehr Tickets geschlossen. Ob dadurch bessere Software entsteht, ist eine völlig andere Frage.

Activity sollte deshalb nie allein stehen. Sie ist ein Teil des Bildes, aber nicht das Bild.

Sinnvoll wird sie erst in Kombination mit anderen Fragen:

• Wurde durch die Aktivität auch Wert erzeugt?
• Hat die Qualität gelitten?
• Sind Menschen dabei dauerhaft überlastet?
• Hat sich der Flow verbessert?
• Hat sich Zusammenarbeit verbessert oder verschlechtert?

Activity ist also nicht böse. Sie ist nur ein schlechter Chef.

C – Communication and Collaboration

Softwareentwicklung ist Teamsport.

Communication and Collaboration betrachtet, wie gut Zusammenarbeit wirklich funktioniert:

• Wie gut fließt Wissen im Team?
• Funktionieren Code Reviews als Qualitäts- und Lerninstrument?
• Wie schnell bekommen Teams Antworten von Stakeholdern?
• Wie gut klappt Onboarding?
• Wie klar sind Verantwortlichkeiten?
• Wie gut werden Abhängigkeiten zwischen Teams gelöst?
• Wie offen werden Risiken und Probleme angesprochen?

Diese Dimension ist besonders spannend, weil gute Zusammenarbeit kurzfristig manchmal „unproduktiv“ aussieht.

Pairing? Zwei Leute an einer Aufgabe.
Review-Schleifen? Dauert länger.
Gemeinsames Refinement? Noch ein Meeting.
Wissen teilen? Da schreibt ja gerade niemand Code.

Und trotzdem kann genau das langfristig massiv produktiv sein. Weil weniger Wissen in einzelnen Köpfen hängt. Weil Fehler früher gefunden werden. Weil Entscheidungen besser werden. Weil neue Kolleginnen und Kollegen schneller wirksam werden. Weil Teams nicht ständig dieselben Missverständnisse recyceln. Menschen können im Urlaub tatsächlich erholen.

Schlechte Zusammenarbeit ist dagegen wie Sand im Getriebe. Nicht spektakulär, aber zuverlässig nervig.

Gerade wenn mehrere Teams an einem Produkt, einem Prozess oder einem größeren Wertstrom arbeiten, entsteht Produktivität nicht nur innerhalb einzelner Teams. Sie entsteht auch zwischen Teams: an Schnittstellen, bei Abhängigkeiten, bei gemeinsamen Produktzielen, bei Architekturentscheidungen und bei der Frage, wie schnell relevante Informationen dort ankommen, wo sie gebraucht werden.

E – Efficiency and Flow

Efficiency and Flow schaut darauf, wie gut Arbeit durchs System fließt.

Also zum Beispiel:

• Wie viel Fokuszeit haben Entwicklerinnen und Entwickler wirklich?
• Wie oft werden sie unterbrochen?
• Wie lange wartet Arbeit auf Entscheidungen, Reviews oder andere Teams?
• Wie hoch ist die Flow-Effizienz?
• Wie viele Dinge werden parallel angefangen?
• Wo entstehen Blocker?
• Wie lange dauert es von Idee bis produktiver Nutzung?
• Wie viel Zeit geht in Meetings, Kontextwechsel und Nachfragen verloren?

Das ist der Bereich, in dem viele Teams sofort nicken. Denn jeder kennt diese Tage, an denen man acht Stunden gearbeitet hat und abends trotzdem denkt: „Was genau ist hier eigentlich passiert?“

Ein bisschen Meeting-Tetris, drei Chat-Pings, eine ungeplante Eskalation, ein Kontextwechsel in ein anderes Thema, dann noch ein Review, dann war die Konzentration endgültig im Eimer.

Flow ist deshalb zentral. Nicht, weil Menschen effizienter wie Maschinen laufen sollen, sondern weil gute Entwicklungsarbeit Konzentration braucht.

Aber auch hier gilt: Effizienz allein ist nicht genug.

Ein Team kann sehr effizient das Falsche bauen. Oder sehr schnell schlechte Qualität liefern. Oder Durchsatz erhöhen, indem es Zusammenarbeit reduziert und technische Schulden ignoriert.

Deshalb braucht auch Efficiency und Flow den Kontext der anderen Dimensionen.

Die bessere Frage lautet nicht:

Wie machen wir Entwickler noch effizienter?

Sondern:

Was hindert Teams daran, gute Arbeit ohne unnötige Reibung zu leisten?

Die eigentliche Stärke: mehrere Perspektiven gleichzeitig

Der größte Wert von SPACE liegt nicht in den einzelnen Dimensionen. Der Wert liegt in der Kombination.

Ein Beispiel:

Ein Team liefert weniger Tickets als vorher. Nach klassischer Output-Logik: Problem.

Mit SPACE könnten wir genauer hinschauen:

• Satisfaction: Ist das Team überlastet oder frustriert?
• Performance: Ist der Impact trotzdem gestiegen?
• Activity: Hat sich die sichtbare Aktivität wirklich reduziert?
• Collaboration: Verbringt das Team mehr Zeit mit Abstimmung, weil Abhängigkeiten gestiegen sind?
• Flow: Gibt es mehr Wartezeiten, Blocker oder Unterbrechungen?

Plötzlich ist die Diskussion deutlich besser. Weniger „Warum seid ihr langsamer?“ und mehr „Was passiert gerade im System?“

Und genau das ist der Punkt.

SPACE hilft, Produktivität nicht als Charaktereigenschaft von Teams oder Einzelpersonen zu betrachten, sondern als Ergebnis eines Systems.

Bitte nicht als Personenbewertung missbrauchen

Der wichtigste Warnhinweis: Metriken zur Entwicklerproduktivität dürfen nicht zur Bewertung einzelner Personen missbraucht werden.

Also bitte kein Dashboard mit „Commits pro Entwickler“, „Tickets pro Kopf“ oder „Review-Kommentare pro Person“. Das ist kein Produktivitätsmanagement. Das ist eine Einladung zum Kennzahlen-Theater.

Menschen optimieren dann auf das, was gemessen wird. Sie schneiden Tickets kleiner. Sie machen mehr Commits. Sie vermeiden riskante Aufgaben. Sie kümmern sich weniger um unsichtbare Arbeit. Sie schreiben Code, obwohl vielleicht ein Gespräch das Problem besser lösen würde.

Das Ergebnis: Die Metrik sieht besser aus, aber das System wird schlechter.

Metriken sollten helfen, gemeinsam zu lernen. Nicht, Menschen in Ranglisten zu sortieren.

Gute Nutzung von SPACE heißt:

• Teams werden einbezogen.
• Metriken werden gemeinsam interpretiert.
• Zahlen werden als Gesprächsanlass genutzt, nicht als Urteil.
• Es geht um Verbesserung des Systems, nicht um Kontrolle einzelner Personen.
• Nebenwirkungen werden bewusst betrachtet.

Oder anders gesagt: Sobald sich das Ganze nach Überwachung mit Excel-Geschmack anfühlt, ist man falsch abgebogen.

Wie könnte ein pragmatischer Einstieg aussehen?

Man muss nicht direkt alle fünf Dimensionen perfekt messen. Das wäre wahrscheinlich sogar der schnellste Weg, das Thema mit Anlauf gegen die Wand zu fahren.

Ein sinnvoller Einstieg wäre pragmatisch.

1. Nicht mit Metriken starten, sondern mit Fragen

Zum Beispiel:

• Wo verlieren Teams gerade am meisten Zeit?
• Wo entstehen die größten Wartezeiten?
• Wo haben wir viel Output, aber wenig sichtbare Wirkung?
• Wo leiden Qualität oder Zufriedenheit?
• Wo hängen Teams an Abhängigkeiten?
• Wo fehlt uns Transparenz?

Erst die Frage. Dann die Metrik. Nicht andersherum.

2. Mit drei Dimensionen anfangen

Für einen ersten Einstieg müssen es nicht alle fünf SPACE-Dimensionen sein. Drei gut gewählte Perspektiven reichen oft völlig.

Zum Beispiel:

• Satisfaction and Well-being: Wie arbeitsfähig fühlen sich Teams?
• Performance: Welche Wirkung erzeugen wir?
• Efficiency and Flow: Wo hakt der Fluss?

Das ergibt schon ein deutlich besseres Bild als reine Output-Kennzahlen.

3. Mindestens eine Wahrnehmungsmetrik einbauen

Nicht alles Wichtige liegt sauber in Jira, GitHub oder irgendwelchen Dashboards.

Manchmal muss man Menschen einfach fragen.

Beispiele:

• „Ich habe genug Fokuszeit für meine Arbeit.“
• „Blocker werden bei uns schnell gelöst.“
• „Unsere Meetings helfen mir, meine Arbeit besser zu machen.“
• „Ich verstehe, welchen Wert unsere aktuellen Themen erzeugen.“
• „Ich kann technische Risiken offen ansprechen.“

Solche Aussagen lassen sich regelmäßig und leichtgewichtig abfragen. Nicht als Stimmungsbarometer zum Weglächeln, sondern als ernstzunehmender Input.

4. Teams bei Auswahl und Interpretation einbeziehen

Wenn Metriken über Teams hinweg definiert und dann einfach ausgerollt werden, entsteht schnell Widerstand. Verständlicherweise.

Besser ist: Teams einbeziehen.

Welche Metriken helfen euch wirklich?
Welche wären gefährlich oder missverständlich?
Welche Daten habt ihr bereits?
Welche Gespräche sollten daraus entstehen?
Welche Verbesserungen wollt ihr ableiten?

Produktivität kann man nicht sinnvoll gegen Teams messen. Man muss sie mit Teams verstehen.

Ein Blick aus der Praxis

In vielen Organisationen arbeiten Teams nicht isoliert, sondern in größeren Zusammenhängen: Produktbereichen, Domains, Value Streams oder anderen Strukturen.

Bei flaschenpost nutzen wir zum Beispiel Streams, um mehrere Teams entlang größerer fachlicher Zusammenhänge zu organisieren. Genau in so einem Kontext finde ich SPACE besonders spannend.

Nicht, um Teams gegeneinander zu vergleichen. Das wäre ziemlich sicher der schlechteste mögliche Einsatz. Dann hätten wir am Ende ein Ranking, viel Verteidigungshaltung und vermutlich sehr kreative KPI-Kosmetik. Auch eine Leistung, aber keine hilfreiche.

Spannender ist ein anderer Ansatz:

Wir betrachten den größeren Arbeitsfluss. Also nicht: Welches Team ist produktiver? Sondern:

• Wo verlieren wir im System Geschwindigkeit?
• Wo entstehen Abhängigkeiten?
• Wo blockieren Entscheidungen?
• Wo liefern wir Output, aber wenig Outcome?
• Wo leidet Qualität?
• Wo ist zu viel parallele Arbeit unterwegs?
• Wo sind Teams überlastet?
• Wo funktioniert Zusammenarbeit gut und was können andere daraus lernen?

Damit wird SPACE zu einem Werkzeug für gemeinsame Systemverbesserung.

Man schaut nicht auf einzelne Teams wie auf Verdächtige in einem schlecht beleuchteten Verhörraum. Man schaut gemeinsam auf das System, in dem diese Teams arbeiten.

Das ist deutlich hilfreicher. Und nebenbei auch weniger unangenehm.

Was SPACE nicht ist

SPACE ist kein Zauberstab. Kein Reifegradmodell. Kein Tool. Kein neues Management-Dashboard, das automatisch Produktivität ausspuckt.

Es beantwortet auch nicht allein die Frage, ob ein Team „gut“ ist.

SPACE ist eher ein Denkmodell für bessere Gespräche über Produktivität.

Es hilft, vorschnelle Schlüsse zu vermeiden. Es zwingt uns, Wirkung, Qualität, Zusammenarbeit, Zufriedenheit und Flow zusammenzudenken. Und es erinnert uns daran, dass Softwareentwicklung komplex ist – auch wenn wir sie gerne so messen würden, als wäre sie einfacher.

Mein Take

Für mich ist SPACE vor allem ein Plädoyer gegen eindimensionales Messen.

Ja, wir brauchen Transparenz. Ja, wir sollten verstehen, wo Arbeit hängt. Ja, wir sollten Wirkung und Qualität sichtbarer machen.

Aber wenn wir Entwicklerproduktivität auf „mehr Tickets, mehr Commits, mehr Output“ reduzieren, bekommen wir am Ende genau das: mehr sichtbare Aktivität.

Nicht automatisch bessere Produkte.
Nicht automatisch bessere Qualität.
Nicht automatisch bessere Zusammenarbeit.
Nicht automatisch mehr Wert.

SPACE kann helfen, die Diskussion reifer zu führen.

Weg von:

Wie kriegen wir mehr Output aus den Teams?

Hin zu:

Was brauchen Teams, um nachhaltig wirksam zu arbeiten – und wo steht ihnen unser System gerade im Weg?

Das ist weniger plump. Weniger bequem. Und vermutlich deutlich produktiver.