Below follows an interview around presentations Marcus holds about Taylorism in the context of software development.

Hi Marcus. First of all, briefly, what is Taylorism?

"Taylorism" is a term normally used to describe the organizational ideas of Frederic W. Taylor. In the early 1900's, Taylor worked at a steel mill trying to make workers more effective.

He did this by dividing labor between management and workers and optimizing individual steps in processes by measuring them. He wrote about his experiences in the book "The Principles of Scientific Management", which was published in 1911.

And how does that relate to software development?

Unfortunately, more than one would initially think! Taylorism and mass production, which came after it, have greatly influenced the Western management style:

• We do divide labor between those that decide how to do things and those who do it - think architects and coders.


• We use measurements for individual steps in a process.


• We organize people by competence instead of by what we are making, which is mass production's legacy.

This management model is really hurting the industry. Programming is an undeterministic design process where the outcome largely depends on who is doing the job. But we cling to the dream of running the IT department as a factory, with exchangable resources, deterministic outcomes, and detailed long range plans.

OK. But how should we then be doing it instead?

The answer could probably be the topic for a whole book, but I'll try to keep it short.

1. First of all, I think we seriously need to rethink the idea of the IT department as a separate part of the organization. In many cases, IT should be integrated into the business that it is supporting, enabling a better understanding of what value is actually being delivered.

   When we have separate organizations not measured by end value, we introduce local optimizations. An example of this is when the central IT department is measured by uptime and therefore is very reluctant to change, introducing draconian release procedures as a result. This is often in total opposition to the business need of a fast time to market.

2. Second, we need to focus on successful products instead of successful projects. Projects are often measured by the classic "on time, on budget" which often leads to projects delivering the wrong thing. Instead, we need to incorporate real world feedback early in the process and adapt accordingly.


3. Finally, people aren't resources. Period. The outcome of any development effort will depend on who does the work; centrally decided coding standards and certification requirements will not change that.

In the end though, it is important to remember that the exact answer depends on your organization's unique needs. There are no one-size-fits-all solutions.

How do Tayloristic organizations affect local decisions to "do agile"?

Quite a lot, actually. Agile and Taylorism contradict each other in their basic values. For example, the first value in the Agile Manifesto states the we should value people and interactions over processes and tools. Taylor, on the other hand, famously wrote: "In the past man has been first, in the future the system must be first."

The principles behind the Agile Manifesto say that we should selforganize around motivated individuals. Taylor, on the other hand, introduced the idea of a division of labor, where management does the thinking and workers simply perform the tasks defined. The most striking example we see of this is the division between architects and coders, where the architects supposedly do all the thinking upfront and then use the developers as a form of code secretaries to do the typing.

Why have you been doing presentations around this theme, i.e., what's your interest in it?

I have been doing agile development for about 10 years now and have for a long time realized that it is hard to introduce agile methodologies, especially in larger organizations. I first heard of Taylor in one of Kent Beck's early presentations on XP, but it was a little more than a year ago that I actually started to look into the subject. What I came to realize was that the legacy of Taylor is embedded in our culture in ways that we are actually not aware of. Or as Panasonic founder Konosuke Matsushita famously put it: "Our heads are built on the Taylor model."

Where have you done these presentations and what have the reactions been? Any new insights you gained from the reactions from the audience?

I have mainly given the talk in Scandinavia - internally at companies and conferences, like JavaZone in Oslo, JFokus and Developer Summit in Stockholm, and Scandevconf in Gothenburg. Reactions have generally been very positive. Knowing your history helps you understand the world around you and learning the historical reasons why organizations are run the way they are helps when you want to change them.

I did get a great question the other day that I want to look into - in what way did military organizational theory affect Taylor and where there any differences between western and Japanese military organizations that reflects organizational differences today? I do not have an answer yet though...

Thanks for the interview, Marcus!