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.