The pursuit of software excellence fuels business performance. As businesses grow to become powered by digital technology, engineering teams have taken the spotlight in leading innovation and process refinement and equipping businesses to be more future-ready. According to a McKinsey study of over 400 large enterprises across 12 industries, companies with high-performance engineering teams best their competition in all areas, including revenue growth, customer satisfaction, and brand perception.
To thrive in a competitive business environment, organizations have to promote innovation and optimize the performance and speed of their engineering teams - all of which needs a high alignment. Such optimization demands highly reliable data to support objective assessment and continuous improvement of software development teams. Often, this data is hard to access, expensive, and unholistic, leaving gaps in engineering leadership’s insights. However, there have been emerging philosophies and frameworks to identify what to measure and how to use metrics to facilitate continuous improvement of dev teams. One such framework is the usage of Git analytics.
What is Git Analytics?
Git is a version control system used to maintain, share, and collaboratively develop code. Programmers use Git to track changes made to code. Git analytics allows users to gain visibility into programmers’ work activity by measuring engineer output, processes, and work quality. These engineering analytics provides managers with a viewpoint to assess their team’s performance and project health.
Why Should Teams Analyze Git Metrics?
Continuous Improvement
Git analytics allows managers to assess and evaluate the performance of their dev teams. It enables them to identify inefficiencies that risk delivery and also equips managers with data insights that enable them to take necessary action. Data-driven insights to guide team management will assist engineering leaders in reducing engineering inefficiency. This allows teams to foster a culture of continuous improvement.
Preventing bottlenecks
Git analytics can provide visibility into a developer’s work activity, serving as a log of engineer’s tasks, progress, and challenges. Managers can use this viewpoint as a daily overview of each developer’s work pattern and identify bottlenecks or anomalies. Using historical data of anomalies, managers can plan 1:1 meetings and stand-ups geared towards process improvements and optimization.
Developer Satisfaction
Analytics dashboards provide visual cues to developer performance and progress. Such visualization incentivizes and promotes intrinsic work motivators such as the developer interest, commitment, and effort. Such intrinsic motivation can translate to better job performance and employee satisfaction, which are critical to employee retention.
Optimized Workloads
Git metrics tools provide a single source of truth to managers and developers. Managers have easily accessible and reliable sources of performance data on their team members. Developers gain workplace visibility even if they are working on relatively low-visibility (but, high impact) work. Such a data-driven view helps managers optimize workloads and also helps prevent burnout by removing the onus of workplace visibility from the developers.
What Metrics Should Teams Measure?
Cycle time
Software development cycle time is the period of time from an engineer’s first commit to the deployment of code. The metric provides insights into the speed of the dev team, that is, the time taken to complete projects, and the overall performance of the team. It measures the efficiency and ability of a team in delivering projects within a given timeline.
When leaders optimize cycle time, they can optimize their team’s tools and processes to adequately support their teams. At instances when cycle time increases when compared to expected benchmarks, leaders can preempt threats to delivery and preserve developer productivity by reorganizing their teams and managing workload to optimize performance.
Rework vs New work
Rework, also known as code churn, refers to the frequency at which an engineer edits their own code. Although a certain level of rework is usually acceptable and normal for engineers, high levels of code churn can indicate inefficiencies in the software development cycle.
New work refers to the code that is produced anew by an engineer.
When rework is contrasted against new work, it helps paint a picture of an engineer’s productivity and contribution towards creating new assets or contributing to new development aligned with the team’s goals. By monitoring this metric, managers can assess whether their teams are progressing efficiently towards creating value. When this indicator is negative, it serves as a sign that helps managers optimize their team’s code churn, maker time, and goal alignment.
Code Review Metrics
Review involvement
Review involvement measures the fraction of a team’s Pull Requests that an engineer is involved in. The PR review process is a hallmark of dev team collaboration. Often involving several stakeholders, the review process checks for completeness and quality of each release and has great implications on a dev team’s ability to deliver business value. Since PR reviews are a critical aspect of a dev cycle, measuring review involvement indicates an engineer’s interest, ability, and efficiency in working as a cohesive team, contributing to the team’s shared goal, and providing valuable input to the team’s work product.
When review involvement for an engineer is lower than team benchmarks, it could indicate inefficiencies in several potential areas such as inefficient PR size allocation or poor workload allocation, or a lack of skill or expertise, or even burnout. When managers track review involvement, they are able to optimize cycle time and align their team members towards delivery goals.
Response Time
Submitter response time is the average time it takes for the coder that raised the PR to respond to a review. It is calculated based on both, response as a follow-on commit, or just an addressed comment.
Reviewer response time represents the average time it takes for a reviewer to respond to a comment by a submitter on their PR. When the response time is high, it leads to a task being left as work in progress. The longer the response time, the more difficult it might get to rework the project with accuracy and creativity due to a loss of context and continuity. It also leads to increased cycle time and causes high rework time.
Unreviewed PRs Merged
This metric represents the count of PRs that were merged without a review. This includes not only PRs that were not approved but also those that were not reviewed at all. PR reviews are a critical process of the dev cycle to ensure that the code is complete, addresses the requirements, is error or bug free, and is of high quality. When teams merge unreviewed PRs, they risk the efficiency of the entire project. Thus, this is an important metric to gauge the quality of dev team processes.
Merging unreviewed PRs is often the reason why some teams have deceptively low cycle time. Even though low cycle time is desirable, having very low cycle time of less than a couple hours is often a signal of compromise on process quality either through merging unreviewed PRs or a low quality of reviews.
Pickup Time
PR pickup time is a component of the cycle time metric. It can be defined as the time between when a pull request is raised and until a review has started. Teams that adopt efficient review processes ideally have their pickup time benchmarked in minutes. When this metric inches higher than a few hours, it could be a signal of inefficient processes including poor workload allocation and high number of work in progress tasks, high PR size, or poor workflows for transfer of projects.
Git Analytics is Not the Complete Picture
Git analytics does not accurately reflect individual performance. While one might be tempted to base the performance of developers on Git based metrics, this is more often than not a bad idea. And this is simply because Git is a collaboration tool and drives workflow and team metrics rather than individuals. Git analytics represent workflow and team metrics. The insights from Git are measurement of developer performance cannot be distilled down to a few metrics and should not be used without context.
Git analytics, when combined with other engineering management metrics, can provide a holistic understanding of development team performance. This understanding is particularly valuable now, as remote work and hybrid teams have become the order of the day. In this future of work, leaders must ensure they preempt and manage inefficiencies, boost visibility, and preserve developer productivity. In this effort, engineering analytics will serve as an indispensable tool to enable engineering team success.
Hatica is a comprehensive engineering analytics tool that couples git analytics with activity from all the tools that developers use to map out workflows and discover opportunities for your team to be better and faster while ensuring well-being. Discover how Hatica can equip your engineering teams to perform at their best. Request a demo with Hatica today!
Top comments (0)