Das SPACE-Framework zum Verständnis von Entwicklerproduktivität

Die Produktivität von Entwicklungsteams umfasst weit mehr als nur Effizienz und Menge. Es braucht zusätzliche Blickwinkel, um dieses Thema zu verstehen.

Das SPACE-Framework bietet eine Denkhilfe an, um Entwicklerproduktivität ganzheitlich zu analysieren. Diese umfassende Betrachtungsweise ermöglicht Teams und Unternehmen, sich zielgerichtet zu verbessern und die Auswirkungen von Interventionen klar zu erfassen.

Um nun die Produktivität von Entwicklerinnen und Entwicklern besser zu betrachten, gilt es zunächst, mit einigen falschen Vorstellungen aufzuräumen.

Mythen über Entwicklerproduktivität

Das große Problem des Begriffs „Produktivität“ ist, dass es keine allgemeingültige Definition gibt. Somit ist ein wichtiger erster Schritt in jeder Diskussion rund um das Thema zunächst festzulegen, was alle beteiligten Parteien darunter verstehen.

Das einführende Paper zum SPACE-Framework listet die folgenden Fehlvorstellungen auf:

• Produktivität dreht sich nur um Entwickleraktivitäten. Mehr Commits, Pull Requests, gelieferte Story Points oder abgearbeitete Tickets bedeuten mehr Leistung? Nicht zwangsweise, wenn z. B. dadurch kein Wert für eine Kundin entsteht. Zudem sind die genannten Kennzahlen sehr einfach zu manipulieren. Natürlich kann ein Mehr an Aktivitäten bedeuten, dass es Verbesserungen im Entwicklungsprozess oder den Entwicklersystemen gibt. Doch wie kann das erkannt werden, wenn Produktivität nur eindimensional betrachtet wird?
• Produktivität ist nur eine Frage der individuellen Leistung. Hier gilt wieder die alte Weisheit: lokale Optimierung führt zu globaler Suboptimierung. Natürlich zahlen Einzelleistungen auf die Gesamtleistung eines Teams ein. Doch der Fokus muss auf der Produktivität des Teams liegen. Müssen oder wollen Entwicklerinnen und Entwickler nur persönliche Ziele erreichen, kann das der Gesamtleistung schaden.
• Eine einzige Produktivitätskennzahl kann uns alles sagen. Die Durchführung von Projekten bzw. die Entwicklung von Produkten ist ein hochkomplexes Vorhaben mit vielen Unbekannten. Betrachte ich ein solches Vorhaben nur mit einer Brille, übersehe ich Nebenwirkungen. Und da jedes Team anders ist, taugt eine einzelne Kennzahl auch nicht zum Vergleich mit anderen Entwicklungsteams.
• Produktivitätsmessungen sind nur für Manager nützlich. Hier versteckt sich ein wichtiger Grund von Widerständen gegen die Messung von Produktivität: wenn Manager Metriken nutzen, um den einzelnen Menschen buchstäblich daran zu messen und zu bewerten. Das ist ein Beispiel für ein Fehlverständnis von Entwicklungs- und Teamarbeit. Damit werden die Chancen verbaut, die Metriken bieten können: Verfolgung von Veränderungen, Zufriedenheit und Gesundheit von Entwicklerinnen und Entwicklern und vieles mehr.
• Produktivität bezieht sich nur auf technische Systeme und Entwicklungswerkzeuge. Ja, diese Tools und Prozesse spielen eine wichtige Rolle. Doch nicht außer Acht gelassen werden darf die Tatsache, dass sich die Softwareentwicklung immer noch um Menschen und deren Zusammenarbeit dreht. Viele dieser „unsichtbaren“ Punkte werden gerne mal unter dem Begriff „Kultur“ zusammengefasst.

Und genau diese Punkte adressiert das SPACE-Framework durch die Einbeziehung von fünf verschiedenen Dimensionen. Was genau sind nun diese Kategorien und was versteckt sich dahinter?

S wie „Satisfaction and Well-being“ – Wie geht es dem Menschen?

