Wednesday, April 7, 2010

Is it a Group or a Team?

This question often occurs to me when I'm on training or coaching assignments. The provocation is usually a statement similar to the following: "We have a development team of 250 highly skilled engineers...." or "Our QA team just can't seem to keep up with development...." or "The business analysis team writes all of our requirements...." or "Our middleware team serves multiple simultaneous projects."

It is common usage to apply the term "team" to mean any collection of individuals who perform some related function, regardless of how those individuals actually work. To me, a team is a very specific type of human organizational unit, defined by how it works, rather than by what it works on. Simply put, teams are distinguished by teamwork. I have even, very occasionally, encountered fair approximations of cross-functional Scrum "teams" that fail to meet this most basic definition.

Teamwork describes a particular way of working toward a shared goal. I have distilled the essential characteristics of teamwork into the following (incomplete) list:
  • sublimation of individual ego and need for recognition to the needs of the team
  • sharing and balancing workload dynamically at daily or finer granularity
  • individuals offering and requesting help in an environment of trust
  • willingness to make personal sacrifices in support of the team
  • recognition that the team's goal outweighs (but does not exclude) individual goals
I'm certain there are many more traits that one could apply to describe teamwork, but this works for me as a starting point for the discussion. The key distinction I see between a team and a group is the collaborative effort a team engages in to meet its collective goal, for example, a Sprint commitment. A group, on the other hand, may indeed consist of skilled, well-intentioned individuals, but without a collaborative framework and a collective goal, teamwork is absent. The common example is the group of developers, each individually working on their assigned tasks, head down, blinders on, either unable or unwilling to share the load with their fellow group members. Sure, they're all working toward the same end point, but on parallel tracks that by their very nature cannot converge. Group work results in the standard array of dysfunctions and failures that characterize traditional software projects.

Implied in my list of teamwork traits is a self-organizing, empowered team that has the authority to set its own commitments and determine how best to meet those commitments. Another implication is that a team is small. The standard Scrum guideline for team size (seven plus/minus two) has always worked brilliantly in my coaching experience.

So the next time you hear a client or colleague talking about a "team," make sure you know what they really mean: Is it a Team or a Group?

All for now....

...-.-

Tuesday, April 6, 2010

The Law of Unintended Consequences

This is big topic, but today I want to talk about just one small aspect: the unintended consequence of command-and-control work environments. There is a persistent myth in the software business that runs something like this: if we plan every detail of our product, assign the details to individuals, monitor and track each individual's progress on each task, make sure the load is balanced across individuals and always at the maximum (or just a little more) that each individual can deliver, and if we put in place sufficient incentives and penalties to make sure that individuals follow the plan exactly, the end result will be a perfectly executed project.

Aside from the obvious difficulties of planning a future over which we mere mortals have neither control nor even foreknowledge, there is a massive gotcha lurking in the shadows of this defined, command-and-control approach that is the result of the Law of Unintended Consequences: malicious obedience.

Malicious obedience is a common behavioral response to situations in which individuals know that they have no control over what they work on, how they work, or the outcome they produce. When the incentive/penalty structure emphasizes obedience over all else, people learn very quickly to do precisely what they are told and nothing more, even if they know perfectly well that what they are doing is not the best way to achieve the end goal, which in the software industry is a working, valuable product. A common example, and one that I have experienced on more than one occasion, is when developers write code exactly as specified even when they know that what they're coding is incompatible with some other part of the system, either because of an initial design failure or a requirements change that did not propagate to their part of the system in time. Since command-and-control values obedience over all else, the developers in question had no choice but to follow the plan, write the code as specified, generate waste, and damage the overall project. "We were just following orders, sir."

Since a successful project is (or should be) the actual goal, the cure is to apply Agile principles and practices throughout. When people choose their own daily tasks, freely commit as members of a team to deliver a Sprint backlog, and have control over how they implement a solution, malicious obedience is no longer an issue. To put it another way, removing the compulsion to follow arbitrary orders from the equation eliminates the possibility of malicious obedience. When people are empowered to take ownership of their work, the Law of Unintended Consequences breaks down, resulting in innovative solutions, sterling quality, and timely feature delivery.

