◢◢ SPACE Framework
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.
— The SPACE of Developer Productivity
Why do we need a framework to measure our productivity and output?
Bringing structure to the conversation about engineer and team productivity will give us a fair and honest view of:
- where we are
- what the problems and blockers are, and
- what we might do to get more effective and enjoy our time at work more.
We will create better, more fruitful conversations—and, ultimately, more fruitful collaborative relationships—with leadership and other departments if we cultivate a system that shows our workings.
So much of engineering is teamwork. A structure which focuses relentlessly on removing blockers and removing friction from our team systems will serve as a potent “secret sauce” as we grow this team and this product.
Introducing a process around this soon will give us compounding results and allow us to build on it further over the coming years.
Extra Context on SPACE and it's origins at the bottom of this doc 👇
JASPACE v1
Here is our first iteration on how we use SPACE at Just About.
The goal with this first version is to be:
- Simple (low overhead)
- Fair (minimising blame culture)
- Valuable (find the “80%” strengths & weaknesses where adjustments result in the most noticeable positive outcome)
Satisfaction and well-being
I’ll ask each engineer to answer the following questions weekly in our 1:1. Answers should be gut feelings and given a score out of 5.
- How satisfied are you with the week?
- How satisfied are you with the Engineering System (DX, CI, CD etc.) this week?
- How satisfied are you with your personal performance and output this week?
Performance
These performance metrics are team-based. There are a tonne of factors that feed into performance, so we'll focus on how we are performing as a team first.
- What was the average time it took to get a ticket from "In Review" to "In Production"?
- How many bugs were reported?
- How many bugs did we squash?
- How many times did we deploy to production?
Activity
Individual performance is still an important piece for us to look at together. I’ll ask each engineer to report on the following in our weekly 1:1:
- How much time did you spend in "focused coding" mode this week (meaning Slack closed, flow-state style coding)?
- When you were pulled out of that space by low-value work, what did that look like?
- How many code reviews did you complete this week?
Communication & Collaboration
I will ask each engineer to address the below questions in our weekly 1:1:
- How would you rate the quality of our meetings on a scale of 1-5?
- How did you arrive at that number?
- How can we improve?
- How would you rate shared knowledge, discoverability and documentation on a scale of 1-5?
- How did you arrive at that number?
- How can we improve?
Efficiency and flow
In this area, I'd like us to focus on improving our general workflow practices, and understand how the engineers in the team want to pick up work.
I will ask each engineer to address the below question in our weekly 1:1:
- How would you rate the quality of Asana tickets & general ticket workflow (availability of work and ability to complete it) on a scale of 1-5?
- How did you arrive at that number?
- How can we improve?
Conclusion
Performance is the outcome of a system or process.
The performance of software developers is hard to quantify, because it can be difficult to tie individual contributions directly to product outcomes. We still must quantify it.
Thanks for participating!
Context on SPACE and its origins
The SPACE of Developer Productivity was Developed by Nicole Forsgren from GitHub, Margaret-Anne Storey from the University of Victoria, and Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler from Microsoft Research.
It provides a way to evaluate developer productivity as a function of Satisfaction and well-being; Performance; Activity; Communication and collaboration; and Efficiency and flow.
The goal of the SPACE framework is to assess productivity as the complex interplay of multiple factors rather than focusing on a specific metric (like lines of code committed, or pull requests, which reliably drives manipulative and myopic behaviour). This framework aims to reveal a nuanced landscape of what’s going well and what can be dialled in.
A Summary of the SPACE Framework
Satisfaction and well-being
- Satisfaction is how fulfilled we as developers feel with our work, team, tools and culture
- Employee satisfaction: The degree of satisfaction among the team, and whether they would recommend this team to others.
- Developer efficacy: Whether we as developers have the tools and resources we need to get our work done.
- Well-being is how healthy and happy we are, and how our work impacts that health and happiness
- Burnout: Exhaustion caused by excessive and prolonged workplace stress
Performance
- Did our code reliably do what it was supposed to do?
- Quality: Reliability, absence of bugs, ongoing service health
- Impact: Stakeholder satisfaction, customer adoption and retention, feature usage, cost reduction
Activity
- Activity is a count of actions or outputs completed in the course of performing work. Because of the complex and diverse activities that we perform as developers, our activity is not easy to measure or quantify. In fact, it is almost impossible to comprehensively measure and quantify all the facets of developer activity across engineering systems and environments. A well-designed system, however, will help in capturing activity metrics along different phases of the software development life cycle, and quantify developer activity at scale. Some of the developer activities that can be measured and quantified relatively easily are:
- Coding: Volume or count of specs, work items, pull requests, commits and code reviews.
- CI/CD: Count of build, test, deployment/release and infrastructure utilisation.
- Operational activity: Count or volume of incidents/issues and distribution based on their severity, on-call participation and incident mitigation.
Communication and collaboration
- Communication and collaboration is a piece that captures how people and teams communicate and work together. At its heart, software is a team sport. Software is written by teams, not individuals. Understanding and measuring team productivity and team member expectations are, however, complicated because of items that are difficult to measure such as invisible work and articulation work for coordinating and planning team tasks. That said, the following are examples of metrics that may be used as proxies to measure communication, collaboration, and coordination.
- Discoverability: Discoverability of documentation and expertise.
- Integration: How quickly work is integrated.
- Reviews: Quality of reviews of work contributed by team members.
- Onboarding: Onboarding time for and experience of new members.
Efficiency and flow
- The ability to complete work or make progress on it with minimal interruptions or delays, whether individually or through a system
- Number of handoffs in a process: number of handoffs across different teams in a process
- Perceived ability to stay in flow and complete work
- Interruptions: quantity, timing, how spaced, impact on development work and flow
- Time measures through a system: total time, value-added time, wait time