Topic: Human factors
Several years ago I took the Certified Scrum Master course with Ken Schwaber as the instructor. He presented a list of factors that reduce a team's velocity. Ken's list was two pages long and suggested rather small numerical factors to be multiplied together to ascertain the net reduction in velocity as compared with a team's own norm. In practice, I've found most of these to be very minor and subject to variation. They can be safely ignored. I pay attention only to the top three of the factors Ken listed: (1) Whether the team is working together for the first time; (2) whether the team has domain knowledge; (3) whether the team has experience in the technologies used on the project. This has proven to be very practical and useful in project planning. The largest impact comes when a team is working together for the first time. Ken suggested this causes a 40% hit to velocity, approximately. My experience with iterative agile methods since that time tells me that is a very accurate number.
Most agile practitioners understand it takes some time for a team to "gell," or settle into the routine of working smoothly together. Until that time, the team doesn't achieve its own normal throughput or velocity. This is one of the reasons for the agile guideline to form teams for the long term and keep the same people together project after project, in contrast with the traditional approach of forming a new team for each project.
What surprises me is the widely-held assumption in the agile community that it's okay to change one or a few team members occasionally. Project managers and ScrumMasters tend not to treat this as a "new team" situation. They don't adjust their projected completion dates for delivery when they change individual team members. The assumption is that swapping out one team member doesn't disrupt the team very much. I have observed quite the opposite in working with a number of agile teams in several companies. My experience suggests that any change in team composition effectively results in a new team that has to begin learning how to work together from Square One.
I've had difficulty communicating this idea to my fellow agile practitioners. Two unrelated experiences may have provided me with language to describe the phenomenon. The first was a conversation with a Catholic priest about marriage counseling. I questioned the ability of a man who can never be in a relationship with a woman to help others who are in relationships. He explained that much of this sort of counseling really deals with general interaction patterns between two individuals, and that most of the problems married couples face aren't unique to the marriage relationship (with the obvious exception, of course); they can occur in relationships between any two people in any context. He described a simple model of personality types that he has found effective, and that I found interesting because it corresponds with my own observations of people and their interactions. It's simpler than the Myers-Briggs type indicators that many of us use in our work with teams.
In this model, each of us has three traits of particular interest in the context of team interaction: The desire to win; the desire to find the best solution to the problem at hand; and the desire to avoid conflict. The strength of each of these characteristics differs in different individuals. One person might primarily be driven by the desire to win, and secondarily by the desire to find the best solution. The next person might primarily be driven by the desire to avoid conflict, and secondarily by the desire to find the best solution. These are not conscious choices, but rather natural traits. The relative strengths of the three characteristics in each member of a team in the workplace will inform his/her interactions with each teammate.
The second experience relevant to this topic was my reading the book, Divide Or Conquer: How Great Teams Turn Conflict Into Strength, by Diana McLain Smith. In understanding how teams function, Smith takes the view that the interpersonal dynamics of a team are a function of the interpersonal dynamics of each pair of team members. She uses the language of human relationships in the book; she doesn't speak of this in terms of "functions." For my purpose here, I think it makes sense to think of it that way, though. The number of unique pairs of individuals on a team is given by the following formula:
Thus, for a team of four, there are six unique pairs; for a team of 20, there are 190; and so on. Conventional wisdom holds that the impact on a team of four of changing one team member will be greater than the impact on a team of 20. When we change one member of a team of four, we are changing 25% of the personnel on the team. When we change one member of a team of 20, we are changing only 5% of the personnel on the team. Therefore, it follows that the impact on team throughput should be minimal if we change one person on a team of 20.
If we accept Smith's model for team dynamics, however, we must expect the opposite effect. When we change one member of a team, we change all the one-to-one relationships that directly involve that team member. So, if we assume all the other one-to-one relationships on the team will be unaffected by the change (a faulty assumption; more on that later), then by changing one member of a four-person team we create three new one-to-one relationships; we have changed 50% of the team, not 25%. If we do the same for a 20-person team, we create 19 new one-to-one relationships; we have changed 95% of the team. This effect may be a consequence of the agile working style, which involves close and nearly continuous collaboration among all team members. With the traditional working style, individuals worked mostly in isolation, and overall team dynamics may not have been as strongly affected by changing a single team member.
There is still more to the story. Remember the three personal traits in the priest's model of interpersonal dynamics. Say we have a team of six with the following characteristics:
- Team member Johan's interpersonal interactions are driven primarily by the desire to win, and secondarily by the desire to find the best solution.
- Three of Johan's team mates are primarily driven by the desire to find the best solution, and secondarily by the desire to avoid conflict.
- Two of Johan's team mates are primarily driven by the desire to avoid conflict, and secondarily by the desire to find the best solution.
- Johan favors a certain architectural design alternative for the solution the team is building; call it Option 1.
- Option 1 is also supported by one of the team members who prefers to avoid conflict above all.
- The other four team members favor a different architectural design alternative, Option 2.
The team's architectural design discussions typically follow the same pattern. Most of the team members who are primarily concerned with finding the best solution argue for Option 2, while Johan argues for Option 1. Johan turns to the team member who supports Option 1 from time to time when he wants someone else to show support for his ideas, but for the most part he argues single-handedly for Option 1. He is very persistent in arguing his position because he strongly prefers not to "lose" arguments. While most of the other team members favor Option 2, including those whose primary motivation is finding the best solution, they all back down eventually because the desire to avoid conflict is either their strongest or second-strongest personal trait. Ultimatly, they would rather just stop arguing than to try and convince Johan of the objective merits of Option 2.
Let's say that at some point during the project one of the team members who supports Option 2 leaves the company, and is replaced by a new colleague, Martin. Martin learns about Options 1 and 2 and concludes that Option 2 makes sense for the solution the team is building. Martin is primarily driven by the desire to find the best solution, and secondarily by the desire to win. He is less inclined than the other team members to give up an argument just to keep the peace, especially when he feels he is defending the best solution to the problem at hand.
Now the team's architectural design discussions are different. Martin stands up to Johan, and because they now have a team mate who is willing to defend Option 2 strongly, the other team members speak up and lend support to the idea. What has happened is that the introduction of a different personality type has changed not only the one-to-one relationships in which he is directly involved, but also the one-to-one relationships between other team members. Johan can no longer push his own ideas through just by being more argumentative than the others. This effectively changes the entire team dynamic; it is a wholly new team.
Martin's joining the team changes not only the one-to-one relationships in which he is directly involved; it also changes the one-to-one relationships between Johan and each of the other team members, and probably those involving the relatively quiet supporter of architectural Option 1, as well. Once team members get to know Martin and discover he is primarily driven by the desire to find the best solution, other one-to-one relationships on the team may change as well, as people realize that they can freely explore design ideas without worrying about being shouted down by Johan. For all practical purposes, every one-to-one relationship on the team changes.
One of the immediate effects of the change is that the team's throughput or velocity will fall by about 40%. This is perfectly normal, since this is now an entirely "new" team.
As PMs or SMs, we need to be aware of this effect and give it due consideration in planning. The key points are that changing a single team member has a greater effect on a larger team than on a smaller team, although that may seem counter-intuitive at first; and that introducing a different personality type to a team will likely change every one-to-one relationship on the team, which in effect creates a new team.
