Overtime is the first refuge of bad management. When teams get behind—as they often do, even with agile—managers search their bag of tricks for a solution.
All too often, the solution they pick is the solution that was used on them before they became managers: Overtime. The problem is, overtime didn’t work then, and it won’t work now.
Four Things to Try When Teams Fall Behind
When a team falls behind schedule, there are many things besides overtime that a manager could try. They could:
- Add people to the team.
- Drop a few requirements.
- Relax a few requirements; that is, not drop them but do a simpler version of some.
- Extend the deadline.
Why Managers Turn to Overtime So Often
With all these things to try, why do managers so often reach for overtime as the solution? Because it seems so easy—buy team members some pizza and Red Bull, sit back and watch the problem evaporate.
Other solutions are harder to enact. You normally can’t add people as quickly as you can buy a pizza. Dropping requirements takes stakeholder participation. By the time these stakeholders arrive at a consensus, the project is either further behind, out of time, or both.
By contrast, asking—or worse, telling—a team to work overtime is easy. And it sometimes works…for a short while.
XP, Kent Beck, and Sustainable Pace
What is a sustainable pace? Kent Beck, inventor of the Extreme Programming agile methodology, called it a "40 hour week." The concept of sustainable pace has come to mean a pace a development team can maintain indefinitely. Teams can keep moving, without needing to pause between iterations of work to rest.
When teams can maintain a constant pace they don't need to pause to rest or take time to slowly wind up at the beginning of the next sprint. Theoretically, they can maintain a constant pace indefinitely.
Kent has a great approach to overtime. He says,
"Overtime is a symptom of a serious problem on the project.The XP rule is simple—you can’t work a second week of overtime. For one week, fine, crank and put in some extra hours.
If you come in on Monday and say “To meet our goals, we’ll have to work late again,” then you already have a problem that can’t be solved by working more hours."
Why Some Overtime Works, For Awhile
One of my clients had to learn the overtime lesson the hard way. With a major deadline four weeks away, the CTO mandated overtime from everyone on the project. And for the first week, it worked. Velocity across all teams was up 22% over the average.
With results like that, he kept the mandatory overtime going. The second week didn’t go as well. But velocity across all teams on the project was still up 2%. That’s better than it would have been without overtime, but not by much.
People were starting to burn out. And in weeks 3 and 4, velocity was down–16 and 20% below the average without overtime. During this 4-week period, the teams actually delivered less with overtime than they would have if they’d worked at a consistent, sustainable pace.
Even better would have been just one week of overtime to get that little extra surge of progress without burning people out.
There’s nothing wrong with an occasional week-long surge of overtime when truly necessary.
In fact, a friend of mine claims that periods like that have been his favorite over his 30+ years in the software industry. He loves the team camaraderie and the trust that gets built when everyone comes together to achieve something. I've experienced the same phenomenon.
The problem is when overtime becomes the first tool managers reach for, and they see it as the solution to every problem.
The truth about defects & sustainable pace
Working beyond a sustainable pace leads to stress, which leads to mistakes.
This chart shows a comparison of four successive projects at the same company. Each project was adding functionality to the same product, so the complexity is reasonably consistent across all four projects.
The red bars show the number of hours each project was estimated to take. The blue bars show the number of hours of overtime worked on each project.
Projects 1, 2, and 4 had significant overtime—ranging from 22% on Project 1 to 40% on Project 2.
The yellow dots indicate how many defects were found in each project.
Look at the number of defects in the projects with overtime and compare those to the number of defects in Project 3, which had no overtime.
Overtime, stress, defects—it’s a predictable cycle many of us have seen time and time again.
Sprints are not races
An agile team seeks to break this cycle by working at a sustainable pace.
This is where Scrum’s term, sprint, gets in the way. It sounds like we’re supposed to be burned out after a sprint. We’re not.
A bonus of working at a sustainable pace is that a team can choose to surge with up to a week of overtime if they want. It can help, and sometimes there are reasons for it—your investors need a demo next week that will determine if they invest more money in the company, or the company will be fined if not in compliance with a new law ASAP.
Let’s return overtime to its rightful place as a rarely used but viable option for a week or so.