Wie bei den oben beschriebenen Mythen schon aufgezählt, dreht sich Produktivität nicht nur um immer mehr Leistung. Warum nicht auch die Dimension „Zufriedenheit und Wohlbefinden“ betrachten?

Zufriedenheit bedeutet, wie zufrieden Entwicklerinnen mit ihrer Arbeit, ihrem Team, ihren Tools oder ihrer Kultur sind. Wohlbefinden bedeutet, wie gesund und glücklich sie sind und wie sich ihre Arbeit darauf auswirkt.

Die Betrachtung dieser beiden Dimensionen gibt ein Puzzleteil mehr im ganzheitlichen Bild, wie es einem Team geht und wo Hebel für Verbesserungen versteckt liegen. Ein Rückgang der Zufriedenheit und des Wohlbefindens könnte z. B. auf ein bevorstehendes Burnout und eine geringere Produktivität hindeuten.

In einer Umfrage bietet sich für die Bestimmung des aktuellen Zustandes eine Auswahl der folgenden Fragen an:

• Wie zufrieden bist Du mit dem Arbeitsumfeld und der Arbeitskultur insgesamt?
• Wie zufrieden bist Du mit den Werkzeugen und Ressourcen, mit denen Du Deine Arbeit erledigst?
• Wie zufrieden bist Du mit Deiner derzeitigen Work-Life-Balance?
• Wie zufrieden bist Du mit dem Feedback, das Du von Deiner Vorgesetzten erhältst?
• Bewerte den Grad Deiner Zustimmung zu den folgenden Punkten: „Ich habe die Möglichkeit, Kontakte zu knüpfen und mich mit meinem Team/ meinen Kolleginnen auszutauschen.“
• Hast Du das Gefühl, dass Deine Fähigkeiten und Fertigkeiten in Deiner Rolle effektiv genutzt werden?
• Wie zufrieden bist Du mit dem Grad der Autonomie, den Du in Deiner Rolle hast?
• Wie zufrieden bist Du mit der Unterstützung, die Du von Deinen Kolleginnen und Teammitgliedern erhältst?
• Auf einer Skala von 0 bis 10, wie wahrscheinlich ist es, dass Du Dein Team an einen Freund oder Kollegen weiterempfehlen würdest?
• Wie oft fühlst Du Dich von Deiner Arbeitsmenge überwältigt?
• Was sind die Hauptfaktoren, die zu diesem Gefühl der Überforderung beitragen?

Diese Dimension ist ein anschauliches Beispiel für die Wechselwirkungen von Produktivitätskennzahlen. Natürlich kann das Entwicklungsteam zu immer mehr Leistung angetrieben werden. Doch welcher Preis muss dafür bezahlt werden? Welchen Wert hat es, Menschen dafür in den Burnout oder anderweitig aus dem Unternehmen zu treiben?

P wie „Performance“ – Was leistet das Produkt?

Kann ein Entwicklungsteam als produktiv bezeichnet werden, wenn ihr Ergebnis nicht die erwartete Qualität und Wirkung erbringt?

Qualität bezieht sich dabei u. a. auf die Zuverlässigkeit des entwickelten Systems, Menge und Auswirkung von Fehlern und den generellen Zustand des Dienstes.

Auswirkung bzw. Impact umschließt u. a. Kundenzufriedenheit, Kundenakzeptanz und -bindung, Nutzung von Funktionen und eine antizipierte Senkung von Kosten.

Die einfachste Betrachtung dieser Art von Leistung der Softwareentwicklerinnen könnte lauten: Hat der von Entwicklern geschriebene Code zuverlässig das getan, was er tun sollte? Und bei diesem Blick auf Leistung geht es um Outcome statt Output.

In einer Erfassung dieser Dimensionen bieten sich beispielhaft diese Fragen an:

