Agile antipattern: Working overtime

Ever feel like the guy over there to the left?  Yeah, me too.  Sorry to offend some people with my language, but working overtime really sucks.  I always felt it meant someone else’s bad planning meant I had to have a lousy day, night, weekend (maybe all 3 at once!).  For agile teams, working overtime is bad in so many ways it is hard to count them all.  This post isn’t meant to give ammunition for someone in the middle of a death march.  Once you are in a death march the organization has two choices: a) keep up the death march and pay whatever penalties come up aftward, or b) recognize the penalties may be larger than the benefit and change the objective to be reasonable.  For people on a death march, I’m sorry you are where you are right now, but this blog post won’t really help you.  This blog post is meant to help people on agile teams where overtime is starting to become more prevalent.  Those people need help – FAST!

I’m going to try to conserve some words and just lay out 5 of the biggest reasons why agile teams should not work overtime:

1. Overtime is not a sustainable condition.  The amount of time people spend at work is at all-time highs just based on regular work hours.  Increasing the number of working hours will cause disruption outside of work which will in turn disrupt work.  When this occurs people are present longer, but they aren’t working more.
2. Overtime does not increase productivity as much as it increases cost.  Many studies, in different industries, have shown overtime hours to be far less productive than normal working hours.  In fact, some studies show that after 9 hours of work productivity actually goes backwards due to a higher number of defects being introduced!
3. Working overtime causes severe morale problems.  I don’t think my feelings in the opening paragraph are any different than what most team members feel when they have to work overtime.  A friend of mine uses the phrase “your incompetent planning doesn’t change my capacity!”  Is there any greater detriment to morale than feeling you are working for people who can’t do their job?
4. Even when working overtime gets the job done it perverts the process enough to cause problems.  If a team has a velocity of 20 and then works a lot of overtime to get 25 points done what should they commit to for the next iteration?  Most teams say 25 and cause themselves to start getting into the overtime habit.  Other teams pick 20 and end up missing because they are worn out from the overtime effort.  By the way, the team trying to hit 25 while likely miss as well.
5. Is getting in the very last feature really worth it?  This goes back to the title of this blog post – remember we are talking about an AGILE team!  So they are working on things in priority order.  Is it really necessary to get the very last feature completed at the expense of killing the team?

In my opinion working overtime should only be done when the team feels it is necessary to meet a commitment THEY made (not commitments made by others and imposed on them) and are in danger of missing because they made other bad decisions along the way.  In this case I’m ok with people wanting to feel good about themselves by making up for their own mistakes.  In fact, I like that in teams.  It shows they have some pride in their work and they want to continue to be successful.  I can’t come up with another reason for overtime which makes sense to me when I really analyze it.  (I consider the “we’ll go out of business if we don’t work overtime” argument to be  red herring – some businesses should not succeed if they do it by treating everyone like dirt.)

Until next time I’ll be helping teams avoid overtime by making sure they understand planning at all levels of agile in order to make commitments which can be met without working overtime.  Doing this will ensure that long term they will be Making Agile a Reality^®.