The need to grow the project is not handled in the best way


For projects that are to become large, it is not always the best approach to staff them at their full size from the outset.  However, it is not a good approach to wait until the project is running late then throw loads of people at it.  Adding extra people to a late project makes it later  (Ref 1).  The growth of a project needs to be nurtured carefully.


There are many variables that come into play when considering this problem.  A useful core team size initially is approximately ten people.  The team needs to be small enough to have good intercommunication, face-to-face.  It needs to be large enough to have a good spread of skills (HolisticDiversity) and viewpoints (DiverseGroups).  This gives it a good chance to come up with a good vision and direction that will keep the project on track as the learning is passed on to incoming team members.  The core team will have a high level of expertise, but this level cannot expect to be maintained for all team members, the incoming members will include predominantly ‘Journeymen’ and novices.  All will require knowledge transferred to them, the novices will also require skills transferred to them.  This can be a considerable distraction to the experts of the core team.  If left too late in the project, it can exacerbate any tightness of schedule rather than alleviating it.

Prevention, Amelioration, Cure


All large projects should start off with a core team of approximately the same size.  These people should be experts, and it is their task to start the project off in the right way, without the distraction of training novices.  This approach is described in PhasingItIn.  Once the project is settled in direction, growth at a sustainable rate can start.  Adding a large number of new people can distract all the experts and severely affect progress, a situation dealt with by DayCare.  Further amelioration can be achieved if the mentoring is provided by bought in expertise for skills transfer, using project expertise only for the knowledge transfer.  Where the growth rate can be slower, ApprenticeShip can help.  Used in conjunction with DevelopingInPairs, this can increase productivity within a few weeks; the apprentice’s help can boost the master’s productivity once the efficient ways of working as a pair are learned.


Where people are used to DevelopingInPairs there is some hope to be able to increase project size rapidly with few ill effects.  However, large team sizes are not recommended owing to the difficulty in communicating all knowledge that needs to be held in common.  In general, if there is a need, despite the speed and efficiency of agile processes, for a large number of developers to provide the necessary velocity, then it may be better to split the work into two or more relatively independent projects.  There is little published experience in this respect, and few common opinions.


1. Brooks “The Mythical Man Month”