Tracking Productivity
Tracking Productivity
What gets measured gets done! - Peter Drucker
If you work as a software engineer (especially as a manager or tech lead), one of the things that you want to track is individual and team productivity. The problem is that productivity is subjective, vague and has shades of grey.
Back in the day (like in early 90's and naughties[00's]), we attempted to track this beguiling quality by trying to track efficiency and used metrics like number of lines of code, features developed per day/week/sprint etc. This approach doesn't work though - you could be staring at your screen for 3 hours and end up writing 3 lines of code and still be more productive than another engineer who is probably writing 100+ lines (without planning, forethought or thinking things through) to solve the same problem. There is also the challenge of spending substantial amount of time deploying your code and writing unit/integration tests - we cannot accurately calculate the ROI of these activities.
So, how do we go about the business of tracking productivity in our modern agile/scrum/anti-waterfall world of software development? An elegant answer was proposed by Accelerate (a multi-year research based book about lean software and DevOps) for tracking team productivity. They propose the following 4 measures for tracking team productivity:
Lead time for Changes - How long does it take to take a requirement and translate it to a delivered feature/functionality/product?
Deployment frequency - how often do you deploy? hint: more often you deploy, the better.
(mean) Time to restore service - How long does it take you to fix a problem in production? You should be able to rollback and recover asap.
Change failure rate - How often does your deployment break the build or introduce bugs? i.e. how robust in your design, review and QA process?
An important point to note is that these are team metrics and not individual contributor metrics. My view is that it is better to track productivity of the team instead of trying to pin down the output of individual contributors.
Now, an astute and a cynical developer might ask - why measure these factors, and not something else like velocity of a sprint? The answer lies in measuring effectiveness as opposed to efficiency. Ideally, you want to measure something that focuses on outcomes with visible (preferably positive) impact and not just output. If you measure the wrong thing, you incentivise the individuals and the team to be better at the numbers game without achieving customer/end-user/business-user delight. These 4 measures will help you focus on high-leverage activities that make your process effective and your team more productive.
To summarise - track team productivity by using the 4 metrics to improve the effectiveness, impact, and quality of your delivery. It might not seem like your cup of tea (initially) but if you persist you will reap the harvest of your measurements in the form of a high performing dev-ops team.