Don’t rely on overtime to salvage a plan
I came across a nice analogy today in Mike Cohn’s Succeeding with Agile book which describes what sustainable pace means:
Watch any marathon, and each runner will keep it up for 26.2 miles. Look more closely, however, and you’ll notice that the pace is not entirely consistent from mile to mile. Each works a little harder going up the hill and maybe recovers slightly coming down it. At the finish line, most accelerate and sprint at a pace that is not sustainable beyond the finish line.
Sustainable pace should mean the same to a Scrum team: Most of the time the team runs at a nice, even pace, but every now and then team members need to kick it up a gear, such as when nearing a finish line or perhaps attacking a critical, user-reported defect.
Working overtime occasionally does not violate the goal of working at a sustainable pace. Some overtime is justified. Do overtime only when we are in critical situation but do not to make it daily or frequent practice as it affects efficiency, productivity, morale and quality. Consistent and extended overtime is a symptom of a serious problem on the project. It is even more serious when overtime is scheduled into a plan.
Teams cannot be pushed infinitely hard and beyond a certain point, working more hours in a week will move the team backward rather than forward.
Don’t automatically assume overtime equates to actual progress or delivery of value. Often overtime just means that people are present longer, but they aren’t working more. Many studies, in different industries, have shown overtime hours to be far less productive than normal working hours.
When overtime is consistently required, we need to address the cause not just the symptoms. It is a learning opportunity of our capability to schedule and rethink how we reschedule. What is it about our scheduling approach that produced an incorrect plan? Agile is about inspecting and adapting our approach and learning as we go along.
Pingback: The Mythical Man-Month Is Not A Myth | Chris Chan's Blog – C2refleXions
Pingback: The Improvement Paradox – Too Busy To Improve? | HI, I'M CHRIS CHAN