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.