Читать книгу Agile 2 - Adrian Lander - Страница 14

Earlier we posed the question, do these practices favor certain ways of working at the expense of others so that certain people benefit but others are at a disadvantage?

The group that authored the four values of the Agile Manifesto was pretty homogeneous. As we said, they were all English speaking, most were from the United States with a few from England and one from the Netherlands, all were men, and all were very experienced. They did not represent a “typical” team of programmers. It is reasonable to expect, therefore, that they had some collective biases that differ from how a typical team of programmers would feel and think.

Since most were experienced, one might assume that when they wrote that they value “individuals and interactions over processes and tools,” they were thinking of themselves as capable individuals—individuals who are highly experienced and who have refined judgment about IT methods. Such individuals arguably need less oversight—less process.

Within the principles that some of the group came up with, one of them reads, “The best architectures, requirements, and designs emerge from self-organizing teams.”

That one principle has resulted in a strong preference within the Agile community for “self-organization,” that is, a team in which there is no designated leader. The authors of the Agile Manifesto were able to come up with four values in the course of a weekend, so they clearly were able to self-organize enough to accomplish that. Would they have been able to continue to be organized over a period of months to create a complex software product?

No one can say. The principle regarding self-organizing teams has been one of the most contentious statements of the Agile Manifesto. An article by one of us in LinkedIn about self-organizing teams received 45,000 reads in the first two weeks—two orders of magnitude higher than the normal read rate for that author.

What happens if you put a group of people together and tell them to “self-organize” to achieve a goal? Well, it depends.

You will read that phrase, “it depends,” a lot in this book. We believe it is central to all of the issues pertaining to how groups of people should work together. In the words of Malcolm Gladwell, the author of Blink, the only answer that is always right is “it depends,” and that is definitely true when dealing with groups of people.

Some of the factors affecting how well a group self-organizes are:

 Personalities—some personalities mix well, others less so.

 Level of knowledge and experience—do they know the job well enough to get it done without supervision?

 Urgency—how important is their goal? Do their lives depend on it? Or at the other extreme, is it something that someone else wants—something the team sees as inconsequential to them—and they are mere mercenaries?

 Preparation—have they been trained to work in a certain way so that everyone has predefined roles?

 Proven history—have they worked together before and shown that they can?

There are certainly other factors as well.

Some people work well in a group; others have trouble in a group and prefer to have their own task. The Agile community tends to dismiss the value of these “loners” or “lone wolves.” Yet lone wolves have created some of the most impactful software. Linux is an example. It was created by Linus Torvalds, who is a self-proclaimed loner and introvert. Today he still oversees the evolution of Linux, but he does so in a room by himself, communicating with the thousands of Linux kernel developers involved entirely by email. Linux powers most of today's computers, from smartphones to most of the servers in the cloud. If you use Amazon, you use Linux. If you use an Android phone, you use Linux.

Introverts tend to shy away from groups. Groups are taxing for them. In contrast, extroverts seek out groups—groups energize them. It follows then that in a team in which the prescribed form of communication is face-to-face and verbal, introverts would feel a lot more taxed than extroverts, who would actually find the frequent face-to-face discussions energizing.

One of the principles in the Agile Manifesto reads, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

This seems to clearly favor extroverts. Extroverts will enjoy resolving every issue by turning around and talking to others. They would enjoy convening an ad hoc meeting to discuss the issue. According to Noa Herz, a neuroscientist and neuropsychologist, “Group meetings, in which each participant contributes thoughts in a disorganised, dominance-based manner, can put introverts at a disadvantage.”¹⁷

An Agile coach or Scrum Master is supposed to facilitate team meetings, but doing so can be challenging. If a few members are talking rapidly, a facilitator might feel that the members are “on a roll” and be hesitant to interfere.

An introvert—by definition—will find that situation emotionally taxing. Even if asked their opinion, they are not likely to keep the floor long enough to actually convince anyone. It is therefore reasonable to assume that introverts might prefer to first communicate in written form and meet in person only if it is necessary.

An interesting fact about programmers as a group is that they think they are extroverts.¹⁸ Yet some psychological studies indicate that programmers actually tend to be introverts.¹⁹ It is a complex issue, though, because other studies produce conflicting results on the question.

Regardless, there is still a problem, because while Agile appears to favor extroverts, the people at whom Agile methods are mostly targeted—software developers—have a high proportion of introverts, as a group, even though the actual percentage is unclear. Even if, say, 60% of programmers are extroverts—something that would be a counterintuitive career choice—forcing extrovert-favoring methods on the other 40% would be unfair and counterproductive.

It is also a problem because by sidelining introverts, teams suffer. According to Herz, “Entrepreneurial teams perform better when leadership is shared between individuals, but only if they have diverse personality traits. Moreover, teams dominated by extraverted members actually perform better under introverted leaders,²⁰ possibly due to their greater responsiveness to their employees' ideas.”

How did the Agile Manifesto come to be written to favor extroverts? Were the authors of the Agile Manifesto extroverts? It is hard to say, but the manifesto's stated preference for face-to-face communication aligns with what one of the authors had been writing shortly before their meeting. Alistair Cockburn had written extensively about how, in his opinion, face-to-face communication is the “most effective” form of communication.²¹

So it is possible that one member of the group influenced the others—a member who seems to fit the profile of an extrovert, based on his high level of involvement in Agile community group initiatives.

Is it really true? Is face-to-face communication always best?

It depends. (There it is again.) We will dig into that question a great deal in Chapter 6, when we talk about how collaboration occurs for simple and complex issues.

What about the people who help Agile teams to define how they work? That is, Agile coaches and Scrum Masters? Do they tend to be introverts or extroverts?

We are not aware of a study on that question, but consider that in seeking such a job, one is looking for a role in which one is coordinating groups of people and encouraging face-to-face communication. It stands to reason that the job, as defined by Scrum and the Agile community, would attract people who like working with groups of people—in other words, extroverts. And it has been our experience that Agile coaches do, by and large, seem to be “people people,” although they are as varied as the people in any profession, and no two are the same.

If it is true—if Agile coaches and Scrum Masters lean slightly extroverted—then we have a slightly extrovert-leaning population advising a somewhat introvert-leaning population on how to work. What could go wrong?

Ignoring whether an Agile coach or Scrum Master is an introvert or extrovert or something in between, and following default Agile practices that favor extroversion can be detrimental if those practices are not what are actually preferred by the team members.

Does this matter? Is there actually a problem? What impact might this have?

Let's look at common complaints that we have heard from programmers who work on Agile teams.

 “I can't focus! There are too many distractions and disruptions.”

 “Too many meetings!”

 “I don't actually want to know what everyone else is working on!”

 “I don't actually want to self-organize! I want someone to get us organized so that I can code! I just want them to let me code the way that I want to.”

 “I don't actually want to reach out to others for ad hoc discussions! I only do that as a last resort if I am really stuck.”

 “Not enough attention is paid to technical issues!”

If these complaints are valid, it is a pretty bad state of affairs, because the true needs of programming teams are not being addressed by the Agile community; in fact, it is worse than that: programmers are being literally coerced, by organizations that adopt Scrum as a mandatory methodology,²² into working in a way that is not suited to their personalities.