Adrian Lander - Agile 2

An example is when it is time for pay raises to be considered. If one's leadership is based on popularity, then one will be incentivized to give everyone the maximum possible pay increase to maintain their support. Servant leadership therefore has an implicit assumption that the team is composed of rational, fair-minded people who are able to see and appreciate the big picture of the organization as a whole.

Management theory has a long history. The 1900s saw the emergence of scientific management through the writing of Frederick Taylor, Henri Fayol, and Max Weber. The 1930s saw the human relations wave through the pen of Elton Mayo, Fritz Rothlisberger, and W. J. Dickson. The 1950s produced “behavioral science,” with authors such as Herbert Simon, Douglas McGregor, and Rensis Likert. So-called systems thinking included writing by Ludwig von Bertalanffy, Kenneth Boudling, Jacob Getzels, and Egon Guba. The 1970s saw authors such as James March, Karl Weick, and Johan Olsen.

Scientific management treated people as machines: so-called Taylorism sought to optimize each step of a workflow, so that each person was performing as much as they could, and thereby optimize the entire flow. It was presumed that a global optimum could be reached by optimizing each step of each task and assumed that all the tasks were predefined by a “scientific” designer of an optimal work process.

Taylorism did not actually seek to dehumanize people. In fact, Taylor believed that as each worker became expert in a task, they would be respected as an expert. However, that element of his theory is often forgotten.

Also, Taylorism did not consider the mental health of the workers or their personal motivations; it saw them only as mercenaries who needed to be pushed as far as they could bear, not too unlike the slaves of a galley ship, except that the shackle was replaced by the desperate need of a job in those times.

Max Weber wrote extensively about the need for a bureaucracy to bring order to management. Ironically, he viewed a hierarchical structure with rules of behavior as a solution to the favoritism and subjective judgment that was common within less formally structured organizations. Those times were characterized by what we, today, would call more Agile arrangements, and hierarchy and bureaucracy were seen as a remedy for the unfairness that was common in those setups. 18

Systems theory as first described by Ludwig von Bertalanffy, Niklas Luhmann, and others pertaining to social systems viewed an organization much like a biological organism. In a systems view, an organization seeks a steady state, which authors of the time referred to as homeostasis , and there are feedback loops that maintain that state. 19 Understanding the organization means identifying and understanding the feedback loops. (It should be noted that today systems are viewed in a broader way, not necessarily requiring a steady state.)

Thus in original systems theory we had the beginnings of the notion that is so prevalent yet problematic today, that an organization exists in a steady state and that a “project” must be conceived to change the organization to a new (steady) state, with the return on investment of that change proven up front. Today's reality is that most organizations cannot be seen as being in a steady state, because the world around them is so rapidly changing.

Behaviorists such as McGregor and Likert rejected the idea that management was all about authority and control. McGregor labeled control-oriented management as Theory X and defined an alternative form, Theory Y, in which people prefer to act responsibly and so do not need to be tightly controlled, and they often apply creativity in their work, which benefits from looser control. McGregor and Likert's writing on this emerged during the 1950s—well in advance of the Agile movement.

Some in the Agile community think that before Agile, all organizations were run in an autocratic manner. That is not true. In fact, the debate over whether autocratic or empowering methods work best is very old. An empowering style of leadership that is still widely recognized as a model today is known as mission command leadership, which dates to the early 1800s and the Prussian army.

In the mission command model, decision-making is pushed down to the lowest level so that those in the field can act immediately, using their own judgment, without having to wait for orders. Mission command relies on training those in the field so that they have sufficient knowledge and leadership skills so that they can make competent decisions autonomously. The ideal field commander is an experienced leader and is knowledgeable of the “big picture” so that field decisions can take the overall strategy objective into account. Individual soldiers are expected to be able to make judgments too, so that if they are separated from their commander, they can act without delay.

Applying this in a business context, the mission command model informs team members of the big picture and goals and empowers team members to decide how to get the job done. Thus the Agile Manifesto principle that reads, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done,” is well aligned with mission command, from the early 19 thcentury.

Unfortunately, this line of the Agile Manifesto has been interpreted by many as “always trust the team,” failing to understand that the capability of the team members is highly relevant to how much autonomy a team should be given. Is complete autonomy for every team from day one what the authors of the Agile Manifesto intended? We do not know, but to us that would be irrational; and in the mission command model, a mission commander first assesses if the troops are up to the task or if they need more training. A mission commander also knows that there is a cost to failure—perhaps a cost in lives—and so failure as a learning tool best occurs during training, not during actual missions.

Good judgment about when failure as a learning tool is appropriate is essential, even for product development. If one's product is a website about retail items, some level of mistakes in the deployed system are probably tolerable, and so the risk of allowing people to “learn through failure” by working on actual systems might balance out as a valid instruction strategy; but if the product is the flight control system of an airplane or if it is a microservice that manages the bank account of customers, then the balance of risk and learning reward is different, and experimentation and learning need to occur far earlier and in a safer setting.

If we could cite the one idea that screams most loudly in the Agile Manifesto, it is an idea that is not even stated explicitly but rather is embedded in the wording of each value. Each value statement specifies two things, and each statement is of the form “thing 1 over thing 2.” Then following the values statements, the manifesto says, “That is, while there is value in the items on the right, we value the items on the left more.”

In other words, the four value statements emphasize balance and judgment. Nowhere does it say, “Do this instead of that.” In every statement, it says, in effect, “Use your judgment about the situation.”

This has been overlooked in the community, where the polarity between the two statements is taken to mean that one side is bad and the other side is good. The caveat of the need for judgment is so frequently overlooked that many written interpretations of the Agile Manifesto leave it out entirely and pose a series of good/bad opposites.

We mentioned earlier that since the Agile movement began with Extreme Programming (XP), which set the tone for extremes, this could be why the Agile Manifesto came to be interpreted in an extreme way: when people read the value statements, they read them as, “Do this instead of that,” rather than “Consider these two things and balance them for the situation.” Agile became a movement of extremes, to its detriment.