
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.