All for now....

...-.-

Tuesday, March 16, 2010

The Ghost of Frederick Winslow Taylor, Part 4


Last time we saw the Utopian glimmer Taylor thought his vision of scientific management offered. Let's wrap that up and get to the Agile connection this time.

In his cold, raspy, ethereal voice, Taylor's ghost asserts that scientific management gives both workers and management what both groups most want, viz., high wages and low per-piece labor costs (cf. p 93). He goes on to say that workers "should" be encouraged and allowed to propose new and better methods of working, which after adequate study and experimentation, management may choose to adopt as the new standard for a given task. The individual worker who proposed the new method "should" receive full credit for the innovation and be paid a cash bonus as a reward (cf. p. 128). Taylor is unable to provide an answer to the question of just how exactly any worker, bound up by the rigid work rules and defined pace scientific management imposes, could ever have the opportunity even to think of a better way of performing a work task. Even worse, management is under no obligation to allow workers to experiment with alternative ways of working.

Taylor wraps up his case with yet another Utopian flourish. First, he states that the new division of duties between labor and management along with "intimate, friendly cooperation" ensures labor peace (cf. p. 140). And finally, scientific management, by dramatically increasing wages ends the wage problem. Even more, the close, constant, and intimate cooperation (there's that formula yet again) between management and labor produces a commonality of interest that makes labor strife impossible. The broader benefits that result are reduction in poverty (through high wages), cheaper products, and better competitiveness even during economic downturns, resulting in minimal economic dislocation (cf. pp. 143-44).

Those are bold statements, but they are -- and always were -- as ethereal as the ghost who continues to assert their validity. First off, Taylor never had any evidence to support his Utopian vision of labor-management cooperation and perpetual peace. Labor strife did not end as scientific management spread. Indeed, scientific management simply escalated the labor-management war by giving management a potent weapon to use against labor. Secondly, he simply ignored the greed and lust for power that characterize the owners and managers of capitalist enterprises. Scientific management came into widespread use and indeed is still at least implicit in the vast majority of businesses of all types.

Taylor provided the theoretical basis for management to remove every shred of the workers' control over the work they were doing. He took away their tools, their knowledge and expertise, and their genius for self-organization and replaced them with rigid command-and-control structures that governed every aspect of work. His predictions of huge increases in productivity, the one aspect of scientific management for which he had good data, were indeed realized. High wages did not follow, however. Industrial management realized that they could realize vastly higher profits by reducing their workforces by the 80-90% Taylor forecast. As scientific management spread rapidly throughout the US economy, high unemployment became the norm, making it very easy for management to use scientific management to squeeze high productivity from workers while offering only the threat of replacement as an incentive to stay in their increasingly oppressive jobs. Henry Ford's famous doubling of his workers' wages in 1914 was short-lived: a stockholder rebellion and resulting lawsuit forced wages back down.

So where's the long-awaited Agile connection, you might ask (I'm sure you are)? Easy. Taylor was wrong. Scientific management, with its heavy handed, command-and-control work methods, stifled innovation by making it impossible for the people actually doing the work to contribute to the development of new and better products. Agile frees this most important source of innovative thinking from the bonds of rigid work rules and suffocating management oversight. Companies haunted by the ghost of Frederick Winslow Taylor stagnate and are unable to adapt to the rapidly changing economic conditions that are now the rule rather than the exception.

Chase Taylor's ghost from your building -- and from your mind. Take advantage of the power of self-organization. Win in the market by being adaptable, by drawing upon the power of innovation that comes with building teams of motivated individuals and trusting them to get the job done. It's long past time for Taylor's ghost and his century old prescriptions to be laid to rest.

All for now....

...-.-

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

Monday, March 8, 2010

The Ghost of Frederick Winslow Taylor, Part 3

Last time, the ghost of F.W. Taylor told us about management-labor cooperation and gave us a hint of his Utopian vision. Today, he's still going on about cooperation and how it is to be achieved. Let's listen in....

