Agile Breakthrough Techniques to Keep You from "Waterfalling Backward": Whole Teams
This chapter is from the book
This chapter is from the book
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.”
The Mythical Man Month by Fred Brooks3
Fred Brooks is a former IBMer who came out against the idea of throwing additional bodies at projects that were running behind. In his classic work titled, The Mythical Man Month, he discusses his Brook’s Law, which reads, “Adding manpower to a late software project makes it later.” My corollary to his point is, when throwing bodies at a project that is running behind, “What one engineer can do in one week, two engineers can do in two weeks.” 
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.