Home > Articles > Programming

Achieving Agile Software Development with Large Teams

When changing to agile development with a large team, you have to deal with several issues involving people, teams, interactions, and communication structures, as Jutta Eckstein explains in this chapter from Agile Software Development in the Large: Diving Into the Deep.
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.


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.


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.


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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020