• Wie gut helfen Dir die von der Organisation bereitgestellten Instrumente und Verfahren, die Qualität Deiner Arbeit zu sichern?
• Wie oft stößt Du in der von Dir entwickelten Software auf Bugs oder Mängel?
• Wie häufig arbeitest Du mit veraltetem Code oder musst diesen umgestalten?
• Wie gut unterstützt Deine Organisation Dich bei Deinen Bemühungen, Legacy-Code zu pflegen und zu aktualisieren? 
• Wie gut passt Deine Arbeit zu den allgemeinen Zielen Deines Unternehmens?
• Wie oft hast Du das Gefühl, dass Deine Arbeit einen bedeutenden Einfluss auf Dein Unternehmen oder die Endnutzer hat?
• Wie oft fühlst Du Dich gezwungen, Kompromisse zwischen den Auswirkungen Deiner Arbeit und der Qualität des Produkts, das Du entwickelst, einzugehen?

Andere Datenpunkte wie Uptime, Anzahl Bugs, Kundenbindung und Feature-Nutzung lassen sich auch ohne Umfrage messen. Und mit Kunden kann auch direkt gesprochen werden (ja, wirklich!).

Auch hier zeigt sich eine interessante, mögliche Wechselwirkung: Was nutzt es dem Unternehmen, immer mehr „Output“ zu generieren, wenn dieser keinen Wert erzeugt? Das ist ein Musterbeispiel für Verschwendung und zeigt, dass ein Entwicklungsteam erst mit dem richtigen „Outcome“ wertvoll wird.

A wie „Activity“ – Wie viele Ergebnisse werden erzeugt?

Ja, in Sachen Entwicklungsproduktivität kommt es auch auf den berühmt-berüchtigten Output der Teamaktivitäten an.

Unter Aktivitäten fallen dabei Handlungen oder Ergebnisse, die durch Entwicklerinnen im Zuge ihrer Arbeit abgeschlossen werden.

Doch aufgrund der komplexen und vielfältigen Tätigkeiten, die Entwickler ausüben, sind diese Aktivitäten nicht leicht zu messen oder vernünftig zu quantifizieren.

Dadurch entsteht die Gefahr, vermeintlich einfache Ergebnisse zu zählen, wie die Anzahl von Dokumenten, bearbeiteter Aufgaben, Pull Requests, Commits, Code Reviews oder Lines of Code 🤦

Nur sind diese Zahlen leicht zu manipulieren und können somit jeglichen Erkenntniswert verlieren.

Um zu verstehen, wie die Tätigkeiten von Entwicklern die Gesamtproduktivität, die Entwicklungssysteme sowie die Teameffizienz beeinflussen, liefern die folgenden Fragen erste Einsichten:

• Wie häufig erfordern Arbeitsaufgaben eine technische Dokumentation oder andere unterstützende Unterlagen?
• Wie häufig gibt es Aufgaben, die die Zusammenarbeit mit anderen Teams oder Interessengruppen erfordern?
• Welche Prozesse oder Tools behindern Dich am meisten bei der effektiven Umsetzung von Anforderungen?
• Welche Prozesse und Praktiken behindern am meisten Deine Fähigkeit, kontinuierlich zu liefern und in die Produktionsumgebung zu integrieren?
• Wie viel Zeit verbringst Du mit dem Schreiben und Warten automatisierter Tests?
• Welche operativen Tätigkeiten hindern Dich daran, die Ziele Deines Teams zu erreichen?
• Wie gut fühlst Du Dich darauf vorbereitet, Incidents zu managen oder Bereitschaftsdienste zu übernehmen?
• Wie oft bist Du an der Nachbereitung von Incidents beteiligt und lernst Du aus vergangenen Vorfällen?
• Inwieweit bist Du Dir Incidents bewusst, die in den Systemen, mit denen Du arbeitest, auftreten?
• Wie oft werden in Deinem Team Änderungen auf die Produktivumgebung gebracht?

Wie eingangs erwähnt, können und sollen auch quantitativ messbare Kennzahlen rund um Design, Coding, Continuous Integration, Continuous Deployment und Betrieb in Betracht gezogen werden. Wichtig ist, zu verstehen, welche Korrelationen mit den anderen SPACE-Dimensionen entstehen können.

C wie „Communication and Collaboration“ – Wie sieht die Zusammenarbeit aus?

Welches Verständnis hast Du davon, wie Deine Entwicklungsteams und die Menschen in diesen Teams miteinander kommunizieren und tagtäglich zusammenarbeiten?

