Achieving Agile Software Development with Large Teams
This chapter is from the book
This chapter is from the book
This chapter is from the book
- Trust is the sister of responsibility.
- —Asian proverb
The reasons for implementing a system with a large team are varied. The most common one is that the scope of the project is too large for a small team to handle. However, some large projects would be better off if implemented by a small team. Even if the scope is large, a small team may be faster or more effective, mainly because communication is not as likely to prove a problem as it is in a large team.
Sometimes, the use of a large team is politically motivated. The size of a team may signify the importance of the project and of the project management itself. Author and consultant Tom DeMarco discussed this problem during OOPSLA 2001.1 He indicated that surprisingly often, the manager of a failed but large project will be valued higher than the manager of a successful but small project.
Furthermore, the project may be shaped and sized to suit a team that is already established. For instance, I witnessed a situation in an organization where a lot of people just sat around, waiting for the project to start. Nobody questioned if this mass of people was really required for the project. Instead, everybody tried to shape the project in a way that kept all these people busy. Granted, for some companies (in some countries), it might be easier to shape the project according to the team’s size than to get rid of the employees—mainly because of legal issues—but this is not usually the case.
It is always worth questioning the reasons for working with a large team, but this is neither the topic of the book in general nor of this chapter in particular. Instead, the assumption is that the project will be run by a large team and you want to use an agile process. When changing to agile development with a large team, you have to deal with several issues involving people, teams, interactions, and communication structures.
This chapter focuses on those aspects of agile processes that work differently in large teams than in smaller teams. First, we look at the people aspect. We discuss how taking up responsibility can work in a large team and what kind of consequences respect, acceptance, and trust have for successful collaboration. Next, we consider how a large team can be divided into subteams and what kind of team roles have to be occupied. In the section on interaction and communication structures, we focus on encouraging communication in large teams. Then, in the section on trouble-shooting, I present typical team problems and their possible solutions. Finally, we look at the difficulties that can occur when developing with dispersed teams.
People
Size matters. The size of a team provides a special risk—a team that is too large can hinder a project. One reason is that the quality of the decision-making typically suffers. For example, the larger the team, the more often you will find that decisions are unclear or postponed. The main reason for this is that within large teams, you will often find a tendency among people to shun responsibility. Because there are so many people on the team, there is a collective mentality that “someone else will decide.”
Unclear or postponed decisions confuse the team and make it difficult for team members to decide which direction to take. This leads either to project paralysis, because nobody has the courage to move on without being told, or to a lot of individual decisions as one thinks best. Often, those individual decisions contradict each other, which in turn leads to a form of project stagnation, based on contradictory development. Both symptoms are very frustrating for the whole team. I once consulted on a restart of a failed project. I interviewed team members about what trap they believed would most likely ensnare the restart. Interestingly enough, most people named a lack of clear decisions as the highest risk.
Therefore, although it might seem unusual, it is preferable to make a clear but eventually wrong decision and to correct it later. Making a wrong decision enables you to learn; postponing a decision does not. If you postpone a decision, you do not know until it has been made whether it is the right or the wrong one. However, if you make the wrong decision, you will learn from the consequences and will have the possibility of correcting your mistake, based on your new experience.
Making decisions is one side of the coin; the other is making sure that they are not only communicated to everybody involved but are also carried out. A decision that is made but not carried out is essentially the same as a postponed decision.
Although this all sounds very obvious, it is common to find the same problems popping up over and over again, which is a sure sign that those decisions either have never been clearly made or have not been realized.
As I mentioned earlier, the main reason for the poor quality of decisions on projects with large teams is probably based on an aversion to taking responsibility. You will find that the more people there are, the harder it is to tell who took responsibility for which task. Often, this results in an undefined task zone, which is defined by
- Multiplicated task responsibility: A lot of people are responsible for the same task. The problem is that they do not know about one another. Therefore, if you are lucky, this task will be carried out repeatedly. If you are unfortunate, they will do the task in ways that contradict each other.
- Null task responsibility: Nobody takes responsibility for the task. Everybody assumes that it is someone else’s job. This can result in everybody blaming everybody else for not taking the responsibility.
To make things worse, you can be assured that with each additional team member, the risk will rise and more of such problems will arise.
Responsibility
Due to the departmental organization, people in large companies are not usually used to having complete responsibility for any particular task. This is because there is almost always somebody higher up the hierarchy who has ultimate responsibility. This is especially true for developers. They often see themselves as only doing what somebody else tells them. When somebody “accidentally” gives them the responsibility for a specific task, they feel uncertain. They are not used to having responsibility, and they do not know what it implies.
On the other hand, agile processes require everybody to be responsible for his or her task, and for the effects that task might have on the whole project. In addition to individual tasks, there is also the shared responsibility for the ultimate performance of the whole system, the project, and even the process of development. Thus, each team member is responsible in some way for every task, even those assigned to other team members.
For example, Extreme Programming has a practice called collective ownership, which refers to a shared responsibility for all kinds of things: the code, the integration, the process, and so on. Best known among these shared responsibilities is probably collective code ownership, which enables and obliges everybody on the team to improve every piece of code, no matter whether he or she is the original author of the code or not.
With collective ownership, every team member bears the same responsibility for all aspects of the project. However, allowing everybody to steer the project at the same time is a challenge and, some fear, a big burden. For instance, every developer would want to have a hand in shaping his or her development environment. At the same time, this increased responsibility is likely to increase the developers’ fear of making the wrong decisions.
When people first sign up for a task but aren’t used to the responsibility it entails, you have to lead them gently into this new territory. For example, ask the developers which task they want to be responsible for, and then assist them in estimating the task. Not only should you make yourself available to answer any questions they may have, it is very important that you also ask them regularly if they are doing okay, or if they need any help, because they might be afraid to bring up such issues themselves.
For example, I remember one project I was working on, where people had problems taking responsibility. I visited all the team members regularly and asked them how they were getting along with their tasks. It did not take long before some of them started complaining that they were not able to get their work done, for various reasons. The most common reply was that they were waiting for something from another team: either the other team had not yet provided some interfaces, or the interface it had provided turned out to be different than expected.
The obvious problem was that these people did not have the right mindset for problem-solving. Instead, they complained that their peers were responsible for the problems. The real, hidden problem was that they were not taking enough responsibility. If they had, they would not have complained, but rather would have started solving their problems. In other words, they might have started talking to this other team, found out why the interfaces were not ready, and addressed the situation.
The typical reaction of people not used to responsibility is to get annoyed at the situation without taking any action to change it. Of course, it could be worse. If, for instance, they could neither complain nor take up the responsibility, you would never learn about their problems.
Therefore, you have to be proactive in asking developers about the status of their assigned task. Only then will you have an idea of any problems they may have. I’m not talking about status reports—I’m talking about walking up to the people and talking face-to-face about their current situation. You should encourage them to look at the big picture and regard their assigned task as part of the whole. Explain that even tasks that may only be partly related to their assigned task (if at all) are important for the completion of the project.
If people are spoon-fed responsibility, they will not learn to make an effort to take it up themselves. Or, as an article in Fast Company put it,
Telling people what to do doesn’t guarantee that they will learn enough to think for themselves in the future. Instead, it may mean that they’ll depend on you or their superiors even more and that they will stop taking chances, stop innovating, stop learning.2
Telling people what to do is not enough. They have to commit themselves to their task. The focal point of this philosophy is that the value of team productivity is much more important than the individual effort. Therefore, every now and then, you have to point out that only the team’s success is the individual’s success. An individual’s success without the success of the team is of no value. Among other things, this means that a well-functioning team does not rely on its official manager—it takes up the responsibility itself, whenever the situation requires it. For this approach to become a reality, the organization has to change from management by command and control to management by responsibility, trust, and teamwork.
Trust is the foundation on which such a management strategy is built. When someone takes on a responsibility, you trust that he or she is capable of handling that responsibility. However, at the start of an organization’s first agile project, this culture of trust and responsibility will not be in place yet. Most team members will not be able to take up responsibility, because they are not used to it. However, I suggest that you demonstrate to them how you take up responsibility, and that you encourage them to take responsibility even if they do not feel ready. This shows your team members that you trust them, even though at this early stage in agile development they might not be able to justify your trust. When you refrain from giving them any responsibility, you prevent them from ever getting the chance to learn how to take up responsibility. That simply reinforces their own mistrust in their capabilities. Just as Ulrich Sollmann and Roderich Heinze say, you should give people the chance to learn how to deal with responsibility:
- The more often you are in an uncertain situation, the better you can handle this kind of situation, or rather the longer it will take till you will again feel uncertain.3
If you want to train your team members to take up responsibility, you have to be aware that this is an investment in their future. This “training” is two-sided: You may also have to train leaders to delegate responsibility and to trust their team members. As with every other learning process, it will be some time before you see results, but it is worth the effort.
Respect and Acceptance
A development team is not usually organized like a team, in the strictest sense of the word—assembled by peers with equal rights—it’s hierarchical. The typical hierarchy in a development team, found mainly in traditionally led projects, follows Taylor’s theory about centralizing a team’s knowledge.4 Individual team members take up specific roles and corresponding tasks. Analysts, designers, developers, and testers often work independently in a linear process.
As a consequence of this separation of tasks and roles, a hierarchy is created. Although perhaps not officially sanctioned, the hierarchy is formed by the different roles in the team, some of which have greater prestige, importance, or acceptance level than others. Often, the acceptance level is defined by the linear development. This means that analysts have the highest acceptance level, while coders, testers, and, even worse, maintainers are at the very end of the acceptance-level chain, doing all the dirty work. This sequence of acceptance levels is just one example, but an oft-encountered one.
The major problem is that nobody wants to be at the low end of this acceptance-level chain. Therefore (as in the example above), everybody tries to climb up the ladder from maintainer to designer or, even better, analyst. From another perspective, you will find the largest percentage of novices in maintenance or implementation. Consequently, there are often too few experienced coders on a team.
In contrast, most agile processes require teams to have shared knowledge and shared skills. This means knowledge cannot serve to form a hierarchy. Therefore, the first step in forming an agile team is to get rid of the Tayloristic split. Assemble teams that cover all the knowledge, where each member of the team is aware of the big picture and takes responsibility to contribute to the whole team’s success. The individual role of each member is not so obvious, then, in terms of individual knowledge, but is recast in terms of contribution to the team’s success. So, acceptance is then based on performance and not on roles.
One of the main differences between small and large agile teams is that in the former, every individual is typically requested to be a generalist. On the other hand, as I discuss later in this chapter, in a large agile team, a whole subteam and not necessarily every individual team member should cover this general knowledge.
This implies that agile teams require more generalists than specialists. At the least, everybody should be able and willing to understand the big picture and not become solely interested in digging into some specific details while ignoring the interests of the whole project.
So, as programmer and software expert Don Wells said, you will find that in an agile project,
- Everyone is of equal value to the project.5
But this is only true if every team member bears responsibility for the whole project. Of course, each team member will have individual capabilities and abilities, but now he or she will contribute equally to the team and to the project.
Trust
It is natural for people to be skeptical of a change like switching to an agile process. The team members themselves, along with a lot of people only partially involved in the project, might not have trust in the success of this new process. The possibility that the team can change the process over time is often even more frightening than following a defined but indigestible recipe.
The best argument against this mistrust is working software. Therefore, try to complete the first, low-functional version of the software as early as possible. Another strategy for building trust is transparency. Make everything transparent for everybody involved in the project.
Different practices help to make things more transparent:
- Shared ownership: Ask everybody on the team to take responsibility for all kinds of things (for instance, the code or the process). This shows your trust in them.
- Shared knowledge: This practice is often based on shared ownership. The knowledge about the information—for example, the system—is transferred from one team member to another. This makes the system more transparent and understandable for everybody, and helps in turn to build confidence in the system.
- Shared skills: The team has people with a variety of backgrounds and skills. This knowledge is accessible not only for the individuals, but for the whole team. Using non-agile processes, the individual guards expert knowledge from the whole team. Making knowledge transparent makes the team more trustworthy. Furthermore, it allows every team member to add new skills to their repertoire.
It is important that this transparency is always open and honest. Do not hide any negative information. Knowing about the bad things makes it easier to deal with them. Moreover, everybody should be invited to comment on the information and to help improve the situation. Thus, transparency includes representatives from control, audit, and, most importantly, the customer.
Occasionally, when coaching a project, I find that project members assume that transparency stops right before the customer. For example, I sometimes have to lead long discussions in order to open the project’s wiki Web for the customer, because the customer will then have full access to the project.6 Often, when asked for more transparency, project managers tell me they’re afraid the customer will find out about the problems inside the project. This is exactly the point! The customer should always be aware of the problems, because the customer is paying for the project. These arguments are typical when discussing the impact of having the customer on-site. As soon as the customer becomes something of an unofficial project member, the fear disappears from both sides: from the team’s side, because team members realize that the customer is a real person, and from the customer’s side, because he or she understands the difficulties the project members are facing.
This reminds me of how I was before I started scuba diving: I liked swimming in the open sea, but I was always a bit afraid of the creatures underneath me, and I was pretty sure that sooner or later one of them would bite me. As soon as I started scuba diving, I did not even fear sharks or other predators. Being close to these creatures gave me the feeling of actually being a part of the living sea.