SlowDevelopment

Time to completion is too great and needs to be reduced

Description

The expected time to completion is too great and needs to be reduced.

Discussion

There are various ways of estimating completion time. All give comparatively poor estimates early in the project and comparatively good ones later, as the team settles in and the unknown factors about the project are clarified. If the prospective completion date is too late, there are many approaches that may be taken. Unfortunately, of these, many are disruptive and their initial effect is to slow down progress even further. One approach is to adjust the scope and take some work out of scope; this is addressed in BadFitToSchedule. Where the scope cannot be adjusted, there are a few approaches that may increase productivity. If the problem is discovered soon enough, growing the team may increase speed; see GrowingPains for advice in this respect. Where development is slow owing to people being idle, see SlackResources.

Prevention, Amelioration, Cure

Traditional

There are ways where speed may be increased by reorganization if the organization is not optimum, yet as always this will be disruptive and will initially slow things down. At the start of a project SizeTheOrganization, and grow it accordingly thereafter. Have FewRoles and optimise the communication by applying CouplingDecreasesLatency. When work is partitioned between teams, define LooseInterfaces for communication between the components, allowing a greater independence between teams. Allow the experts on the team to work at maximum efficiency where they need to support others with their expertise by having a DayCare system.

Modern

Modern Agile approaches tend to establish a ‘velocity’ early in the project, and use this for estimating the effort needed to complete the WorkQueue (see the PlanningGame). The high degree of internal communications needed by a team restricts the size of a team, though there are ways of bringing multiple teams to work on a project. Having a lower percentage of high quality people usually results in slower development rather than poorer quality product. In effect, this means that problems with time to completion are likely to be detected earlier, but there may be fewer ways to address the problem. In theory, DevelopingInPairs should bring newcomers up to speed faster. However, the team cannot afford to grow too much or internal communications become too costly. Growing a team then splitting into two teams may be a way forward, bearing in mind there will need to be extra overheads to keep the teams working toward the same ends.