Working Overtime is a Killer of 24 Hours Based Agile

To be successful in any project we have to look at it as a whole, especially from the system point of view. According to the definition " A system consists of interdependent and interacting parts joined by a purpose. A system is not just the sum of its parts-it is the product of their interactions ."

It is very important for every project leader to try to move one step back when looking at the project, when trying to analyze and to solve its problems. I have found a beautiful way of modeling of those interactions together with the set of fantastic patterns (structures) of common problems named Systems Thinking.

I was able to observe a lot of Systems Thinking's patterns in my current project. A good example could be the well-known problem of keeping project in schedule. Even if in my current project we are extensively using agile, our project managers' first reaction to this problem was to extend the working time. What a bullshit. I'm not generally against longer working time but that should be used in case of an exception, not as a rule.

Nevertheless our project managers did it and this short term decision had (counterintuitive) a very negative influence on the project. Let me explain this using the Systems Thinking, and one of its patterns called "Fixes that fail" using Causal Loop Diagram (CLD):

As you can see due to the schedule gap we have run an action working overtime. In the short term it causes that our current estimated schedule had decreased thus reducing the schedule gap. That was exactly that, what the project managers expected and wanted to achieve. But what they have overseen is the second loop which shows that the action working overtime causes the fatigue of the developers, which causes less quality of the code being developed, thus the increase of the number of an open issues, thus increase of the current estimated schedule and finally the schedule gap. It was simply a "shot own leg" solution.

Secondly in a 24 development project as I have, this decision has killed the project rhythm based on so called Home-Handover-Development-Handover-Home (shortly 2HD) flow, which is very important for the time-boxed agile development approach, we have chosen (based on Scrum). Before extending the working time all developers were happy, because they have noticed that time-boxed development (8 hrs. per day) had the advantage of getting task faster done, due to the implicit pressure of the upcoming daily handover. They had simply no possibility to work longer on the task because it has been transferred to the other team, which had a very positive influence on the productivity and effectiveness. As you can see it was the second shot in the own legs.

The right solution to this problem is not to extend the working time, but to reduce the scope. The flexibility in changing scope is one of keys to the successful development projects. Based on many studies we can assume that over 50% of functionality of any software is not used or is used rarely, thus it builds a perfect candidate for reducing scope. I always admit that the flexible scope based on prioritized user stories should be a part of every software development contract (but it is a story for other discussion, I will discuss this in one of my next posts).

So, working overtime is the killer. Simply avoid it.

It is almost always cheaper to build less, but build it stable, rather than to build lots of stuff and then have to do panic hot-fixes (by Henrik Kniberg)

---