First, let me make myself clear. This post isn’t focusing on voluntary overtime (though you should still consider the impact to your team, but that’s another post), it’s focusing on forced overtime in order to meet some deadline. I consider this to be one of the worst kinds of failure.
Teams forced into this situation are typically faced with the worst of all possible choices. Do we take shortcuts to get out on time and risk the quality issues that can come from that, or work long days and weekends, not have a life, and still likely introduce problems due to burnout?
It’s failure if you have to even ask this question, but let’s look at the choices anyway.
Keep Working 8 Hours
Hopefully this is the direction your management is leaning, but it comes with a cost. In order to continue working at the same pace you must sacrifice scope or let the schedule slip. Yes, personnel can change too, but I’m assuming that by the point you realize you need to make this decision that adding new people won’t get you to the finish line any faster
. Everyone must either accept the delay with the understanding that this is what is necessary to achieve the expected level of scope and quality, or strip out a few unfinished/untested features and move them to the next release (yes they should move to the top of your backlog). This will let you release a working product of known quality without cutting corners.
Burn the Midnight Oil
Some people might not think this is so bad. I think it’s one of the worst things you can do to your team. What message are you sending when you’re forced into this situation? To management? To your team? By deciding to work long hours, weekends, or even burning the midnight oil to put out the occasional fire (many of which were a direct result of those long hours and weekends) you’re sending the message to everyone involved that this is the new normal.
This sets a precedent and creates the expectation that all future situations like this will be addressed the same way. Then the first time it doesn’t go this way (because you tried to do it the right way) you’ll catch flak about why your team is no longer dedicated to their job. Do you really want to knowingly commit to 7-10s every few months? Think of the children.
After you’ve made it across the finish line, you absolutely must evaluate how you got there. How did you get into that situation to begin with? Did the team commit to too much? Did certain features take longer to implement or test than the team estimated? Did the team not consider testing costs? Were there a lot of unknown unknowns that crept in? Maybe some other part of the process caused the schedule to drag? You need to answer these questions in order to avoid this type of situation in the future.
Don’t Go There
This is one of those cases where the best answer is to avoid asking the question in the first place. Pull things that would normally be done at the end of a project earlier into the schedule. Build your installer or deployment pipeline after the first couple weeks, produce system-level tests for each new feature you add (and make sure they pass before moving on!), do code reviews on a per-feature basis rather than monumental reviews at the end, etc. The more frequently we do these things the better we get at them and it also has the welcome side effect of enabling us to be releasing almost all the time.
Remember, no matter what anyone tries to force you to do Quality Is Not An Option
. Be a professional and stand your ground. This is a tough spot to be in, but burning your team out or torching the codebase with sketchy implementations will do more harm than good in the long run.
Comments are open. I’m sure everyone has their own stories or advice to lend to this situation. Let’s hear it!