Modern old way

In 1882, the old way received a blow like no other. Frederick Winslow Taylor was promoted to machine shop foreman and was free to work out a new way to approach getting the workers to produce at greater efficiency. He’s known for the invention of the time-and-motion study, and this approach has introduced a new level of efficiency and productivity to many industries. As a consequence of its success, management has become a more scientific occupation and now impinges on the adaptive nature of skilled workers.

For some tasks, the approach works very well, but even to this day, managers are often ignorant of the principal disparity between physical labourers and mind-workers—the former group primarily works to live and for the community of the effort, while the latter are more strongly driven by mastery, autonomy and purpose.

Later on, Taylor produced a book which includes a comment indicative of his beliefs:

It is only through enforced standardization of methods, enforced adoption of the best implements and working conditions, and enforced cooperation that this faster work can be assured. And the duty of enforcing the adoption of standards and enforcing this cooperation rests with the management alone.

— Frederick Winslow Taylor, The Principles of Scientific Management[Taylor1911], p. 83.

When I read this, I picture someone who does not trust their workers. I believe they think of them as children or cattle. I recognise the tone of someone who believes management, with no experience of working with a new technology, will somehow know how best to use it, and that those same managers will be able to direct their workers without ambiguity.

A hundred years have passed, and these words still echo in the halls of management. Those in charge of organisations still generally believe in command and control. They measure outcomes and use cost accounting, forecasting next year’s chickens based on the eggs in this year’s baskets. However, software development has proven problematic.

Software developers consistently underestimated their work and missed deadlines. Something was wrong, and management didn’t know how to fix those unruly techies. Knowing they needed to get on the IT money train, the heads of production were never going to give up on attempting to wrangle them into good behaviour. Yet none of them would even consider giving up their command-and-control approach to projects. In fact, the worse the experiences of the project manager, the more tightly they turned the screws. They demanded more and more detailed estimates and finer task breakdowns. At least they were extremely efficient at creating a demand for printer ink and paper.

This lack of trust led to even worse behaviour. Demotivated mind-workers are a revolting bunch. Those without autonomy started to feel like cogs in the machine. Those lacking the space to develop their skills began seeking job security through other means. As goals grew more ambiguous, purpose and shared vision fled, destroying any sense of achievement. We spent a hundred years increasing efficiency and a hundred years disintegrating pride.

I find the whole story so sorrowful. The old way generated motivated workers; the kind we want to build projects around in an agile environment. When you enable skilled and motivated people to do their best work, give them clear goals and let them find the best solution, you always get a better solution than if you tell them what to do. Christopher Alexander’s team worked like this, and their clients began to see how motivational it was. When the project is goal-driven—purpose-driven to satisfy a real and present client—it’s propelled by virtuous pride. We’re driven by the pleasure we take in seeing a smile on someone’s face in response to our efforts. We do not seek awe but to satisfy and delight, and this is much healthier than being profit-driven.

Another aspect of the old way is the notion of local people helping where they could and training to support themselves in the future. Christopher Alexander followed this approach in the Mexicali project[TPoH85]. The people who eventually lived in the homes were also part of the labour force.

In Team Topologies[TT19], we see the concepts of stream-aligned and enabler teams. The idea originates from looking to reduce the cognitive load for others by ring-fencing individuals who are knowledgeable in a sub-domain so they can be available at short notice. In a large project, we generally align sub-teams with specific product features; these are the stream-aligned teams. When their members have to learn how to do uncommon but mandatory activities, it can become a form of waste. Whether you are working on a computer game or a word-processing application, no matter what sub-project or feature you are working on, you must set up and maintain continuous integration, static-code-analysis, issue-tracking, or other technically complex supporting systems. Enabler teams help to keep the stream-aligned teams on track. They act as knowledge-on-demand resources when dealing with tasks that the stream-aligned teams only need to do once.

The locals in the Mexicali project were the stream-aligned teams with a purpose and vision. Those coming in to help them with processes and skills in construction and design were their enablers. The enablers helped the teams achieve necessary but daunting tasks. For example, builders on the enabler team taught the locals how to set up and work with the brick-making machine. The locals did not know how to plan for plumbing or other utilities, but this was a one-off event for each family to get them past a bump in the construction. Enabler teams provide on-demand, just-in-time knowledge. This bears a great similarity to the workshop, where an apprentice and a master of the trade would work side by side, with a specialist being brought in to do the irregular but occasionally necessary work. When we form and maintain a team under agile development, we forget about this spontaneous need for knowledge and often ask a team to grow instead of supporting them. A team should self-organise around a problem but demand the right to remain ignorant when it is more effective.

Some programmers do work this way. They retain the option to work on tools as they see fit, according to their experience of what would make future work effortless, safe, and efficient. Craftspeople would look for ways to improve their work processes when there was a bit of downtime. Leads would chat with their staff over a beer at the end of the working day, and grievances would be aired as they are now, during a sprint retrospective. During a lull, they would sharpen their saws. During a longer one, they would invent a new tool altogether. However, this required slack. Without slack, there is no time for reflection or improvement. The time and motion studies took it all away. In so doing, they wasted those innovation-generating skills of the workers. Have you ever noticed how programmers who have slack and autonomy often have the best suite of tools?