Teams, die erfolgreich zur gegenseitigen Arbeit beitragen und diese effizient integrieren, sind auf eine hohe Transparenz und ein Bewusstsein für die Aktivitäten und Prioritäten aller Entwicklerinnen angewiesen.

Eine wirkungsvolle Zusammenarbeit kann den Bedarf an individuellen Aktivitäten (wie unnötige Code-Reviews und Nacharbeiten) verringern, die Systemqualität verbessern, die Gesamtproduktivität aufrechterhalten und Burnout vermeiden.

Um zu erfassen, wie gut Menschen und Teams kommunizieren und kooperieren und wie Informationen innerhalb und zwischen Teams fließen, liefert eine Auswahl der folgenden Fragen erste Erkenntnisse:

• Wie einfach ist es für Dich, relevante Dokumentation oder Wissen für Deine aktuelle Aufgabe zu finden?
• Wie beurteilst Du die Effektivität der Kommunikation und Zusammenarbeit innerhalb Deines Teams?
• Wie einfach ist für Dich, während des Entwicklungsprozesses Zugang zu Kunden oder Endnutzern zu bekommen und mit diesen zu kommunizieren?
• Wie zufrieden bist Du mit dem Code-Review-Prozess innerhalb Deines Teams?
• Auf welche Herausforderungen stößt Du derzeit, die Code-Reviews schwieriger machen, als sie sein müssten?
• Wie gut hat Dich der Onboarding-Prozess auf Deine Rolle vorbereitet?
• Wie einfach war es, während des Onboarding-Prozesses Zugang zu den Tools und Ressourcen zu erhalten, die Du für Deine Rolle benötigst?
• Wie viel Unterstützung hast Du von Deinem Team während der Einarbeitung erhalten?
• Welche Verbesserungen könnten am Onboarding-Prozess vorgenommen werden, um ihn effektiver zu gestalten?

Wie bei jeder anderen Dimension ist auch hier von Interesse, wie sich Kollaboration auswirken kann. Mehr Besprechungen oder anderen Formen von Zusammenarbeit (Pair Programming als ein mögliches Stichwort) können beispielsweise einerseits Kennzahlen rund um Effizienz drücken, dafür die Notwendigkeit für Nacharbeiten reduzieren, die Qualität steigern und die Wissensverteilung fördern.

E wie „Efficiency and Flow“ – Wie ungestört läuft die Arbeit?

Welches Verständnis hast Du davon, wie lange Deine Entwicklerinnen ungestört an einer Aufgabe arbeiten können?

Dabei geht es um die Möglichkeit, Arbeit möglichst „am Stück“ abzuschließen. Oder zumindest mit minimalen Unterbrechungen voranzukommen, sei es individuell oder innerhalb eines Systems.

Für diesen Flow ist es wichtig, Grenzen zu setzen, um produktiv zu werden und produktiv zu bleiben – zum Beispiel, indem eine bestimmte Zeitspanne für die konzentrierte Arbeit reserviert wird.

Um zu verstehen, wie Du Entwickler in die Lage versetzen kannst, ihre Arbeit fertig zu bekommen oder mit minimalen Verzögerungen voranzukommen, liefern die folgenden Fragen erste Einsichten:

• Was hindert Dich derzeit daran, in einen Flow-Zustand zu kommen?
• Wie schätzt Du Deine Effektivität in Hinsicht auf die Erreichung Deiner eigenen oder der an Dich gerichteten Ziele ein?
• Wie zufrieden bist Du mit den Ressourcen, die Dir für die Ausübung Deiner Tätigkeit zur Verfügung stehen?
• Wie lange kannst Du selbstständig und ohne Abhängigkeiten an einer Aufgabe arbeiten?
• Welche Besprechungen könntest Du Dir Deiner Meinung nach sparen?

Natürlich passen hier zusätzlich die quantitativen Kanban-Metriken und -auswertungen zur Erfassung des Flusses der Arbeit. Wie sieht es z. B. mit der Flusseffizienz oder dem Durchsatz aus?

