The office had been taken over. We were all sniffling, aching, and battle-hardened. Tissues and cold medicine shrapnel-filled up our garbage can*. Instead of our salad and burrito place being our daily destination, we feasted on spicy pho, to give us a short relief from pain.
The whole team had been sick from February 12th to about March 18th, 2019, on and off with different team members having various levels of illness at different times. It would come and go without warning. We were basically zombies, or white wights.
But we’re not here to tell you how we overcame this, but rather how our work was impacted by the sickening.
So how did we use Gitalytics to understand the impact on our projects and goals of the entire team being sick?
Let’s look at the obvious one, what the impact of hours worked on actual development compared to previous weeks. Our Work Hours report is not a direct, minute-by-minute, analysis of when engineers are actively working, but rather a calculation based on their commit times. This can still give leadership and team members a relatively close idea if processes and work patterns are abnormal.
As you can see, everyone except Arya, Tyrion and Podrick (who had just joined our team) had a large drop in work hours, with the highest being 60%. Sickness can’t be helped once it’s caught, but being able to communicate and plan for a roughly 25% decrease in output can enable the team to be more proactive in their release schedule. But what if their code was the most amazing, highest retained, code ever?
We can then look at the Churned report to understand whether the code that the team members had written during that period was kept. We define churn as LOC re-written within 3 weeks of the original authoring.
We hadn’t been doing any major new feature builds during this time, so we would expect churn to be roughly the same as usual. Instead, what we found was that churn had increased by 84% compared to the previous period.
Our software development team was not only working fewer hours, but they were less effective during those hours. If you’ve ever been sick (which if you haven't, please tell us your secrets), you can probably understand that you may not be in tip-top shape while fighting off a cold.
Time to Merge for Pull Requests
The Time to Merge for Pull Requests (or Code Review Merges) is a key indicator for us on how overwhelmed the team is or whether we have the right resources in place. During this time period, we saw an increase of time to merge by 51%, to 2 days, and 20 hours. What this means is that when we got back to our healthy state, we would likely be dealing with more bugs caused by delayed merges.
Let's just get this out of the way: Getting sick is really bad for productivity. Next point.
Because of our slowdown, we moved tickets out of this sprint into the next with much higher predictability on the impact of releases. We were able to communicate with senior leadership and other departments why there were delays, and how long those delays would be. All with actual data to back it up, instead of just estimates. We were able to better prioritize not only the next 2 sprints, but we now have a greater understanding of what happens when we all become sick, and we will be able to proactively plan around it.
If you’re a software engineering manager that has a policy in place that discourages sick days, or work from home days, this is a silver bullet for changing that. If you disagree with your company policy on sick days, you can use undeniable metrics to back up your stance. We encourage you to use our findings, as well as your own metrics from a trial.
Gitalytics is a platform that gives software engineering teams the ability to see work patterns and processes of the development process. We have helped over 20,000 software engineers have better processes and receive clearer feedback from their leadership. Learn more at Gitalytics.com, and sign up for a free trial, today.
*Just to make something clear, we are encouraged to work from home and take sick days at Gitalytics. This was just for dramatic effect.