What’s unique about 2021, you might ask. For the first time in history, we might be seeing 1 in 4 Americans working remotely. But, what does it mean for leaders and managers, especially those in technology-driven businesses? It means that despite all the challenges that remote or hybrid work will bring, they will still have to maintain the same pace in delivering reliable software, managing engineering teams effectively, and keeping stakeholders satisfied.
In order to tackle this, leaders need a data-driven framework that can help them gain visibility into engineering work, and understand the alignment with business initiatives. The best approach would be to get a single view of your team’s contributions and work habits, and then, start optimizing your development process.
For that, we have compiled a comprehensive list of all the engineering metrics that you need to keep a track of, to move from a feeling-driven to a data-driven approach:
1. Impact: It is a way to measure the ‘bigness’ of code changes that are happening, in a way that goes beyond simplistic measurements like lines of code. Impact is a measure of work size that takes this into account:
To give you a better context here’s an example: One engineer makes a contribution of 100 new lines of code to a single file. Compare that to another engineer’s contribution, which touches three files, at multiple insertion points, where they add 16 lines while removing 24 lines. The significance of each contribution can’t be boiled down to just the amount of code being checked in. Even without knowing the specifics or the severity of the changes, it’s likely that the second set of changes was more difficult to implement, given that it involved several spot-edits to old code, and therefore has a higher impact score.
2. Active Day: For large teams, it can be very difficult to see who is succeeding and who is struggling, or how the team as a whole is doing. Waydev proposes the idea of Active Days — any day where an engineer contributed code to the project. There are many different forms of engineering work: writing code, reviewing others’ work, discussing specs and architecture. Arguably the most important of these is contributing code, and it’s important for teams to make sure that time dedicated to things other than this stays at a reasonable level.
The global average of “days on deck with code” is about 3.2 days per week. Subtleties of what’s right for each team can vary a bit. Developers who are working on ops stuff or non-code work might only have 1 or 2 Active Days.
3. Code churn: Code Churn is when engineers rewrite their own code in a short period of time. A certain amount of Churn should be expected from every developer. Unusual spikes in Churn can be an indicator that an engineer is stuck. Or high Churn may also be an indication of another problem like inadequate specs. Knowing immediately as your team is experienced churn spikes helps you have timely conversations to surface any potential problems. The industry-standard code churn hovers between 15-30%.
4. New Work vs. Other Work:
New Work is a measure of how much fresh, blue sky work is happening over time. The amount of attention to new work depends entirely on the phase of the product and business. It is very normal for a growing company to aim for more than 50% of their work to be “New Work” which is indicative of forward progress.
Legacy Refactor is the process of paying down on “technical debt”— traditionally very difficult to see. New feature development oftentimes implies re-working old code, so these activities are not as clear cut as they might seem in Scrum meetings. As codebases age, some percentage of developer attention is required to maintain the code and keep things current. Objectively tracking the percentage of time engineers spend on new features vs. application maintenance helps maintain a proper balance of forwarding progress with long-term codebase stability.
Help Others is a measure of how much an engineer is replacing another engineer’s recent code—less than 3 weeks old.
5. Risk: Risk is a measure of how likely a particular commit will cause problems. Risk helps teams put their attention where it’s most needed. This not only helps with quality control but serves as an incredible tool for building engineering talent: by concentrating review on outlier commits, engineers receive high-quality feedback and suggestions for improvement where it’s needed most.
Some notable metrics to mention here:
Waydev increases visibility into team contributions, helps you see where the most significant impact is being made, identifies areas to give concrete feedback, and helps teams understand how process changes impact their effectiveness.
Ready to improve your SDLC performance?
