We talk about how using Agile practices help us deliver business value faster because they let us focus on doing the right things faster as well as doing things like incremental releases.

Unfortunately, there’s a dark side that often comes along with this (and, in some organizations, ends up being the driving force instead of a bad side effect) – an obsession over velocity. Velocity, for those who aren’t familiar, is the number of points/cards/features/etc that a team ships over the span of a single sprint.

A lot of managers will obsess over this number and either expect it to go up constantly or to remain steady no matter what. I’ve literally seen managers who have dragged entire teams into meetings that were focused around “wanting to get to the bottom of” why the team’s velocity dropped from one sprint to the next.

Part of this obsession comes from the fact that velocity is a number that they can point to in order to prove that they are working or pushing their teams to do ever increasing amounts of work (please don’t do this. It’s unhealthy). Your manager usually has a quarterly or year end review just like you do and they want to be able to point to something concrete.

A lot of managers work on the maxim that you need to be able to measure basically everything for it to be of any value. In fact, many of them will use a quote that they attribute to W. Edwards Deming – “if you can’t measure it, you can’t manage it.”

The problem is that that isn’t the quote. The actual quote is “It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth.”

That’s… a little different from what so many managers repeat – which they have usually gotten from someone else in a game of managerial buzzword telephone.

Now, that’s not to say that measuring things which can be measured is useless. It can be incredibly useful if you do it for the right reasons – and being aware of a team’s velocity is no different. Done right, it can provide valuable feedback and help guide your practices as a team or even an organization.

We’ll get to the right reasons to look at velocity in a second, but first I want to make a statement that a lot of people who offer agile coaching services (and certainly a lot of managers) will vocally disagree with me on.

Velocity, as a metric, will tell you almost nothing useful in the moment. It is, at best, a far trailing indicator. You can’t walk in on Tuesday morning and say “Yup. They’ve shipped 3 points worth of software. They’re on track.” You can’t really even do that at the end of the sprint.

Velocity is really only valuable in the aggregate. A single velocity reading isn’t really worth anything.

That gets us to what the right reason to look at velocity is – detecting significant swings in velocity can give us a little insight into the health and flow of a team.

By significant, I don’t mean a few points. If your team varies a few percent from sprint to sprint, that’s pretty normal. What we’re looking for here are fairly large swings, and we want to find them in both directions – upward and downward.

A significant increase in velocity can indicate a number of things including:

• Your team is starting to gel
• Your team is getting a handle on a new process that they’ve been learning (TDD for example)
• Your team is really starting to get their heads around the problem domain
• Your team (both business and technical) are having better conversations about the value that’s really needed so are doing less rework

On the downside, it can also mean that they really over-estimated the complexity of the stories that they were working on (possibly to impress management by “shipping lots of points”).

A significant decrease in velocity can, among other things, suggest:

• Your team has underestimated the complexity of the things they’ve been working on (a lot of teams do this sometimes)
• Your team has encountered some issue that has caused work to stop or slow down temporarily like a production or infrastructure outage
• Your team has needed to rework more things than normal or has discovered defects that needed to be fixed
• Your team has needed to spend time to modernize a section of a legacy codebase that wasn’t previously under test
• Your team’s morale has taken a hit for some reason

Of course, it could also be that someone went on vacation, someone left the team, or you got new people on the team and time was spent getting them up to speed.

So what do you do with this information?

When you’ve found out what caused the swings in velocity and ruled out the noise of things like “Rachel went on vacation” or “We accidentally over/under-estimated a series of stories”, you look at a couple of things:

• What caused us to speed up (higher velocity)
• What caused us to slow down (lower velocity)

As a general rule, you want to do more of the things that speed you up and find ways to mitigate the things that slow you down.

Seriously. That’s it. That’s the best use of velocity – to be alerted when things change significantly so you can figure out what changed and how best to deal with it.

So stop beating your teams up if their velocity drops a little. Instead, figure out why it happened and what you can do as a group to fix it. And, for the love of all that’s decent, stop using it as an achievement in your year end reviews because, in that sense, it’s worthless. Focus on business value instead – after all, that’s what helps keep the lights on.

You often hear people talking about how “fast” agile lets you work. It’s something touted by a lot of “Agile Consultants” and is eaten up by people in upper management.

I even had one team lead on a project I was on brag about “how much you get done” and literally how exhausted you were at the end of the day as though that was a good thing. He also said that they used pairing as a way of “keeping you honest” because you couldn’t stop during the day. Sadly, I’m not exaggerating. Between that and other behaviors, he’s made the List of people I will not willingly work with again (it’s a really short List considering how long I’ve been doing this).

If this is the mindset you have about agile – especially if you are in a position of authority in your company, it’s time for a little reeducation.

