The SPACE framework aims to debunk the myths about measuring developer productivity and proposes a healthy and practical way to measure it. The fundamental ideology of the framework is Developer productivity is a function of multiple dimensions and tracking only "one metric that matters” can never represent the actual productivity of your team.
Developer productivity is important not only to measure engineering outcomes but also to the satisfaction of your team members, as satisfaction and productivity are highly correlated. As in any team sport, success of both the team and the individual is important.
Developer productivity is important not only to measure engineering outcomes but also to the satisfaction of your team members, as satisfaction and productivity are highly correlated. As in any team sport, success of both the team and the individual is important.
Optimizing only for individual performance would do more harm than good. Key is to find the right balance between individual, team, and organizational success. Any model which reduces developer productivity to a single metric is designed to fail.
Optimizing only for individual performance would do more harm than good. Key is to find the right balance between individual, team, and organizational success. Any model which reduces developer productivity to a single metric is designed to fail.
SPACE metrics span across these five dimensions: Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow. It’s best to measure developer productivity with metrics spanning at least three out of these five dimensions.
“Similar to team sports, success is judged both by a player's personal performance as well as the success of their team. A developer who optimizes only for their own personal productivity may hurt the productivity of the team.“
The biggest source of fulfillment for developers is by doing development that makes a difference. And to ensure a healthy working environment for your team it's important to be mindful of the stress caused by the workload and have measures in place to mitigate it before it's too late. It’s absolutely crucial to include this dimension of SPACE metrics when tracking developer productivity.
SPACE framework suggests the best way to track performance is by measuring outcomes rather than output. Often the outcome of individual contribution is dependent on the type of work that is assigned to the individual. Thus measuring outcomes at a system level can help you understand the performance of your team.
Developer activity when tracked across different phases of the SDLC, can help you with limited insights into the developer productivity and efficiency of your team and engineering processes. However, individually the activity dimension of SPACE metrics will not help you understand true developer productivity.
“Developers often say that productivity measures aren't useful. This may come from the misuse of measures by leaders or managers, and it's true that when productivity is poorly measured and implemented, it can lead to inappropriate usage in organizations.“
This dimension of SPACE metrics is crucial to capture the aspect of how well the team can collaborate and whether there is an optimal flow of information amongst the team members. A team that communicates better and has a culture of transparency is bound to be more productive as team members know about the priorities and what others are working on which makes it much easier to coordinate dependencies.
This dimension of SPACE metrics attempts to capture how well work is done across the team and whether development activities continue without interruptions. Flow tries to capture how many hours can developers dedicate to uninterrupted work and also how swiftly can a piece of work, flow through different processes. DORA metrics do a great job of capturing the flow metrics at a team level.
“The most important takeaway from the SPACE framework is that productivity cannot be reduced to a single dimension (or metric!).“
Read answers to the most common misconceptions and myths about tracking developer productivity.
Developer productivity is not a “taboo”. The reason for running away from developer productivity is that leaders have often represented it as metrics that are easy to track, and not the ones that make more intuitive sense. When developer productivity is tracked for the right reasons it becomes a motivator for the team, where everyone understands that optimizing the right metrics ultimately leads to a happier and more satisfied development team.
Historically developer productivity is either something the leaders run away from or reduce to one metric, which is clearly the worst way to deal with it. The SPACE framework clearly sets out the areas that matter and gives examples of metrics that could be tracked in each dimension. However SPACE metrics are not a fixed set of metrics to track, but more like guidance for teams to select metrics that make the most sense for them.
Not at all. The way developer productivity has been defined in the past is the primary reason for developers’ perception that “productivity measures aren’t useful”. However, developer productivity when measured correctly can also be used by the developers to measure themselves and understand areas of improvement. Given there is a high correlation between productivity and happiness, it becomes even more important for developers to track this.
The underlying ideology of the SPACE framework is, you shouldn’t say Developer productivity = Story points shipped BUT when you say Developer productivity = Story points shipped AND PR cycle time AND Customer satisfaction it completely changes the way you track developer productivity. Starting small is absolutely okay, however, do ensure you track one metric across at least three out of the five dimensions.