Home > Articles > Software Development & Management > Agile

Agile Breakthrough Techniques to Keep You from "Waterfalling Backward": Whole Teams

This chapter describes why whole teams experience better communication, productivity, and collective knowledge sharing than traditional silo’d teams. It makes a case for keeping teams intact as well as protecting them from interruption during a product release.
This chapter is from the book
  • Being agile requires whole teams because the synergy derived from cross-disciplined and cross-component teams working together enables teams to be more productive than working in isolation.
  • By Leslie Ekas

Do any of these phrases sound familiar?

  • “When are you going to get your problem solved?”
  • “Oops, I forgot to copy John on the email that discussed our proposed solution.”
  • “The test team can’t start working on this release yet, so we will have to start writing code without them.”

These are phrases typical of teams that work in silos. If you regularly hear such comments from your team, you are likely not experiencing the benefits of whole teams. Whole teams are composed of people who work together to deliver a product.

The first time I saw the power of whole teams went something like this: While we were building a product, our entire team met together to discuss various challenges. One developer was working on a search interface, and innocently brought up a usability problem he was tackling. This search interface showed various related fields that the user could select. (Just to describe the scenario, think of one field being the state selection and another field being the city selection. The city selection contents would change based on which state the user selected.) The developer casually mentioned that if a user selected the state and city but then changed the state, he would receive an error dialog alerting him that the city was no longer valid. One of the testers instantly became indignant and complained that she hit this issue all the time and getting an error message would drive her crazy! If she had to close an error message every time she switched the state selection, she would despise the interface and the application. The meeting came to a halt in a stunned silence.

Luckily the whole team was in attendance and that included the user experience (UX) expert. He agreed that the error dialog was a poor choice and recommended using a visual warning that the user could open or ignore. This may not seem like a big deal, but the team had already used error dialogs in the code, so this was a change in the design pattern. But everyone liked it, and after they discussed it, it seemed like it should have been the obvious solution all along. In fact the idea was so well received that over time they updated the application to use it wherever possible.

What occurred to me while I listened was that, had this problem been raised after the entire interface was written and was in test, it would have been considered an enhancement request. As such, it would not likely have seen the light of day because it would have been too late to do anything but fix broken functionality—forget about making the application a little easier to use. The more code that is written before a good suggestion comes in, the harder it is to make a change because it affects more code and subsequently requires more testing. So the team experienced “just in time feedback,” which allowed them to make the product better.

But what was so compelling is that the entire team was there. Without the whole team present and working together, this problem would have taken weeks to solve. Using email, we would likely have missed a few critical team members needed to “seal the deal.” As it was, in a few hours a problem was solved, the customer got more value from the solution, and the team did not have to revisit the issue again. During the meeting, feedback was given fearlessly and feedback was taken constructively. For me, this was an early, albeit unintentional, demonstration of the power of whole teams.

Principles

What Is a Whole Team?

In the context of agile development, whole teams are teams that are both cross-component and cross-discipline teams that work together throughout a product life cycle. The whole team is responsible for the success of its work. By cross-discipline I mean a team that includes developers, testers, and user documentation professionals (writers). By cross-component I refer to teams that are responsible—not for just a single component out of a larger project—but which have the necessary expertise to work on all the affected components. The whole team concept goes beyond just team composition though: The whole team concept is a way of thinking and acting that must become the norm. In fact, until a team starts to be a true whole team, the team may experience limited success with agile and may feel continually stuck in a beginner’s rut.

Being agile requires whole teams because the synergy derived from cross-disciplined and cross-component teams working together is more productive than when each discipline works in isolation and/or when components are developed in isolation. Whole teams succeed because they capitalize on the combined skills of each team member working together to accelerate their deliverables. Working cooperatively, they can leverage each other’s insights, instincts, and responses to ongoing work throughout a project.

This chapter describes why whole teams experience better communication, productivity, and collective knowledge sharing than traditional silo’d teams. It makes a case for keeping teams intact as well as protecting them from interruption during a product release.1

Why Are Whole Teams Hard to Create?

Traditional software development organizational structures have advocated for teams that specialize in technology and are grouped by a common discipline, for example, development, test, user documentation, and so on. The reasoning goes that teams composed of people with similar skills can help each other within their own domains. Furthermore, it is believed that teams that share a common discipline can be “time-sliced” across various projects as needed instead of focusing on one project at a time. This is the epitome of the “job-shop” mentality in which engineers just do their specific job and lose sight of the bigger picture. Unfortunately, optimizing the efficiency of a particular discipline almost always sub-optimizes the organization—a point that is often not well understood. Lean thinking in particular focuses on process throughput optimization to improve efficiency, versus individual throughput (described more in Chapter 3, “Queuing Theory”).

The whole team approach advocates the idea of team members being “generalizing specialists” who have deep skills in specific disciplines, domains, and technologies but who can also work outside their area of expertise to help achieve the team’s iteration goals. At first, teams shy away from this aspect of the whole team concept because they interpret it to mean that everyone on the team must do everything. In small, high-performing agile teams, this may be the case, but it gets more difficult as projects grow in size and encompass many technology domains. However, teams do not have to achieve the ideal level to become a whole team—but they should at least move in the direction of becoming “generalizing specialists.”

