The goal of this article, according to the authors, is to help managers understand several key work
design principles that undergird not only agile practices in software but also Toyota Motor Corp.'s
well-known production system. Understanding these underlying work design principles — through
a framework the authors call dynamic work design — enables managers to create work processes in
their own organizations that are both more flexible and more efficient.
Traditionally, an academic theory known as contingency theory has suggested that if work consists
of well-defined tasks (for example, assembling components), then it is best to organize it serially, like a
factory assembly line. Conversely, if work is highly ambiguous and requires ongoing interaction (for
example, designing new products), then it is best organized collaboratively.
The authors argue that this approach to work design is not entirely satisfying for two reasons. First, it
describes an unpalatable trade-off: Work done using a serial factory design isn't very flexible, making it
hard to adapt to changes in external conditions, and work done using the collaborative approach often
isn't very efficient. Second, few types of work perfectly fit the archetype of well-defined or ambiguous work.
The authors instead advocate a dynamic approach to process and organizational design that transcends
the serial versus collaborative work framework by creating mechanisms for moving between the
two basic ways of organizing work at appropriate intervals. By identifying mechanisms to cycle back
and forth between well-defined factory-style tasks and collaborative modes when appropriate, managers
can considerably reduce the trade-off between efficiency and adaptability.
For example, work on Toyota assembly lines is the epitome of the serial, mechanistic work design,
and tasks are precisely specified. But sometimes things go awry. In the Toyota scheme, a worker noticing
such an issue is supposed to pull the Andon cord (or push a button) to stop the production line and
fix the problem, which temporarily changes the work design to a collaborative problem-solving mode.
Once the problem is resolved, the operator returns to the serial work design. The authors argue that
movement between the two work modes is also the key to understanding the success of agile software