Does high velocity lead to burnout? That may be the wrong question to ask.
In a webinar we did with Liberty Mutual, we explored how to create “high velocity” teams and sustain them. It was a great exploration around morale, tools, and other ways we can organize folks to make sure teams output the best quality work they can. Though reaction to individual points was positive, the overall message was overshadowed by a semi-recurring sentiment: a high-velocity team means people are burning out.
Most tenured folks probably have experience with an overbearing boss or project manager cracking the whip, following an old and tired trend of getting more hours out of developers at any cost to move the needle just a few notches more. But it doesn’t have to be this way, in fact I would say it shouldn’t be this way if you are planning for a stable team with high morale that can consistently deliver.
What do you mean, “high velocity?”
As much as I hate how these discussions devolved into semantics at times, there is something we have to get out of the way: what the heck do we even mean when we say “high velocity?” Velocity is commonly used to define the number of points completed, or effort expended, within a team in a certain interval, usually called a sprint. For better or worse, different teams come up with different ways to define these points and measure them. However, the most popular way tends to be folks on the product side come up with work that is framed out with clear criteria, and then devs as a group “size” this work with how much effort they think it will take with a number we call story points. So the work is planned, developers measure how much work they think it will be with a number (story points), and the sum of the number of points in the work they complete in an interval is their velocity.
In the simplest terms: velocity is how much work developers think they got done based on estimates in the past. And we always want output to be “high,” right? A “high velocity” has to be a good thing, right?
Right?
“Tell me how you measure me, and I will tell you how I will behave”
Eli Goldratt
That depends. Does this mean high compared to two weeks ago? High compared to the other teams in your organization? How do we even measure velocity accurately without it becoming just another metric that is gamed? I have often talked at length about my love/hate relationship with velocity and focusing on developer enablement, and my opinion has largely been unchanged for about a decade. The obsession with this (relatively) arbitrary number skews the value we are creating when it becomes your only goal:
- Trying to compare the velocity of multiple teams to see which is better? Different products, dynamics, skill sets, external and internal factors, etc. all play a part, and it is impossible to accurately compare.
- Trying to show improvements to single team performance by rising velocity only? Then you are only making the pressure higher and higher for people to compete against who they were two weeks ago. The motivation to alternate between sandbagging and crunch mode just rises.
- And in almost any scenario, any metric that is in the hands of those you are measuring through sizing and grooming will just be tweaked to match whatever you are positively reinforcing; there is no reason not to make something that was 2 points now 3 points, then 4 points, etc just to make the number look better. After all, higher velocity is better.
Without fail when velocity alone becomes the goal, you hear two things mentioned less and less: quality and morale. These two things don’t get measured accurately because it’s hard and it’s not convenient with our new, unhealthy laser focus on numbers. When velocity becomes the only goal, looking at quality as a measure begins to feel like judging a runner after they have finished the race.
Then the hedging and compromising start. Folks will begin to rationalize the long tiresome hours to justify the numbers getting bigger on a spreadsheet. Then, as we alluded to in the beginning, the inevitable burnout starts. All team members, not just developers, begin to realize they aren’t making good decisions; they are going down the wrong path but this arbitrary velocity number is the one defining what is right or wrong.
“What gets measured gets managed — even when it’s pointless to measure and manage it, and even if it harms the purpose of the organization to do so”
Peter Drucker
After a while, when we are no longer able to ignore it, we have to have the talk about all of these missed deliveries, rising bugs, and low morale on the team. Many will talk about buying tools, changing platforms, or having an ice cream party to raise morale. But the one thing no one dare bring up: Maybe we need to change directions? Or even more sacrilegious: Maybe we have been measuring this wrong all along?
For a lot of folks, this will get head nodding; plenty of folks have been, or are still struggling, in places with that mindset. Other folks who haven’t had to put up with this, it sounds like a nightmare and almost fantastical in its silliness and backwards thinking. But it is real and worth acknowledging that when leaders talk about being “high velocity,” there is baggage that comes with it. I have no doubt the commenters on that webinar alluding to burnout have been victims of this reductionist mindset. This is why I have done away with the “high velocity” moniker for a team and stuck with something that is more broad, but also far more accurate to what we want to have: “well performing.”
What do you mean, “well performing?”
I know what you are thinking; it’s the same thing my co-workers said when I told them this was my new preferred term: “You are saying the same thing, but with different words. Your misdirection won’t work!”
Sleight of hand attempts aside, I am not saying the same thing. I am looking at a team in a whole different manner without using a single number to measure team performance and health. Here are the factors I look for in a well performing team, and the signs that can let me know the team needs attention or if they are healthy.
Look at velocity, but not how you think.
The weirdest way for me to share advice on how not to let velocity run your team’s life is to start by talking about velocity, but my point is about how people use it as a tool incorrectly. High or low velocity doesn’t mean success or failure, it’s an indicator. If a team has had sharply rising velocity for the past three sprints, the last thing you should do is sit back and think “Well, the team is doing its job and my work here is done.” You just had data point to something going very right on your team and you need to find out why, this is when the real work as a leader starts.
Have folks been pairing or divvying up stories in a way that works better for them? Are they showing a certain affinity for types or stories or a phase of the project they are in? Were we more accurately estimating stories? Perhaps it was a false positive, they were just severely underestimating stories, or any number of variables to explore.
This goes for lower velocity as well: you have to find out why. It could be people are out sick, some stories were very unclear, or something more severe like a loss of team vision or morale dropping. Find out if there is something you should recreate and sustain (or even better, spread to other teams), or identify and mitigate, and then observe. Those data points are telling you something, so you should listen. Just remember it isn’t telling you success or failure.
Clearly set expectations, and the team delivers on them.
A lot of folks like to use the term “predictable,” but that can be a bit vague and mean a lot of different things. It also has the connotation of timelines and dates, which are affected by so many variables outside of a dev team; you should never give someone responsibility for something they do not have control over.
I prefer the term “expectations” over predictable because expectations can change, shift, or be completely reset and the team can still be completely healthy as long as it is clear why it is happening. Sometimes teams can’t be predictable because they are in an unpredictable industry or org, but expectations can still be clear.
A large company I worked for was obsessed with predictability as a measure of team success. The team would make estimates on work that would come their way, and if they did not deliver on that timeline consistently, the team was failing. So naturally the teams added a lot of buffer because being “on time” was what we were reinforcing, not quality, agility, or anything else that would deliver more value. Then the pendulum swung the other way, teams were criticized for taking too long for projects, but still expected to make an estimate and honor it as a promised commitment. Morale shrunk, defensiveness rose, and making sure it was someone else’s fault became an essential job skill.
On the other hand, how I manage teams here at Stack Overflow is around expectations. When we research work to do, we know that we do not know everything. We create an environment where that is okay as long as we communicate around it and acknowledge where things are fuzzy or unclear to avoid surprises for our stakeholders. It also sets reprioritization as a healthy thing. If we are working on something with clear expectations, but then something else pops up that is high priority, resetting expectations is fine. Working on two things in parallel or putting something else on the backburner is okay and a choice everyone can make together. We expect the team to identify the impact, share pros and cons, and let our stakeholders make the decision they think best. Timelines will change, but the team is still delivering on what they said they could; even though some would call that “unpredictable.”
Team morale is high, and they are relying on one another.
As far as I know, since the inception of development (and putting those developers on teams together) folks have never worked better when they are stressed, unsure, or distracted. This sounds obvious to some and perhaps too sensitive to others, but a high team morale pays dividends in every other area that they operate. This is where checking in with team members and asking how they are doing is something that should be normalized. You should also create a safe place for them to say they are not okay. If they are stressed from work or personal life, they will not do their best work, and it becomes your responsibility as a leader to mitigate it best you can. The last thing you want is for folks to be miserable and take it out on their teammates; this is how morale vampires are created.
The best way you can make this an honest and fruitful conversation is by leading by example. Though I tend to be an upbeat person, there are days where I am not doing well and I share it with folks. This opens the door for reciprocation, not just with you but with the whole team. A lot of folks have found having health checks with the whole team to kick off team meetings to show a shared investment in folks’ wellbeing (though I personally have had mixed success with it). From there, we see foks stuck on work tasks asking for help without reservation and other folks eager to help. We share celebrations of our successes as well as responsibility for our problems.
“It is wrong to suppose that if you can’t measure it, you can’t manage it.”
W. Edwards Deming
We see the difference in these approaches, but while one is extremely costly, I won’t pretend the other is perfect. There has never been a convincing argument for defining a team by velocity only other than to put teams and people in convenient boxes so managers have the illusion of control and influence in more familiar ways.
But there is still a struggle in managing a team with the factors I laid out: a lot of it is subjective. There is no numerical value for morale, there are ways to exploit or game expectation setting the same as timelines, and other ways are not as convenient as the black and white of a velocity number.
And that’s why leadership is hard. The organization you work for and the people you manage are trusting you to do what’s best for them both, and a lot of it will come down to how well you can understand a problem and give folks clear direction on how it will be solved. There is no universal playbook for this, and folks that try to pretend like there is end up with people complaining about how folks use velocity to burn people out.
Tags: burnout, metrics, velocity
5 Comments
I agree, it’s a big debate among teams vs managers or vice versa. The trick is not so much in exerting control because we all know the weight of illusion present in the matter, it’s more on a level of relationships. Letting your team know you love them and their work and showing them your willingness to fight the battle with them. I completely get the one day your on fire the next not so much, that’s just human chemistry which I believe can be evolved through our relationships with the team. Placing an environment where they feel wanted and not just needed, delegating certain tasks to various ones perse in an area they are known to strive that away they not only see success but they also feel like they’re important. The relationship building as well as spending extra hours studying their work and see who does what in what time manner will allow insight into who likes and excels at challenges, who likes just being left to one aspect because they always shine in that area and it makes them feel good. I believe that just like coding is an experimental puzzle that has to be constantly readjusted, so do teams until you figure out more about them in action. Create a “project”, not a real one to their knowledge but one for you to make discoveries about your teams talents. Sitting down and asking teams personal questions can only give ideas because people always over-under estimate their qualifications. I don’t know, maybe I’m off subject or didn’t get the post but it’s now long and typed out so it’s now being posted.
In my team we try to balance quality with velocity. A bad sprint would be one with many quality issues regardless of the velocity. Also, when it comes to velocity, we also value consistency more. For a new team the initial sprints will be a bit all over the place as you figure out the estimates etc., but in time you settle (as a team) on these issues and at that point I expect to see a more-or-less consistent velocity – regardless of what the actual number is.
Each team is unique and properly self organizing teams may have vastly different velocity scores even if you find the actual output of each individual team to be more or less the same (measured against all other metrics like lines-of-code, bugs etc.). You should never compare one teams velocity against another – any correlations is purely accidental IMHO.
I agree that team morale is highly important. In fact, I think it is one of the cornerstones of producing consistent quality output.
I just did a browser search in this article for the terms “customer” “end user” “user” and “lowering cost” and came up with zero hits. Not a single mention of the only things that are objectively valuable. If you want to know if a team is performing well, you only need to measure those types of things. Is the team directly creating value for their end users or indirectly creating value by reducing the cost of running the platform/tool/software. I have seen so many teams give themselves credit for “velocity” of things that don’t do that. You *CAN* measure these things, you need to have an arbiter decide the value component of a given change, and the other thing that is almost always missing with respect to “velocity” is time to market. How long was a priority item sitting in the backlog before getting on the sprint plan? Why does that matter? because as long as your product manager has a brain, that’s the only other thing your customers care about – how long until I get the thing I want. Solid leadership knows all of these dynamics and how to create hard and soft metrics and visibility that ultimately drive the behavior needed. I used to work with Liberty, and I know Justin, and I know their leadership understands all of these dynamics.
That is certainly one important side to see how well the team is performing but it should be combined with the team’s morale. If you delivered value but it came of at the cost of stressing out the team, do you really have a well performing team? is that something sustainable? It’s something hard to measure as the post mentiones but it has to be taken into account.
This depends heavily on the nature of the product and the goal of the team. If the team is doing foundational work, the end user might not see the results of that work for some time. Similarly, if the teams’ job is maintenance and upkeep, those are things that manage risk, not cost, and aren’t immediately visible. As mentioned, team health / morale is yet another point that this wouldn’t cover, and that affects long-term viability and employee churn.
Long story short, the idea of this article (that you have to look holistically and not be beholden to a single metric, of *any* sort) makes a lot of sense to me.