Software Principle #5: You Are What You Measure
In software and in life, you are what you measure.
If you measure velocity, your team will optimize for delivery. If you measure code quality, you will optimize for that.
You must have both measures and countermeasures to ensure that teams stay on track and don’t stray too far in one direction. Countermeasures, or quality measures, are standard when it comes to tools like Outcomes and Key Results or OKRs to ensure when OKRs are achieved, they are achieved advantageously. For example, setting a sales quota without having any quality measurement around it can result in bad deals in the name of hitting quotas.
Knowing What to Measure
Determining what to measure is important as it will dictate the direction of your team. It will become the default response to problems.
In Principle 4, we discussed using measurement to know what is essential. In Principle 3, we considered using measurement to understand your impact. Measurement is crucial to knowing your context and earning your complexity.
Most of the principles discussed show we can discover an incredible amount of information via measurement.
To determine what to measure, you must first assess your weaknesses and strengths as a team and in the context of the created software system. A classic tool to use for this is a SWOT (Strength Weaknesses Opportunities and Threats) analysis for both your system and team.
Once there, it would be best if you got the data required to measure your strengths first. This will ensure that as you fix your weaknesses, you don’t diminish your strengths or if you do, it’s intentional.
After strengths are measured, target a weakness and measure improvement on that weakness as a team and a system. Work on your most significant weakness first, as it is likely that it will have an impact on one or more of your strengths and you’ll have to manage how much tradeoff you’re willing to make.
Strength can be as a team that you deliver incredibly fast. A weakness of the system could be limited testing. If you don’t focus on this weakness, it will affect your strength in the long term.
However, focusing on it in the short term will also more than likely slow the team down while they build the necessary infrastructure for testing the system.
Measured well, and given the time to create change, a velocity increase will happen in the long term as the team confidently ships more features to production.
Putting Metrics to Work
Metrics can lead to long-term exponential gains, but becoming a mindless zombie simply following metrics will prevent your team from focusing on less tangible things like values.
Just like in software: over-optimization is almost always worse than under-optimization. Human factors like emotional well-being are challenging to measure and practically never measured by software teams.
It can lead to a point where teams are hitting their visible metrics but are burning out or leaving to other companies, which affects metrics in the long term.
In addition to metrics, teams should regularly have retrospectives and team outings to ensure people’s viewpoints are heard and team members know each other and have a bond.
Software is fundamentally a team sport, and trust is a requirement to build something great.
Being thoughtful in the process used to measure software systems is the only way to maintain balanced optimization.
Knowing how to align metrics in your context will assist in creating the desired outcomes and ensure systems and teams are working in alignment.
Regards,
Andrew Wolfe, CEO @Skiplist
Originally posted on https://www.skiplist.com/
