Evolution of metrics and practice of SPACE (Filed under DevEx)
Evolution of metrics and practice of SPACE (Rubric #DevEx)
My colleagues Sasha Kusurgashev and Dima Gaevsky at the IT Picnic in the summer talked about how we use the SPACE framework to assess the productivity of engineers. Recently, it appeared. recordSashi. (||blown off for two||) So I decided to share a brief sammari of this story.
If you put this sammari into one thought, it is something like “engineers cannot be adequately evaluated by a single digit or a simple numerical indicator” – although this has often been attempted. (For example, the number of commits, lines of code, completed tasks)But each metric reflects only one aspect of the matter and is highly context-dependent. For example, a large number of changes to the code can be indicative of both high team pace and overtime or an inefficient process – without context, such numbers are misleading. The guys gave a bunch of examples of how to take into account many aspects of efficiency: speed, quality of the result, team interaction, employee satisfaction and other factors.
Actually, the first half of the report was about the SPACE framework itself, where the story was based on the article. **"The SPACE of Developer Productivity"**Which I'm talking about. told earlier. The acronym SPACE itself stands for as
- Satisfaction & Well being (contentment)
- Performance (performance)
- Activity (activity)
- Communication & Collaboration (communication)
- Efficiency (efficiency) Each of these dimensions complements the others, creating a complete picture. This multidimensional approach was born as a reaction to the abuse of one-sided metrics and is aimed at making the assessment of the work of engineers more fair and meaningful.
The second part of the talk was about the experience of implementing SPACE, and I think it's the most useful part of the talk. Sasha told how to start collecting metrics and how to interpret. Implementing a multidimensional measurement system was not an easy task – it was necessary to aggregate data from different sources. (Version control systems, task trackers, CI/CD, employee surveys, etc.) And bring them to a single basis for comparison. The authors emphasized the importance of data normalization and correct “cuts” – it is necessary to decide on which sections to analyze the metrics. (Teams, projects, time periods)To identify patterns and problem areas. This was not trivial: different segments showed a different picture, and the wrong slice selection could hide the problem or create the illusion of success. For example, team comparison requires taking into account the specifics of projects; time comparison – taking into account seasonality and changes in circumstances.
It’s cool that the guys honestly shared the mistakes of the first approach to SPACE. At first, they tried to measure everything at once and get an instant integral metric. This has led to data overload and difficulty understanding it. As a result, you should not try to cover all metrics at once without prioritizing. Instead, it’s better to pick a few metrics on the key dimensions that are most relevant to the team’s current challenges and start with them. It is important not to bend the stick and not to drown in data, but to choose the metrics to fit your context. Gradually, when the culture of working with metrics began to form, they expanded the scope of SPACE factors, but already consciously and taking into account the insights received.
You can take these thoughts from the speech. 1) Combine objective metrics with feedback from people 2) Use metrics as a tool to improveNot for punishment. Identify bottlenecks and growth points rather than a developer competition or red tape 3) Enter metrics gradually and meaningfully. Start with a pilot team or referral, select a small subset of SPACE metrics relevant to the most painful problem, and try them out. 4) The role of culture and leadership support. The implementation of SPACE is not a one-time action, but a change in the approach to management
#Processes #Management #ExternalReview #ProductManagement #Leadership #SoftwareDevelopment #Software #SRE