Taylorism Creeping Back in
We’ve worked in countless organizations where people hold strong beliefs about product development that aren’t compatible with the proper use of the Scrum framework. These beliefs are often held both by people in various levels of management and among the people doing the work. These beliefs are often overlooked and rarely discussed because the trust needed to talk about them is lacking. To make matters more difficult, many of these beliefs are deeply rooted in corporate culture and are difficult to work through.
What kinds of beliefs, you ask? Ones that people in management and large organizations have held for a long time. In fact, many of these beliefs are over 100 years old. We won’t bore you with the details, but in 1911, Frederick Winslow Taylor published a study called The Scientific Principles of Management,[5] which resulted in a methodology known as Taylorism. Taylorism is rooted in the idea that we can break tasks into very small, simple steps that can be analyzed, taught, and repeated. The goal was to separate workers’ brains from their hands. In other words, remove the need to think about the work and simply give people small steps to follow to complete a task. With small steps in place, the result is predictability and compliance, not innovation.
Taylorism was designed to solve manufacturing problems that were prevalent in the industrial era (which emphasized repeatable work), and it solved those problems quite well. But when people apply the principles of Taylorism to complex work in the innovation and development space, the results are typically disastrous.
Taylorism differs dramatically from the Scrum way of doing things. A quick summary of the main beliefs in Scrum and Taylorism is shown in the table.
| Taylorism | Scrum |
|---|---|
Workers only know how to do the specific tasks they’ve been assigned; they don’t have or need a big-picture view of what their organization is trying to accomplish and are not encouraged to broaden their skill sets. | Work is performed by cross-functional teams that have all the skills they need to get the job done. These teams are supported by leadership, and high levels of trust are leveraged between leadership and Scrum teams to make decisions quickly and deliver increments of working software to customers frequently. Workers are encouraged to broaden their skill sets and collaborate. |
Managers plan work without input from the people who perform the work. | Planning happens at varying levels across all the Scrum roles. Management is invited in to inspect the team’s work during sprint reviews and to collaborate with the product owner, so that the team can take management and stakeholder opinions into consideration as they figure out what to do during the next sprint. |
Management tries to make the work as predictable as possible by precisely managing resource utilization with exact estimates. | Scrum teams manage their time and focus as they plan their work. The development team is responsible for resource utilization. They use estimates to trigger conversations within the Scrum team and with management—not to make the work as predictable as possible. |
Management optimizes workers’ performance using metrics and measurements. | Scrum teams use metrics to optimize outcomes that benefit the customer. |
Management uses money and rewards as primary motivators for performance. Workers are motivated to achieve rewards and avoid punishment (extrinsic motivation). | Scrum team members have a goal they are trying to achieve, the autonomy to achieve it, and a comprehensive set of skills to accomplish their goal. They also have opportunities to learn from each other. Team members are motivated to perform their work because they enjoy what they do and feel a sense of personal accomplishment (intrinsic motivation). |
As you can see, Taylorism and Scrum are two very different mindsets. They are basically opposite ways of approaching work. So it’s no surprise that adopting Scrum in an organization that is accustomed to the Taylorism way of doing things can be an uphill battle. Keep this info in mind when you’re trying to bring people in your organization around to the Scrum way of doing things. It’ll help you understand where people’s opposition to Scrum practices comes from.
When Taylorism and Scrum are at odds in your organization, you’ll likely see some of these signs:
-
A mechanical implementation of the Scrum framework without truly embracing its principles and values.
-
Scrum team members view Scrum as just new way to get micromanaged.
-
No meaningful signs of collaboration between Scrum team members.
-
The Scrum team is producing poor-quality increments.
-
People are still being measured by how busy they are, not by the outcomes of their work.
-
The Scrum team is unable to deliver increments of product every sprint.
-
Reverting back to past practices—but calling them by new names.
Keep an eye out for these signs that the old ways of working are still at play in your organization. This book describes a lot of anti-patterns that occur when Taylorism and Scrum compete with each other. Adopting Scrum will require conversations about your company’s culture that will give you an opportunity to create change. Take advantage of those opportunities so you can positively impact your organization and move it more toward the Scrum model, which represents the world we work in today far better than Taylorism does.