Dev Team Health: Vital Signs To Watch
By: Necco Ceresani
Tags: DevOps, Agile, Devhealth, Development, Software Development

Team Health is the most important KPI for dev leads. Monitor these vital signs during your iteration to identify problems early and prevent developer burnout.

Many of us in software are working longer and harder than ever before. Being at home all day, every day, is blurring the lines between work and home life. On one hand, this work from home experience is wholesome and humanizing. Seeing your boss holding a newborn or wrestling with a curious five year old during product strategy meetings adds a new perception and understanding to the workplace. Something that was often not found in the workplace. Unfortunately the same coin has another side.

As family life blends into worklife, the opposite is happening as well. It’s all too easy to get pinged on slack after dinner and say “I’ll just send that over real quick.” No one wants to be the blocker afterall. This type of always-on mentality is something that many companies are learning to combat because it is unhealthy and a leading indicator of bigger issues down the road.

Keeping the teams pulse at your fingertips is one of the necessary challenges of the team lead.

In a lot of ways the team’s pulse is something that is felt, an intuition if you will. In other ways it is something that can be measured, like work output changes. Great leaders work hard to combine their intuition with quantitative data, providing them with powerful insights into their teams.

I’m not sure I can help you feel the pulse of your team, but I can share the quantitative data I watch at a team and individual level that helps me identify unhealthy behaviors before they become larger issues.

Top Development Team Health Indicators to Watch:

Consecutive Days Worked

Number of Open Tasks per Team Member

Unfocused Work

High levels of Rework

Number of bugs/fire drills per Iteration

Team Members Acting Out of Character

Consecutive Days Works

At LinearB we run 2 week sprint cycles, meaning my team has 10 good working days to accomplish our sprint goals. At larger companies with hundreds of developers, seeing developers log on 11 out of the 14 days might be the norm. This includes being on-call during a sunday night merge or answering a quick slack message on a Saturday.

At smaller companies who employ only a handful of developers, all of which are all at home all day, it’s much more regular to see 12, 13, 14 days logged in per sprint. This is okay during some sprints, big launch weeks for example, but when my lead developer is working at least some of every day for multiple sprints, that is unhealthy.

LinearB’s retrospective view

Consecutive days worked is a leading indicator of team member health. It is the job of the team lead to step in and be the responsible people manager. It’s like putting a 7 year old to bed, they are tired, you know they are tired, but they fight it anyways. If tomorrow is going to be a good day, we need to disconnect, mentally and physically. If you see your people working consecutively, if you find yourself working consecutively, start enforcing mandatory downtime.

Number of Open Tasks Per Team Member

Work balance across development teams has gotten much better over the years. As a team lead myself, I take an active role in knowing what everyone is working on and making sure our more experienced developers aren’t taking on more than they should be.

On the LinearB development team we flag anyone who has more than six tasks open at any one time. What does the flag mean? It means I need to take some time to listen.

LinearB’s Custom Workflow Alerts

There may be a good reason why Oriel has 6 active branches right now, or it might mean that I haven’t provided Miki with the right priorities. Either way, knowing the number of open tasks everyone is working on allows me to open a dialogue and keep my team balanced.

To keep your team members healthy, stop using individual velocity as a KPI, focus instead on providing the right priorities and keeping the work balanced across your whole team.

Unfocused Work

Similar to having too many open tasks, team members who aren’t focusing their efforts on solving one problem before another is a leading indicator of developer burnout. If we take Oriel as the example again, we can see that he is spread across 4 different open tasks and 4 completely different areas of focus. It’s going to be hard for him to immerse himself in any of those problems if he is constantly switching contexts.

LinearB Team Pulse View

Another way to identify unfocused inefficient work is to look at the type of output coming from developers who are spread thin. If someone like Oriel, who is often providing several PR reviews a week, hasn’t participated in any reviews during this sprint, I can infer that his time is being taken up in other areas — meetings, support tickets, bugs, etc. While day-to-day operations like these are important, it’s also crucial to make sure your team members have enough time to block out the business and zone in on solving a single problem.

Identifying people on your team who are spread across several focus areas is an excellent way to prevent developer burnout. Help your people by communicating their priorities and asking what they need so they can focus without switching context.