Maximizing Developer Productivity: SPACE
Accurately measuring developer productivity remains a myth.
As we discussed last time, When you’re building cars, it’s easy to count the output – the number of cars produced. Building software isn’t like building cars. You can’t simply measure output by measuring lines of code. Some code is written instantly – other bits of code can require so much thought that 10 lines can take an entire day by a highly experienced developer. With remote developers, productivity is even harder.
In past blogs, I’ve talked a lot about remote teams, finding & hiring remote devs and learning & development. Last time, we talked about the DORA framework. This week, we’re covering a new framework: SPACE. Whilst it may not help you accurately measure productivity, it will certainly help you get the most out of your development team.
A team from GitHub, the University of Victoria, and Microsoft published a paper introducing SPACE in early 2021. As they state in their introduction:
Developer productivity is complex and nuanced, with important implications for software development teams. A clear understanding of defining, measuring, and predicting developer productivity could provide organizations, managers, and developers with the ability to make higher-quality software—and make it more efficiently.
Software development is a complex environment. At its core is coding, but there’s design, testing, refactoring, meetings, security, compliance, and so much more to delivering a secure, useful and stable code base. How can developers best use their skills, manage their time, and ensure that their efforts create the most value?
SPACE offers a structured approach, ensuring developers can stay focused on what truly matters and consistently produce results.
The SPACE Framework:
S – Satisfaction & Wellbeing: Satisfaction is how fulfilled developers feel with their work, team, tools, or culture; well-being is how healthy and happy they are, and how their work impacts it. It’s clear how these impact productivity. Measuring them can be done through regular surveys.
P – Performance: Measuring performance from developer (or development) team output is tough. The amount of code isn’t necessarily a good measurement, as quality is equally important. The best way to measure this is by analyzing if the code from the developer does what it’s supposed to do, through a combination of different outcomes: quality, reliability, the absence of bugs, ongoing service health, but also items such as customer satisfaction, customer adoption and retention, feature usage, and cost reduction.
A – Activity: the count of actions or outputs completed in the course of performing work. Think of design documents, specs, commits, pull requests, code reviews, CI/CD tasks, incident work, on-call time, etc. Developer activity is almost impossible to comprehensively measure and quantify all the facets of developer activity across engineering systems and environments. A well-designed engineering system, however, will help in capturing activity metrics along different phases of the software development life cycle.
C – Communication and collaboration: software isn’t developed by individuals, it’s developed by teams. Teams that successfully contribute to and integrate each other’s work efficiently rely on high transparency and awareness of each other’s activities and task priorities. You could measure: discoverability of documentation and expertise, outcome from quality of code reviews, network metrics showing who is connecting with whom, and the onboarding time and experience of new members.
E – Efficiency and flow: the ability to complete work or make progress on it with minimal interruptions or delays, whether individually or through a system. We all know how fast work goes when we’re in a “flow” state, and how annoying it can be to be interrupted (by emails, calls, messages and meetings), or to have to reach out to someone else to continue the work. Metrics that could be measured are: the number of handoffs in a process, the perceived ability to stay in flow and complete work, interruptions (quantity, timing, how spaced, impact on development work and flow) and time measures through a system: total time, value-added time, wait time.
SPACE In Practice
Getting started with Space and measurements may sound like a lot of work. Start by measuring at least three different categories. Most likely, you already have some data (e.g. the number of commits). Add measurement points from some of the other categories. And, combine measurement data with survey data to ensure you have a complete picture.
The original paper has a lot more background information on measurements, where to start and what to watch out for. Read the entire paper before you start creating your plan.
Need more help? Reach out to us for a brainstorm or workshop tailored to your team’s needs!
