I will start by saying that there’s no real right or wrong answer for this topic but hopefully I can share some of my thoughts and ideas around what I’ve seen work and not work in the past.
I have had this discussion with many companies, engineering managers, scrum masters and head’s of engineering and it always come up as an impossible task.
Firstly, some of the metrics we should rule out!
Don’t use story points or velocity! Story points are great for the team to use to estimate a given task or story to help drive discussion and alignment in the team. But that should be it, you can’t compare teams or other engineers against the same value as they aren’t comparable. Story points and velocity are messing to the team to help them improve day-to-day but are meaningless for anyone outside of the team.
Areas that can increase or decrease story points
- The teams knowledge of the product
- Engineering experience
- The amount of technical debt in n the product
- Test coverage
- Complex deployments
Don’t use git commits! I’ve witnessed git commits being used to measure both an individual engineers contributions as well as a whole team. Git commits are open to Gamification and could drive bad engineering practices.
For example: Someone to commits small changes little of often before submitting a pull request will be seen to be doing more work or adding more value than someone who might be doing the same but will then quash their commits before submitting it for review.
It could encourage behaviours such as:
- Engineers to not squash commits
- A culture of scope creep to make it looks like they’re doing more
- A lot of refactoring more no value
- Slow down delivery
Measures to try and use This wont work for every-time but I find is generally a good place to start
Ownership and accountability of the product Everyone in the team is engaged in the product and the team they work in, they succeed together and fail together and they celebrate both.
As a team they’re also striving to improve both as team and the product.
Note: someone to consider with this is if the product owner isn’t working with the team and open to feedback, time and ideas, you will struggle to meet this one.
The team feel empowered This is a hard one to measure but the key is to see if the team are able to influence the backlog and the product they’re working on. They can make decisions without needed to get to approval from a more senior person etc.
The majority of the team are happy Not everyone in the team will always be 100% happy, we all have personal life that can affect our mood. We also have individual career progression and goals to take into account, because of this we can’t expect everyone to be happy all the time.
As I mentioned above the key here is that as a team they’re happy and celebrate the wins and can
Do they socialise or at least eat together Socialising as a team doesn’t mean going down to pub every night after work and getting drunk together. It’s more about as a team do they like eating lunch together, making sure it’s an inclusive environment. This could also be do they share coffee or tea breaks and talk about their interested outside of work.
Share learnings We’re all human, we make mistakes, we learn from them and we want to share with otherwise you they don’t have to make the same mistakes in the future. Maybe you’ve a particular interest or built something in their own time and would like to show others what they achieved and how they approached it.
After all as engineers, we love to build things!
Conclusion
There’s no solid was to measure this in a modern engineering environment and nor should we be. We ideally should be looking at value the team brings to the business which shouldn’t just be measure by numbers of commits or pull request reviews. The best way of understanding the value a team brings to a company you should ideally be close to them, see how they interact with the business, work with them to solve their challenges together. I hope you enjoyed reading this articulations and found it useful.