In today's world, data must be a first-class citizen. It drives companies to make smarter, better-informed decisions.

Organisations' engineering teams continuously create data as a by-product of their day-to-day actions.

Pipelines build, time to tenth merge request, and release frequency are all metrics in establishing the quality of your engineering.

Things have come a long way since measuring commits or counting lines of code!

Utilising this data through building visualisations and insights is proven to help teams improve their performance over time.

What are the benefits?

Being able to measure and quantify engineering metrics can enable organisations:

• Identify which teams need enablement - Code coverage, cyclomatic complexity and time to deploy can be used as metrics to indicate teams which may not follow the best engineering practices.
• Evaluate if processes are effective - Lead time, waste and production defects can all suggest improvements with requirements gathering, acceptance test definition and refinement ceremonies.
• Track trends over time - Allowing for long-term decisions and strategic planning such as cause-effect analysis around events such as measuring the effectiveness of introducing new cloud services.

How Can We Help?

At ClearRoute we have identified a model that can help you and your organisation harness the power of data. To get started, we suggest following a process of defining, ingesting, surface and adapting for specific measurements.

This approach allows you to get feedback early on from development teams and pivot if necessary.

Define

When defining metrics, we suggest defining measurements under three main categories.

Quality -The quality of each change released.

Speed - How fast can change be released into production.

Agility - How easily can you create change.

Below we have outlined some measurements we like to use on our engagements.

QualitySpeedAgilityHow many peer reviews per pull requestTime to the tenth pull requestSize and complexity of changeThe cyclomatic complexity of changeRelease frequencySize of the repositoryNumber of open defectsChange success and failure rateLifespan of branchCode CoverageBuild timeCycle lead time

Ingest

Once decided, you will need to start ingesting the data. Often, we find data will originate from multiple sources and will most likely need transforming to become structured and meaningful.

We have found that cloud-native platforms are ideal when performing these extract, transform and load operations.

Depending on complexity or ambition, you may need to decide between a database as a service or something more heavyweight.

We prefer starting small but occasionally a data lake could be more appropriate.

Surface

Once you have ingested data, we need to present measurements to the teams in meaningful ways.

There are so many approaches here. We suggest picking a tool that the relevant teams are incapable of ignoring and need to see.

If this means a weekly report in the team slack channel or a screen next to the scrum board it's really up to you!

Once presented, include your new measurements as part of your development practices.

Use it to arm yourselves in making better engineering and business decisions.

Adapt

Following agile practices, it's important to reflect on our chosen metrics and ensure they are providing value. If value is not being realised, then how can the measurement be improved, or maybe it's more pragmatic to drop tracking the measurement altogether.

Once you’re satisfied with the results, you are now in a position to start the next definition cycle. Remember, there is not a one size fits all approach to utilising data. It will be an ongoing process that will be tailored to each team and organisation. Although, we hope this article can provide a solid foundation for you and your team.

If you’re interested in how to start measuring your engineering and learning more then feel free to get in contact today.