The overtime trap
September 13, 2006 Leave a comment
This article about excessive overtime in the IT industry reminded me of a question I was asked about how meet a release date when the project was behind. While there are many things to try, asking the team to work additional overtime was low on my list, and here’s why.
Anyone who has worked in the software industry for any amount of time knows that releases can and often do have highs and lows in terms of work hours. If the team has been cohesively formed, development and QA engineers will most likely work extra as the release date approaches anyway. While a last extra push over a couple of weeks or so might help cleanup a few last details, the effects of doing this for many weeks will often cause the project to be delayed even further. This is because tired and burned out engineers will make more mistakes, which will create more churn and code chaos. In addition, if any team members quit before the release is complete, the project could take a serious setback and potentially fail. So, what can be done? Fortunately/unfortunately, there are three fundamental things.
- Decrease scope. If the project is using an Agile approach, this won’t be an issue because the team will maintain a releasable state for the majority of the project. Some will often mention decreasing the quality, but this is essentially decreasing the scope since releasing a quality product was a requirement in the beginning.
- Adjust resources. Adding people is a favorite suggestion for second and third level managers to make, and it never hurts to reevaluate the team. Unfortunately, software isn’t the same as building a highway, and in some cases, the additional resources can consume time from the key contributors and stretch the release date out even further. There are some interesting variations on this suggestion ranging from adding subject matter experts to help the existing team all the way to adding resources in specific areas, such as testing. With an Agile approach, resources are typically fixed, but if there are multiple Agile teams, some teams may be able to take tasks from another team that has encountered roadblocks. In addition, if the Agile teams have been formed over time as cross-functional teams, it becomes much easier for alternate teams to be able to take on extra tasks with minimal training time.
- Push the release date. If no compromises can be made in either of the first two areas, moving the date will be required. When using an Agile approach, everyone agrees to the three laws of software development, often referred to as the iron triangle, and in this model, additional iterations will added until the desired scope is achieved.