Since scientific management requires companies to define each task to the finest detail, there must be a massive expansion of management activity going on as well. And indeed, that is the case. According to Taylor, scientific management requires the establishment of a large and elaborate management structure to plan the work of each worker at least a day in advance, record each worker’s output, train each worker as needed for each task, keep and issue necessary tools each day, etc (cf. p. 70). Whereas previously, workers had provided their own tools, expertise, and initiative, now all three of those categories would fall strictly under the control of the new, massively expanded management.

Achieving maximum output requires cooperation, but no individual worker has the authority to require peers to cooperate in that effort. Only management has that power. Therefore,

“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 of enforcing this cooperation rests with the management alone.” (cf. p. 83. Original emphasis)

Management must train all workers and dismiss those who are unable to meet the required work pace after training. Management must also recognize that workers will not submit to rigid task standardization and faster pace of work unless they receive a substantial increase in pay in return. And finally, all four components of scientific management must be applied in order to realize the promised results (see the previous post in this series).

This is beginning to sound less and less Utopian, despite Taylor's repeated and plaintive calls for dramatic wage increases after the adoption of scientific management.

Next time we'll drive a stake through the heart of Taylor's Utopian daydream and examine the consequences of his ideas.

All for now....

...-.-

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

Friday, March 5, 2010

The Ghost of Frederick Winslow Taylor, Part 2

In our last installment, we heard Taylor state that cooperation between management and workers was the essence of scientific management. Now it's time to query him about what scientific management actually is. So here we go....

The new role of management under scientific management is to provide task-level standardization of methods to achieve maximum efficiency from each worker. In return for vastly increased productivity, workers must receive 30-100% increase in wages or else they will simply not agree to work in a new way. With management taking on half the burden of the work, in the form of task-level planning, and the increase in pay, labor-management relations will be automatically close and cordial (cf. p. 27).

Taylor's thesis was that only through scientific management could both employer and worker fulfill their needs and ambitions and that once those criteria were met, there would no longer be any cause for labor unrest. The backdrop to Taylor's work was the intense, violent, and often bloody warfare then taking place between owners and workers, both in the US and in Europe. There was also the ideological struggle being waged between industrial capitalism, socialism/communism, and anarchism. Taylor attempted to demonstrate that by cooperating in a spirit of shared sacrifice, labor and management could work together for the benefit of everyone. We'll assess the success of his prescriptions in that area later as well. Suffice it to say that following a visit by Taylor to a workplace, 80%-90% of the original workforce joined the ranks of the unemployed. But back to our Taylor haunting....

Taylor urged management to take on the responsibility of collecting all of the tacit knowledge of every trade practiced in their enterprise and “classifying, tabulating, and reducing this knowledge to rules, laws, and formulae which are immensely helpful to the workmen in doing their daily work.” Management would also take on four essential tasks that form the heart of scientific management:
  1. Develop the science for each element of the work every worker performs, using time and motion studies, etc.
  2. Scientifically select, train, teach, and develop each worker to the highest level. Previously workers chose their own work and carried out their own training by whatever means they could arrange.
  3. Management must “heartily cooperate with the men so as to insure all of the work [is] being done in accordance with the principles of the science which has been developed.” This means training at the task level.
  4. Almost equal division of work and responsibility between management and labor, with management taking on the science and task-level direction of each worker (cf. pp. 36-37).
Taylor acknowledges that scientific management inevitably results in a further division of labor as tasks are separated and subdivided (cf. p. 38).

So where are we at? So far we have vastly improved productivity, a recommendation for much higher wages, labor-management cooperation, task-level direction, and extreme and increasing division of labor. That is at best a mixed ledger. Next time, we'll look at Taylor's ideas on cooperation and how it is to be achieved. We'll also begin to form a picture of what scientific management meant to the people doing the work. And don't worry -- we'll get to the Agile connection very soon.

All for now....

...-.-

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

Wednesday, February 24, 2010

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.