Having people doing nothing productive
There is a project, but there are workers who have nothing productive to do
Slack resources, people who have nothing productive to do, tends to be a symptom of phasist or waterfall development. This mind-set has each skill-set, each role, coming into play at a particular phase in the development cycle. If it isn’t their phase, they will have nothing to do. Yet there can be development work, cutting code, in all phases of the life cycle. During inception there are proofs of concept and candidate architectures; investigative work. During elaboration the architecture will be built and proved, etc. Of course, the amount of work for each skill set will vary in the different phases of a project. Other causes of slackness occur when the work is blocked waiting for resources or information. We could claim that all causes are similar; the developer is waiting for requirements, etc.
The classic way to deal with workers that are waiting for things to do is to release the resources that are holding them up, as described in InterruptsUnjamBlocking. However, where the ‘upstream workers’ are already flat out producing these resources, perhaps progress may be made with what is already available. If we already have part of the picture we require, maybe we don’t need to wait for the whole picture, we could JustDoIt. Sometimes, the act of producing something will itself unblock resources by producing feedback; this approach can be used when we BuildPrototypes, and it can become a way of life in EarlyAndRegularDelivery.
Modern Agile approaches often have GeneralizingSpecialists; they can put their hand to quite a wide range of work and would rarely be short of ways to make progress. The most agile of development methods will iterate through analysis, design and coding in very short cycles, taking very small chunks at a time. The cycle time may be only minutes in duration and result in only two or three lines of code. With the CustomerOnSite to supply, prioritise and clarify requirements, waiting time should never be long.