Cross-Component Teams

Software composed of multiple architectural components is often built by separate teams that develop their respective components independently. There may be a database team, an application server team, a user interface team, and so forth. After the components are developed, the parts are put together to create the product as a whole and tested during an integration phase. Teams working on a single component find this a convenient way to work because they can easily capitalize on their common knowledge. However, the overall focus of the work becomes rather narrow, and it can be tempting to hand off responsibility for some component to a remote team, further isolating the various parts of an organization. Individual component teams are likely to work together only at the beginning of a project, during initial design, and again at the end of the development cycle when trying to integrate the components (perhaps for the first time).

Building components in isolation rarely produces the best product because the bigger picture is often lost. And although it may seem counterintuitive, building independent components in isolation is less productive than building cross-component functionality from the outset. One of the basic aspects of whole teams is that they include team members from across technology disciplines that are required to develop the software. These integrated teams work together from the beginning of the project and continue together throughout the life cycle of the project. One of the core enablers of teams working together this way is continuous integration, which enables products to be automatically built, tested, and deployed from the beginning of the project. This practice avoids the typical expensive integration problems that arise when large amounts of code get integrated for the first time.

The emphasis on cross-component team composition also facilitates the practices of evolutionary architecture and emergent design.2 Whole teams, using these practices start with a minimal architecture that is “good enough” to enable them to build a “thin slice” of cross-architecture/cross-component functionality in one of the earliest iterations. All the architectural details will not have been worked out yet, but the team can test the initial, basic architecture right away. This approach enables teams to validate their architecture early in the project and have greater confidence that it is a sound architecture—or adjust it as needed—which can be much easier now rather than later because the amount of work done up to this point is so small. Compare this with finding a major problem in the architecture late in a project when various components are integrated together for the first time.

Working together as a whole team iteratively on the architecture and design enables everyone on the team to understand the strengths and weakness of the software so that the team develops good instincts regarding any noted constraints. A whole team will also have a common history that enables the team to produce more consistent design patterns as more and more features are added. Furthermore, because this evolutionary approach enables real functionality to be manifested earlier, the team can demonstrate this functionality to its customers and get feedback earlier than was possible with waterfall’s component-based development approach.

Cross-component, whole teams should be formed around epic stories or product features rather than technology. Agile teams, working together to build cross-component functionality from the beginning require that an end-to-end working environment be ready early in the project life cycle—that is, a continuous integration system that continually builds, validates, and deploys the product build. These are just a few of the items that need to be addressed for cross-component teams to function successfully in short iterations. Getting such an environment in place at the beginning of the project requires cross-component expertise, and this expertise can continue to be required as the project progresses and the environment requirements continue to grow along with the product.

Cross-Discipline Teams

Whole teams also include team members from each of the disciplines required to develop and successfully deliver the product. Teams should include developers, testers, and writers, and may also include a product manager, a build developer, a user interface designer, and so forth. It is important that teams have the collective skills to fill the required roles. Note, however, that a “person per role” is not required.

Teams organized by discipline often operate differently from cross-discipline teams. For instance, in waterfall, testing groups may wait until the design phase is complete before they develop a test plan, and testing itself doesn’t typically begin until late in the cycle when a lot of code has been written. Testers may even be prevented from joining the effort on the new release because they are finishing up leftover work from an earlier release. Getting to the point in which whole teams can begin work together on the first day of a project may take a significant amount of effort, and perhaps some behavioral changes as well. All available engineers should focus on completing any work that would prohibit them from starting together on the next release. This means getting the previous release out the door so that everyone can be available on Day 1 of the next project.

Why is it so important that a team actually start a release together? The goal for whole teams is to work together to produce a product, to learn together, and help each other get to “Done!” each iteration. With whole teams, no one gets credit for anything until the team has gotten to “Done!” Only then is any “credit” given for completing work, and it’s the team that gets the credit. It’s an all-for-one, one-for-all approach in which there’s no “partial credit” and no “individual credit.” For this to work, the team needs to start together so that coding, testing, user documentation, automation, defect fixing, code reviews, and so forth can all be accomplished as part of each iteration, beginning with the first one.

It is common to see the team members charged with system level testing joining an agile team well after the initial iterations have been completed. System level testing typically describes testing that covers scalability testing, failover testing, long-run testing, performance testing, and more. System testers tend to have a unique set of skills, so they tend to move from one project to another, always joining a project long after its start. When system testers actually do join a project, the rest of the team loses valuable time trying to get this set of contributors caught up and, more importantly, the project team misses the opportunity to have things such as scalability testing and performance testing executed early in the project when adjusting the code is much more manageable. If the system testers are not engaged early in the project, it is also harder for them to devise how best to test the software because much of the discussion and early decisions will not be known to them. Thus, system testers should be part of an agile whole team from the very beginning of a project.

