The Ghost of Frederick Winslow Taylor, Part 1

So who was Frederick Winslow Taylor and why is he haunting my blog? Taylor, 1856-1915, was an American mechanical engineer and among the first practitioners of the management consulting profession. So much for the "who" part of the opening question. The haunting part is more complex. Taylor not only haunts my blog, he has haunted my entire working life and certainly the the working lives of countless millions around the world.

How could one dead white guy have that much influence, you might ask? The answer lies in a paper Taylor presented to the American Society of Mechanical Engineers (ASME) in 1911 and later published as a short book. Both presentation and book bore the title: The Principles of Scientific Management.

Taylor's purpose was to explore President Theodore Roosevelt's call to increase national efficiency and was a part of the larger efficiency craze sweeping the United States in the early twentieth century. William Howard Taft was president of the US in 1911, when Taylor presented his findings and prescription for industrial efficiency, but no matter.

Taylor set out to use the scientific method (or just "science!" as Thomas Dolby sang back in the 1980's) to secure maximum prosperity for both employer and employees by developing each employee to a state of maximum efficiency in the highest grade of work for which each employee was suited. Taylor was speaking of manual labor, both skilled and unskilled, of course, since there was no such thing as a "knowledge worker" in that day and age.

Taylor's observations of working people led him to the conclusion that any "work gang" left to its own devices would work only at the level of its least efficient member. In those days, the term for slowing work to that level was "soldiering." Taylor understood that the workers engaged in soldiering to protect their own interests against what he called "defective management practices." Workers believed, and as it turned out rightfully so, that broad increases in productivity would lead to mass unemployment, then as now, the scourge of the American economy. More on that in a later installment.

Taylor identified the key elements of labor inefficiency:

1. Workers use rule-of-thumb practices handed down through observation of their peers. There were no standardized practices even within the same trade within the same company. Management does not know how the work is done and therefore leaves the heavy responsibility for figuring out how to do the work up to the workers themselves.
2. The worker best suited for a particular job is incapable of understanding the scientific laws governing the most efficient way to complete the work. Taylor stated that it was the duty of management to take on half the workload by deriving those very scientific laws and then providing the resulting information and training to the workers.

I'll leave you with the following quote: "This close, intimate, personal cooperation between the management and the men is of the essence of modern scientific management." (p. 26)

More on Taylor's ideas next time.

All for now....

..-.-

References
Taylor, Frederick Winslow, The Principles of Scientific Management. New York & London: Harper, 1911, reprint edition, 1934.

Pragmatism

Pragmatism is a word I hear quite often in my coaching life. Webster's defines pragmatism as "a practical approach to problems and affairs." To me, that is also the definition of Agile. Every minute of training or coaching I deliver is devoted to building a practical approach to whatever problems the client is facing. With its focus on flexible planning based on realistic time horizons, short-term commitments, frequent deliveries and adjustments, Agile is the acme of pragmatism.

Where I find the term pragmatism problematic is when clients or colleagues use it as an excuse to paper over or otherwise avoid addressing issues that Agile principles and practices expose. Overcoming impediments is a part of the Agile game and the only path to continuous improvement, so declaring that some set of organizational or corporate-cultural impediments cannot be overcome is simple capitulation, not pragmatism.

That is not to say, of course, that it is possible or even desirable to change everything about an organization overnight. Successful Agile coaches -- and successful Agile clients -- are committed to playing by the rules of the game, even if getting there is a process of incremental change rather than a single, sweeping event.

The vital thing to keep in mind is that Agile, whether XP, Scrum, Lean, etc., or some combination, is a framework, something like a scaffold, in which every key aspect depends on other key aspects. What this means in practice is that for companies to be successful with Agile, they -- and their Agile coaches -- cannot pick and choose amongst the principles and key practices, deciding to implement some and ignoring those that are difficult or otherwise inconvenient. As Takeuchi and Nonaka* put it so succinctly 25 years ago when they wrote about a new way of developing products: "These characteristics are like pieces of a jigsaw puzzle. Each element, by itself, does not bring about speed and flexibility. But taken as a whole, the characteristics can produce a powerful new set of dynamics that will make a difference."

Agile today is no different than the "new new product development game" Takeuchi and Nonaka described in their ground-breaking article. Pragmatism does not mean dropping the troublesome pieces of the puzzle on the floor; it means finding practical ways to implement the key practices and all Agile principles in a given context. And that is "a practical approach to problems and affairs."

All for now....

...-.-

*Hirotaka Takeuchi and Ikujiro Nonaka. "The New New Product Development Game." Harvard Business Review, January 1986, p. 138.

The Meaning of Commitment

A common dysfunction I encounter when coaching Agile teams is a failure to understand the meaning of commitment. Scrum teams commit to delivering the Sprint backlog -- complete, tested, and ready to be shown to stakeholders by the end of the Sprint. That commitment means that the team members agree, freely and entirely of their own volition, to do their level best to meet their collective Sprint commitment. Does it always work out exactly as planned? No, of course not. But over the course of repeated Sprints, teams learn what that commitment looks and feels like and they get better at delivering on their commitments.

The lament I frequently hear is: "This team always misses its commitments." Oddly enough, I almost never hear that from members of the team in question. The source of the complaint is almost always from a stakeholder, functional manager, or executive at some level.

In the rare instance of a team whose members acknowledge that they routinely fail to meet their commitments, I work with the ScrumMaster, Product Owner, and team to ensure that they have good stories, solid acceptance criteria, follow the Agile rules for estimating, and that they understand the importance of building trust by doing what you say you are going to do. A team-based commitment failure is usually not difficult to overcome, although sometimes there can be a painful drop-off in perceived productivity as the team learns how to make a realistic commitment and deliver on it.

The much more common case of a stakeholder, functional manager, or executive expressing exasperation with routine commitment failure is usually easier to diagnose, but often more difficult to cure. The essential problem is a failure to understand that the team itself must commit to the Sprint backlog, freely and with complete consensus among team members. Any hint of a commitment that is forced from outside or arrived at without team consensus is automatically invalidated.

Think for a moment about the nature of commitment. We make commitments at many points in our lives. Marriage is a commitment. Having children and being a good parent is a commitment. While a Sprint backlog is trivial in comparison, the nature of the commitment required is exactly the same. Commitment must be voluntary. Commitments cannot be taken lightly. Commitment is a personal decision, sometimes taken in a collective context, as with a Sprint commitment when a team arrives at consensus.

One recent example of habitual commitment failure demonstrates very clearly a fundamental misunderstanding of the nature of commitment and the inevitable result. On a coaching engagement, I heard from an executive that several teams never met their Sprint commitments. He was intensely frustrated with the situation. A little probing of the situation revealed the exact nature of the problem: When asked where the Sprint commitment for the teams in question came from, his response was, "I tell them what they'll commit to each Sprint." It turns out that he had laid out the teams' Sprint commitments months in advance. I explained that a Sprint commitment forced on a team from outside placed the team under no obligation whatever and that such a policy had completely undermined the company's entire Agile practice. When the members of the teams confirmed my assessment of the situation, the executive backed off and started allowing each team to make and deliver its own Sprint commitments. The problem of Sprint commitments not delivered vanished instantly.

A related problem at the same client proved to be the result of the ScrumMaster assigning all tasks at Sprint planning. The team did have control over its Sprint backlog commitment, but pre-assigning tasks left the team fragmented, demoralized, and unable to make the daily adjustments necessary to meet their commitment. When the ScrumMaster agreed to allow team members to self-assign tasks on a daily basis and to self-organize, using the daily Scrum, to ensure that they did everything possible to meet their Sprint commitment, the result was amazing. The team became cohesive, lively, and productive. They began meeting their Sprint commitments and experienced a remarkable increase in velocity after a few Sprints.

Commitment is not just a buzz-word. It is a vital component of Agile and a key ingredient in every team's success. So do the right thing, empower your teams to commit and reap the benefits.

All for now....

...-.-