Agile isn’t about “going fast.” It’s about going at a sustainable pace over the long term. Yes, I realize that terms like “sprint” indicate that you’ll be running at top speed all of the time, but those were incredibly poorly chosen marketing words.

Software development (indeed the creation of any reasonably complex system) is more like a marathon. It’s not something that can be done in short order, and we need to view it through that lens. If you try to go at top speed for an extended period of time, the only thing you will accomplish is wearing yourself out without having achieved your objective.

And that’s the best-case scenario. In the worst case, you will injure yourself to the point that you’ll be unable to do anything else at all.

For an organization, the consequences of trying to work at a fast, unsustainable pace are usually a combination of having the things you do ship being full of defects, people not being motivated to do anything at all after a while, people taking a lot of sick days just to be able to rest, and eventually people leaving your company in large numbers.

With all of that institutional knowledge walking out the door, you’re not going to be able to maintain the things that you did manage to ship. To add a further bonus, you won’t be able to hire the people that you want because none of them will be willing to work with you. The whisper network is real and we all talk to each other.

For an individual, the consequences can be even more severe (as is usually the case). They include burnout (at best), a now permanent medical condition like hypertension, diabetes, etc or (in the worst cases) ending up in the hospital because you’ve had a heart attack.

I’m not exaggerating about any of these. I’ve seen otherwise healthy people (self included) suffer long term medical issues from overwork. The heart attack scenario isn’t an exaggeration either – I can think of at least one coworker who suffered that fate. To make matters worse, one of their executives visited him in the hospital and had the gall to ask why he wasn’t studying software related material instead of following his doctor’s orders to do nothing but relax.

I know it sounds like a sick joke, and I wish it were, but this is the reality of things that I’ve seen. I hope it goes without saying that the exec in question is also on my List.

I told you it was a high bar to become a member of that club. Most of the people on it are there because they abused the people around them.

All of that said, I hope we can agree that none of these outcomes are things we actually want either as companies trying to get work done or people trying to live a meaningful life. So what’s the answer to help prevent all of this?

Stop thinking about going full speed all of the time and work at a sustainable pace instead.

The first step to doing this is to realize that the definition of “sustainable” can change day to day – someone may be on vacation, someone may have a bad day or feel out of sorts, your team may be encountering outside problems (AWS going down or a package disappearing from NPM would be relatable examples lately), or the people on your team may be absolutely killing it that day and getting an amazing amount done. All of these things will affect what is “sustainable” for that day.

Think of the long-term instead of day-to-day or “sprint” level. Stop obsessing over having a “stable velocity” (or, even worse, obsessing about it always going up). As long as there aren’t wild swings in your velocity, you’re probably fine.

Stop encouraging (or worse, enforcing) overtime. Realize that working extra hours is a signal that something is broken. Sure, it happens sometimes, but those times should be incredibly rare and you should fix what caused it afterward.

If you do end up having your people work overtime because of an emergency, make sure they get time off to compensate them for that to allow them to rest. In fact, if it was more than a couple of hours, I’d advocate giving them more time off than they spent on OT in order to recover. The reason for this is because it always takes you longer to recover from something like a lack of sleep or extreme stress than it took to get you into that situation.

Encourage your people to spend time thinking about the problem they’re solving instead of obsessing that their hands always be on the keyboard. Obsessing about how much a software developer is typing is about as useful as obsessing about how much a doctor is actively cutting open a patient. The same goes for encouraging your people to spend some time every day/week to do professional development during work hours (and for the same reason).

Make sure your people actually take time off when they need it. Make sure they take a vacation every year. Make sure they stay home and rest when they’re sick. Don’t make them feel like they are going to earn points for working themselves into the ground. And if they are taking time off, anyone who contacts them about work better have an apocalyptically important reason for doing so.

My favorite boss as of writing this used to make me take a 3 day weekend every month because of the level of work I was doing on the project (to say that I was punching above the weight class I was hired for was an understatement and he realized that). Personally, I have sent people home on my team who came into work sick despite their protests that they could still work.

All of these things let your people work at a pace that can be sustained. They leave work feeling like they got something done. They take time off when they need it. They come into the office feeling refreshed. They may even look forward to starting work in the morning (what a concept, right?).

Maybe they’ll even tell the people they know about how amazing it is to work with you as a company and you’ll have your pick of potential employees. It’s one heck of a way to build a pipeline, and it’s even cheaper in the long run than running your people into the ground and replacing them when they quit.

Treat people well and fairly, make sure they get the rest they need, and watch your teams get work done that is not only amazing but is more likely to solve your actual business problems.

Most of us in this field want to do a good job (the same is true of most people in whatever profession). It’s the things that employers and managers do to “make us go faster” or “keep us honest” that end up slowing us down or make us leave.