Und auch hier sind wieder die möglichen Nebeneffekte zu beachten. Mehr Effizienz beeinflusst wahrscheinlich die Aktivitäten positiv. Mehr Kollaboration reißt Entwicklerinnen aus dem Fluss. Eine höhere Effizienz kann zu mehr wahrgenommener Zufriedenheit führen und korreliert dafür nicht zwangsweise mit einer höheren Qualität.

Tipps zum praktischen Einsatz des SPACE-Frameworks

Die Möglichkeiten des SPACE-Frameworks sind mit der Vorstellung der fünf Dimensionen zum einen noch nicht ausgeschöpft und können zum anderen überwältigen. Hier deshalb zur Abrundung einige Anmerkungen, Hinweise und Empfehlungen für den Einstieg in die konkrete Anwendung.

• Der Betrachtungsgegenstand kann variieren. SPACE als Denkhilfe hilft nicht nur bei der ganzheitlichen Betrachtung von Entwicklungsteams. Möglich ist auch die Anwendung auf z. B. nur einen Teil des Entwicklungsprozesses, um diesen genau zu durchleuchten.
• Die Betrachtungsebenen können variieren. Die verschiedenen Dimensionen können weiter verfeinert werden durch eine Aufteilung auf Individuum, Team bzw. Gruppe und System. Vorsicht ist geboten bei einem Fokus auf den einzelnen Menschen. Entsprechende Warnungen sind weiter oben im Abschnitt über die Mythen zu finden.
• Wie viele Dimensionen sollen genutzt werden? Es müssen nicht immer alle 5 sein. 3 sind ein guter Anfang. Wichtig ist, dass eben mehr als nur ein einziger Blickwinkel genutzt wird, um die in den vorherigen Abschnitten beschriebenen Wechselwirkungen erfassen zu können.
• Mindestens eine Metrik sollte sich auf Wahrnehmungen beziehen. Die schönste quantitative Kennzahl kann einen verzerrten Blick auf die Lage liefern. Die Einbeziehung und Auswertung qualitativer Wahrnehmungen liefert ein runderes Gesamtbild.
• Individuen und Interaktionen vor dem Einsatz von Prozessen und Werkzeugen. Es ist elementar, bei der Bestimmung der erhobenen Metriken, deren Messung sowie der angedachten Nutzung die „betroffenen“ Menschen einzubeziehen. Dies erlaubt zunächst die Auswahl eines besseren Sets an Kennzahlen, da im Rahmen der Diskussion zusätzliche Sichtweisen und Erfahrungen einfließen. Und durch die gemeinsame Erarbeitung wird die Chance auf Akzeptanz der Messungen erhöht und deren Manipulationsmöglichkeiten verringert. Kurzum: es werden Widerstände abgebaut.

Und der wichtigste grundsätzliche Punkt: Eine Metrik dient der Diagnose und Verbesserung. Sie dient der Bestimmung eines Ist-Zustandes und der Überprüfung der Auswirkung von Interventionen. Wird sie dagegen genutzt, um Menschen zur Rechenschaft zu ziehen oder dient die Kennzahl selbst als Ziel, verliert sie ihren Wert. Goodharts Gesetz sagt das bereits seit 1975: „When a measure becomes a target, it ceases to be a good measure.“

Fazit

Das SPACE-Framework bietet einen Rahmen, um Entwicklerproduktivität multidimensional zu betrachten und gezielt zu erfassen. Dabei gibt es keine festen Metriken vor, sondern unterstützt die Anwenderin dabei als eine Denk- und Analysehilfe.

Die Mischung der verschiedenen Dimensionen macht den großen Nutzen des Frameworks aus. Wechselseitige Abhängigkeiten zu verstehen und zu beobachten, reduziert die Gefahr von Fehlentwicklungen. Diese Spannungen zwischen Kennzahlen sind gewollt und machen eine Steuerung von Maßnahmen erst wirklich wirkungsvoll.

Und durch die Nutzung von mehr als nur einer einzelnen Dimension können Unternehmen besser verstehen, wie Menschen und Teams arbeiten – um auf dieser Basis bessere Entscheidungen zu treffen.

Buchen Sie jetzt eine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.