In Post-Covid Era, software development teams are absolutely reconstructing processes and foundations that they are based on.
New paradigms and trends are emerging in tech organizations, startups, and remote teams especially when the majority of their teams are global, remote, and decentralized.
Organizations are still understanding how to tackle these new issues that are arising in their operations, but the reality is that this is the new normal - for the good or for the bad. 🤩
Our ultimate and main objective remains the same:
Deliver to clients high-quality services and software that simplifies their processes.
With remote teams spanning throw multiple time zones, levels of proficiency and cultural backgrounds, engineering managers in traditional organizations have to continually adjust their methods for optimal productivity and efficiency.
As a Software Engineer Manager or Technical Lead, our main role is to guide and educate our teams to deliver flawless and exceptional software that makes our customers come back and our community proud of 👏.
Since TAIKAI's genesis, we have been constantly monitoring the quality of our software, measuring team performance, and checking customer satisfaction to make sure that the company is heading in the right direction to achieve our grand vision. 🚀
During this long and hard journey, we identified the so-called Northstar ⭐️ metrics for our software teams, which help us to improve our processes and deliverables.
So let's find out what metrics are we talking about 👇
The 10 Key Metrics to Measure the Success of Software Development Teams 📏
1.Bugs/Month
These are the number of bugs identified during the month period. Knowing the phase in which a bug was reported is key to determining whether it had been identified too late when the software has already been released and is being used by customers.
2. High Priority Bugs Ratio %
These are the number of high-priority bugs divided by the number of low and medium-priority bugs identified.
3. Bugs/Month Detected in Production
This metric refers to the number of bugs detected in production during the month period.
A healthy development pipeline should be optimized to identify potential issues as early in the process as possible via code review, QA testing, and staging. That said, every once in a while an issue or bugs are only detected when you are in production in front of your crowd 😭.
Although it's natural to happen and part of the software manager's job, an abundance of bugs being noticed in production shouldn't be taken lightly.
When a high percentage of bugs are detected in production, it signals that measures must be adopted to improve your testing and code review processes before any more issues arise.
You can increment the number of code reviewers, review the QA process or analyze with the team what could be improved to decrease this fundamental metric.
4. Velocity/Month
The number of story points delivered by a team during a month. This allows us to verify if productivity levels and deliverability remain at a constant pace.
During festive periods such as December or August, for example, the velocity normally drops by 50%, but this is something that completely aligns with our market cycles.
One thing that I truly don’t recommend is to use this metric to compare teams. Every team has its own set of processes for estimating stories, making it unwise to attempt to compare apples and oranges.
5. Velocity/Sprint
The Number of Story Points per sprint by the whole team. We use this metric to benchmark sprints against previous team sprints, so that we can identify blocking contexts on teams.
The reason for velocity drops are extensive, so be sure your team is able to identify the source of the issue before you implement measures. Poor onboarding processes, low team-motivated teams, bad story plannings, or a high number of drop-ins can ruin the team's delivery and health.
6. Velocity/Developer
This metric refers to the velocity of a team divided by the number of team members it has. In a perfect world, adding team members should lead to improved speed and efficiency. Unfortunately, this is not always the case in reality.
When you have onboarding periods, productivity can be adversely affected. In larger teams - where expertise is diffused across various levels - senior developers could experience a drop in efficiency due to the time consumed when mentoring junior developers.
Be sure to find the right size for your team, otherwise, you will end up getting a very low velocity per developer ratio.
7. Delivery Ratio % (Velocity/Commitment)
This is the ratio between the number of story points committed at the beginning of the sprint versus the number of story points delivered.
If the ratio dips below 60%, it is a clear sign that something went wrong with the team planning or they are experiencing roadblocks on their journey that need to be addressed promptly.
8. Bug Time to Fix (50th percentile) Days /Month
The number of days that the team usually takes to deliver a fix for 50% of the bugs. This metric safeguards your "Time to Fix" KPI from being skewed by an anomalous sample, ensuring that you get accurate insights.
9. Bug Time to Fix (Average) / Month
A traditional average for the time to fix all the bugs closed during a month.
10. Bug Time to Fix High Priority Bugs (Median)/Month 🐞
The number of days that the team usually takes to deliver a fix for 50% of the bugs.
11. Bug Time to Fix High Priority Bugs (Average)/Month 🐞
Average of all the High Priority time to fix” bugs.
Usually, these last two metrics are extremely important in our development cycle. High-priority bugs usually have an impact on an end user so we try to prioritize the delivery of these bugs in our development pipeline.
...
This simple framework was formulated to streamline our development process and eliminate decisions based on intuition and gut feelings.
When you manage a significant number of global software teams your role is to design the foundations, create a good developer experience, and have a single ruler to manage and assess them fairly.
And what better than numbers to manage a computer science team? 😲
"Numbers don't lie" 💯
The challenges of collecting metrics from tracking tools
I personally really believe in this motto, “Numbers don't lie” so the only way to have a broader perspective of the output of our two development teams is to look at metrics and act accordingly to mitigate risks and improve efficiency and productivity.
Most of the metrics described above could not be exported from traditional issue-tracking tools, at least for now. Sometimes you need to bring up your inner ninja script skills to collect all the information from the reports generated by your tracking tools.
One of our team resolutions for 2023 is to export these metrics automatically and get rid of the manual process required to collect them.
Maybe this could be a topic for another technical blog post. 🤞
Benefits of implementing this framework
This framework was created in a very specific context to measure our teams, notwithstanding, we firmly believe it can be implemented in other contexts - from larger organizations to teams that operate on agile methodologies.
To get these metrics from your issue management software sometimes you need to do manual work, but the effort completely pays off when you identify trends and you are able to act and guide your team to find the perfect strategy to mitigate a problem.
At the end of the day, that is the main role of a Software Manager, CTO, Team Lead, or Engineering Manager: to help our teams deliver high-quality software that stands up in front of your crowd.
Nothing should worry you more than this, especially if you are fully committed to growing a startup that wants to become a reference on the market.
Aim to deliver flawless customer experiences
When I wake up in the morning, my goal is to ensure that the members of my team are inspired, motivated, and have all of the necessary resources at their disposal to produce outstanding products.
This could not be the silver bullet framework to achieve success, but we believe it serves as a starting point for any team to start looking more carefully at their deliverables and outputs.
I like to think of the software development process as a traditional factory. It's critical that our processes are efficient and organized, with trained resources who comprehend their mission within each division.
This ensures a steady output in an expeditious manner from all members working together at the same pace.
Final Thoughts 🤔
At TAIKAI Labs, as a customer-centric company, our main goal is to deliver flawless experiences, and we are obsessed to detect issues as soon as possible in our development pipeline.
We tend to optimize our teams to reduce the number of bugs detected in production and have a low bug time to fix issues that have an impact on the user experience or are high priority.
During the last couple of years, this obsession had a good impact on our growth.
If we take a closer look at our Customer Satisfaction Score, we can surely conclude that they are truly satisfied with the service and quality of our delivered software and usually come back to work with us again without looking for another competitor just around the corner.
I hope this article was useful to you as it was useful for us. You are welcome to send us any kind of feedback to improve our efficiency in measuring our software teams. This framework, born from great discussions, is truly our team effort to achieve a proficient and successful delivery team.
Time to focus and keep BUIDLING 💪 🧑💻
Happy 2023 Coding, hope to come back soon with some new thoughts about software engineering.
Top comments (0)