Applying the SPACE Framework
This is the latest issue of my newsletter. Each week I cover the latest research and perspectives on developer productivity. Subscribe here to get future issues.
Laura Tacho, CTO at DX, and I held a discussion yesterday on the DORA, SPACE, and DevEx frameworks, including their differences and how they can be applied. It was a fun conversation, and it was great to hear from the audience about how different teams are measuring developer productivity today. (If you missed it, 70% of respondents are using some type of metrics, whether from DORA, SPACE, DevEx, or something else. 30% are not measuring productivity.)?
Laura also wrote a guide on DORA, SPACE, and DevEx, which goes into greater depth about how each framework should be used and how to collect metrics. In today’s newsletter, I’m sharing an excerpt from her guide which focuses on the SPACE framework. ?
SPACE is particularly interesting because there’s still a lot of confusion around the framework and how it can be used. Here, Laura gives a clear explanation on SPACE and who it’s most useful for.
The SPACE Framework of Developer Productivity
The SPACE Framework of Developer Productivity is a holistic approach to thinking about and measuring software developer productivity. Unlike DORA, the SPACE framework is not a list of metrics or benchmarks. Instead, it outlines five different dimensions of productivity that can inform your own definition of productivity, and by extension, your measurements.
The five SPACE framework dimensions are
Not only does SPACE emphasize the importance of all five categories, it goes further to explain that both workflow metrics (like those used in DORA) as well as perception metrics, like how productive a developer feels, are equally as important when defining and measuring developer productivity.?
Who should use the SPACE framework?
SPACE is a broad framework that gives developers and engineering organizational leaders new vocabulary and mental models to define developer productivity.?
SPACE is a great choice for:
SPACE may not be as useful on teams where developers and leaders are not in a position to improve productivity through interventions, or for leaders who are hesitant to adopt new ways of thinking about productivity.?
How do you implement SPACE?
Since SPACE is a broad framework, all metrics related to developer productivity – even the “bad” ones – fit into SPACE. Additionally, because SPACE introduces other dimensions to consider, such as workflow vs. perception metrics, it can be confusing to understand how to implement SPACE on a practical level.?
“SPACE metrics” simply don’t exist, and it’s a misconception to think that it’s possible to swap out DORA metrics and use SPACE metrics instead. SPACE is a framework that does not come with a punch list of things to measure. Instead, SPACE provides guardrails and mental models when crafting your organization's definition of productivity, ensuring that you don’t overlook an important aspect of productivity and pay the price later by damaging culture or leading to burnout.
领英推荐
Using SPACE to challenge assumptions about productivity and uncover gaps in your teams’ thinking is a great way to get started with SPACE on your teams. An exercise to do this is to use an online whiteboard tool and have your team members create a sticky note for each measurement of productivity. Then, drag each measure into the corresponding SPACE category.?
In the case of the team below, this helped them see that they did not naturally view measurements of Satisfaction and Well-Being or Communication and Collaboration as part of their own definition of productivity. Many teams will discover the same, as the S and C categories are often absent in definitions of developer productivity. This is an area of strength for SPACE:
Another way to begin using SPACE is to introduce self-perception metrics as a way to measure developer productivity. Taking a closer look at the metrics from the team exercise above, we notice that all of the metrics can be collected from developer tools. The voice and experience of the developer, which SPACE data shows is equally important, is absent.?
If this is the case with your team, don’t worry – it’s normal. Often, engineering leaders and developers have a tendency to value automatically collected metrics more than self-reported metrics, and more than measurements of perception, like “how satisfied are you with our code review process?”?
But workflow measurements only tell part of the story. Take for example two teams that both have an average code review time of 12 hours. For one team, this is sufficiently fast, and does not delay work in a meaningful way. For the other team, it feels like swimming through mud, and the perception is that code review timing is a huge bottleneck. We can’t see this when only looking at the numbers, which is why SPACE advocates for including both measurements of perception alongside workflow measurements.
What’s important to consider about the SPACE framework?
SPACE is a holistic and comprehensive way to think about developer productivity. It advocates for balance in multiple ways:
Because SPACE is a framework, it is still up to you to define productivity, and then select metrics that align to your definition. SPACE is a useful tool to reduce the likelihood of omitting important dimensions of productivity based on the latest research.?
Practice caution here. Just because a metric falls within a SPACE category does not mean it is a “good” metric or that it will not cause cultural damage when introduced.
It might be the case that there is hesitancy to adopt new ways of thinking about productivity outlined in SPACE, particularly for organizations and leaders that have experience with DORA metrics. DORA is very concrete, whereas SPACE is very abstract, and focuses equally on developers’ experiences as it does on metrics from tools. This might feel “squishy” to leaders who have developed a taste for quantitative metrics. An important consideration to keep in mind when advocating for SPACE is that Dr. Nicole Forsgren, the lead researcher for DORA metrics, is also the lead researcher for the SPACE framework. Though they measure different things – DORA focusing on software delivery performance and SPACE focusing on developer productivity – the research informing both frameworks is equally as rigorous.
One drawback of SPACE is that it can be difficult to understand because it is so vast. It’s not necessary for all developers in your organization to understand SPACE even if you are introducing a collection of metrics that were developed using principles from SPACE, so don’t view organization-wide understanding of SPACE as a limiting factor to your progress.?
Read the full guide from Laura for more on the SPACE framework and how it relates to DORA and DevEx.
Thanks for reading. As always, reach out with any thoughts or questions here on LinkedIn.
-Abi
Founder@Promptility Research
8 个月I have my own framework that I call PAIN, just to remember it, for performance, activity, ( as in SPACE), intensity is for how intense are communications, and negativity is for how much negative behaviors are there in a team. It has some interesting characteristics to make it more agile ( can operate in many varied scenarios ) since the first two dimensions are positive in contrast to the rest. Instead of trying to maximize a metric ( such as SPACE ) it is permits to also compensate with PA for IN. On the other hand it does not permit degraded performance as in SPACE where the metric is posititive while performance is at zero. There is very little value to not producing even if everyone is happy with communication and well being of the team. On the other hand it is much more realistic as it penalizes over performance at the expense of negativity, and captures transformational team building phases better, moving from a negative value to positive values.
Transforming SaaS startups into scaleups
9 个月Qualitative / perception metrics are such a key (and often overlooked) part of measuring team performance. I've found they can give you high-quality, actionable insights and the ability to drill down into underlying issues more than quantitative measures. Especially when teams are just starting to look at performance and/or going through the forming/storming/norming phases. Great, detailed writeup Laura Tacho Abi Noda
Unbundling startup risks ???
9 个月???