One of the benefits of whole teams is that when the team discovers and solves problems together, every team member understands the context and history of the issues and resolutions. Together they gain a shared experience and build a knowledge foundation that will serve them throughout the entire project. As the team builds its working history, it improves its synergy, which allows the team to make decisions faster and even anticipate problems before they actually happen.

Cross-Geographical, Cross-Cultural, Large Teams

In enterprise application software projects, whole teams can consist of engineers from around the globe and from different cultures. Whole teams can work when team sizes are larger than the recommended 7 to 10 engineers. However, it should be no surprise that all the same principles still apply: These types of teams need to start a project together, plan their work together, and get to “Done!” each iteration together. The effort to create a whole team is even more critical in these situations but—we won’t sugarcoat it—it is much harder.

The most difficult part of cross-geographical teams usually has to do with the need for daily communication. To establish trust and ensure rich communication channels, regular communication is an imperative. The communication needs to be open, the interaction needs to be constructive, and the focus needs to be on working together to succeed. There are a couple of ways to tackle the cross-geographical problem. The most successful way is for everyone to share a bit of the “pain.” By this I mean that some team members may have to stay up late for calls with the other part of the team, or get up early, or perhaps even shift their schedules to align completely with the other part of the team. Teams can meet at different times throughout the week to “share the pain” of difficult meeting times. Some teams record their standups so that the team members separated by time-zones can understand what happened. There are many ways to make this communication successful, and teams should try a variety of mechanisms to determine what works best.

We know that this is not ideal but we encourage you to be creative, try different approaches, and keep experimenting until you find the right combination of changes that make it work for your team. However, please do not dismiss the need for regular communication (whether the team is local or geographically separated)—it’s just too important.

There are a couple of positive benefits that cross-geographically organized teams can obtain: Teams that span time zones can coordinate work so that one part of the team can start where another part leaves off at the end of their day. In addition, teams that bring different cultural behaviors together can leverage the best from multiple working styles.

Stable, Dedicated, and Protected

Whole teams are more effective when they are committed to the project for the complete duration of the project. With this approach, teams should get new team members or lose team members only on an exceptional basis. Managers and other project leaders should do everything they can to protect teams from all interruptions so that the teams can get to “Done!” (which is very, very hard to do if management acts like a “fast-forward” button, immediately passing along every interruption to the team).

Although this probably sounds like common sense, it’s not that common. Companies with multiple products typically juggle people between projects to align with changing schedules and revenue expectations. Engineers with particular knowledge or skills may get “time-shared” between various projects. People may get pulled from doing new development to manage a critical defect discovered at a customer site. And of course all teams are constantly asked to do more with less. Team churn ultimately slows down project progress. Furthermore, if team members slice their time between different projects, their lack of focus for any length of time can negatively affect their productivity and likely the quality of their work as well. The section “Maintain and Protect Dedicated Teams” discusses the evils of task-switching further, as does Chapter 4, “No Multitasking.”

Expecting team members to work on multiple projects may feel like an efficient use of personnel, but it is likely not delivering the best product in the most efficient way. “Protect the team”—this is a cornerstone principle of whole teams, thus management must have as a primary goal protecting the team. Protecting the team means that the team should be shielded from distractions to meet its project goals.

Rotating people between agile teams is a common practice in some organizations. An individual may have a particular expertise that makes him valuable to multiple teams. There are three primary problems with moving an expert around, however. First, if an expert is moved out of an agile team for an iteration, the work the expert would normally have contributed will not be picked up by the rest of the team, thus putting the team behind. Second, if an expert spends limited time on a project, he will not have the shared history enabling him to make well-informed decisions regarding his own contributions. For example, he will have to learn what technology has been developed so that he can determine what to test. This will demand valuable time from the rest of the team. Finally, it will be difficult for others to learn from the expert due to the limited time the expert has available by virtue of being pulled in multiple directions at once.

One development project that I managed included new features that required aggressive performance tuning. Our company had a skilled team to measure product performance and make tuning suggestions, but that team had little time for my project until late in the schedule. We decided to bring the performance testing work inside the scope of our team and get some of our team members skilled with the performance testing tools. This way we could test and tune early in the project as the features were developed. Educating the developers, creating the environments to test, and managing the results took extra time initially for the project. However, by doing this, we had performance information in one of the earliest iterations, and the data showed that we had problems. The team stopped further feature work until it understood and fixed the performance problems. This behavior continued throughout the project, and by the middle of the project, the team felt confident that it had discovered and fixed the most critical performance issues. Furthermore it concluded that had the problems been found later in the cycle, the root causes and the solutions would have been harder to identify. The actual fixes also would have been difficult and time-consuming to implement. This is also an example of “stop the line” thinking, which we address more in-depth in Chapter 9, “Stop the Line.”

High-performing agile teams have dedicated members and are protected by their management from interruptions and from constant changes in team membership.

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.

Overview


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.

Surveys

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.

Newsletters

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.

Security


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

Children


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

Marketing


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.

Choice/Opt-out


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.

Links


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