It has long been a tradition in waterfall style projects to associate long hours with increased productivity. A recurring pattern is up-front planning, followed by realisation that a deadline is not going to be achieved and then finally a push to increase working hours.
This approach is popular because managers often associate long hours with success. Perhaps that correlation is true in many industries and many job roles. But with software development it is very dangerous and potentially counter-productive.
Why is software development so different?
The first thing to remember about software development is that there are an infinite number of approaches to solve any one problem and not all of these approaches will deliver maximum business value. A second consideration is that it is possible for a small mistake to have large consequences.
Let us consider a development team that is currently working 40 hours each per week. If they were to switch to doing 50 hours per week it is likely that their output would increase. But output and business value are not the same thing. To effectively convert output in to business value requires careful thought and a good process. Otherwise additional output may end up not being of value to the customer, or it may end up requiring rework.
Also, with most team members the more tired they become, the more likely they are to make a mistake. As mentioned, converting output in to business value requires careful thought and careful thought is harder when you are tired.
Say the team then increases its hours to 60 hours per week. At this stage it is unlikely that they will be able to maintain the same generation of business value for a sustained period of time. In effect they are borrowing from the future to get a short-term payoff. The real danger with this approach is that the appearance of an initial increase in output can encourage the continuation of the long hours. However, the instance of mistakes will increase and it seems likely that the ability to convert output in to business value will decrease.
Eventually the team will reach a length of working week where their return of business value is actually decreasing. Beyond that point there is often physical and mental impact on the team. Illness can become more frequent, morale can fall dragging down productivity. In the medium-term there may also be a problem with staff retention. Working longer hours can achieve an increase in productivity, but it has limited impact and is not sustainable. It also runs the risk of long-term negative impact on a team.
The agile approach to sustainable pace
The agile concept of sustainable pace recognises these factors and tries to find the sweet-spot of high business value output that can be sustained indefinitely. Instead of focusing on working harder agile teams focus on working smarter. Improvements in productivity by process change are potentially limitless.
A sustainable pace means that team members are often fresh and thoughtful. The nirvana of a pleasant working environment combined with continually improving productivity is a real possibility with this approach.
Tags: developmentTarget Audience: Scrum Master
