Chapter 1: Whole Teams

This article is a chapter taken from the book Being Agile: Eleven Breakthrough Techniques to Keep You from "Waterfalling Backward," by Leslie Ekas and Scott Will, published Oct 21, 2013 by IBM Press.

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.

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. (Note that in some agile circles, the term “integrated teams” is used instead of “whole teams.”)

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 3. Brooks, Frederick P., The Mythical Man Month . Boston: Addison-Wesley, 1995: page 232. Print. This is a book that should be on every software engineer’s shelf. 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.

Practices- Start with Whole Teams

Agile teams are whole teams. Whole teams are created at the beginning of a project and stay together throughout the project. Whole teams consist of everyone needed to complete the planned product deliverables.

Team members each have unique skills and expertise that they use to contribute to the overall effort, but they are also expected to cross outside of their skill boundaries when required to help the rest of the team reach the iteration goals. Teams new to agile often respond to this notion with anxiety. “We cannot afford to have developers test.” “I cannot learn how to develop.” “I am not a good writer.” Team productivity will obviously increase if the entire team could do any of the tasks; however, this is not the situation for many teams. Getting to the point in which team members can contribute outside of their particular skill area takes time for most teams to achieve, and some teams never achieve the ideal given the size of their projects. Nevertheless, becoming a whole team requires team members who are willing to jump in and help in any way they can and learn new skills as they go. This might mean helping to set up computers, looking over someone’s shoulder to help find bugs, writing draft documentation, and so forth. But it does not necessarily require that everyone on the team learn the most complex aspects of each job, such as kernel-level debugging, the use of automated testing tools, or the usage of unique product documentation tools.

Teams willing to adopt a whole team approach can experience productivity growth. Furthermore, team members willing to jump into unfamiliar tasks can expand their domain knowledge and skill sets and also gain satisfaction and job growth as a consequence. And of course, they are making themselves more valuable to the team.

Maintain and Protect Dedicated Teams

Unless you’ve adopted the practice of self-organizing teams, it’s typically management’s responsibility to assign team members to a project and then protect the team. It is to management’s benefit to protect the team so that the team can get its work done and ultimately deliver the product with customer value and high quality. Protecting the team means preventing any interruptions to the work the team has committed to accomplishing in its current iteration. Furthermore, management must keep each team member focused on and committed to a single project so that team members can maximize their output.

In the real world, teams have to respond to short-term crises and shifting priorities. The easiest way to manage such challenges and continue to protect teams is to keep iterations short. And by short iterations, we mean 2 weeks maximum. It is easier to protect a team during a short iteration than a longer iteration. In fact, this is one of the many reasons iterations should be short. If a critical interruption arises, and the team is halfway through a 1- or 2-week iteration, the manager can make a better case for the team being allowed to complete its work and stay productive, rather than stopping the team and getting nothing “Done!” for the iteration. It can use its next iteration to manage the crisis because the elapsed time is relatively short. Conversely, if the iteration is as long as a month, it is easy for management to believe new work can be absorbed by the team by simply having the team “work a little harder” (which, when translated into reality, implies overtime).

Highly productive agile teams may even adopt a “no iteration” methodology based on a “pull” or a “continuous flow” model. In these scenarios the team is maintaining working software even more aggressively. As teams get better at working together as a whole team, they should consider trying these lean models.

When teams get used to getting to “Done!” in short iterations, and they reliably repeat the pattern, management has a new defensive strategy: It has the data to show that protecting the team from interruption results in higher productivity. Any situations that arise that require immediate attention are added to the top of the backlog and addressed the next iteration. This should remove the typical distractions that are less urgent than maintaining progress on the project. Shorter release cycles also help protect the team. When teams deliver “just enough” capability in a short release cycle, they can better respond to new priorities that would negatively impact longer release plans.

Whole teams can get to “Done!” better by learning how to work together leveraging their unique skills. Each team is unique and develops its own team dynamics because it is made of unique people who have their own combinations of gifts and skills. Changing the team make-up regularly by moving people around disrupts this pattern and hurts a team’s long-term effectiveness and predictability. Short release cycles also help enable dedicated teams because it is easier to keep a team together for shorter time periods.

The Conversation

The most critical aspect to succeeding as a whole team is effective communication. Communication is best achieved by interacting, or rather, by having conversations. Agile’s primary mechanisms for this necessary communication include release planning, the daily standup, iteration planning, customer demonstrations, and reflections. There are additional ways that encourage increased communication, such as making it a team rule to help each other remove blocking issues, adopting pair programming, and team creation of user stories. Whatever the mechanism, the goal is the conversation -live interaction. Conversation enables interaction while ideas are fresh. It also enables collective thinking, that is, one person’s input inspires another’s feedback. Furthermore, timely discussion with all the right people contributing (or maybe even just listening), results in faster progress. Working together enables a team to stay informed.

Teams often use documentation to communicate anything that needs to be referenced. For instance, engineers have a tradition of documenting designs, but often they do not review their designs with their team because it is written down-anyone can pick it up and read it. However, even the best writers often struggle to convey their point in written form. ((To drive this point home, Scott and I would much rather be having a live conversation with you about the topics covered in this book rather than simply having you read this book. We could cover the material in less time than it would take you to read the book and in a more comprehensive way. Additionally, you’d have the opportunity to ask questions of us and gain additional clarifications that you obviously aren’t able to do by just reading the book.)) So why do we expect that the written document will succeed in socializing the critical points that need to be conveyed? Many have heard the familiar quote from Blaise Pascal that goes like this, “I have made this letter longer than usual, only because I have not had time to make it shorter.” Constructing a message that is easy to understand takes time. Documentation is useful and should not be abandoned, but teams need to use live discussions to make sure that they are communicating and that the information is understood.

Email threads often result in failed communication. After you send an email explaining a problem to a coworker, do you think your job is done? Have you ever received a long email thread with a message from the sender saying, “How do you want to handle this?” Do you have emails sitting in your inbox that have been there more than a week? Email is a great storage repository for unfinished business. Find a way to get critical issues out of email and get them handled.

Scott has a great saying, “If a picture is worth a thousand words, then a conversation is worth a thousand emails.” Live discussions are necessary to get work completed in a timely fasion. Improving the communication at the daily standup is a great place to start. But it is hard to enable the teaming on work if you do not share enough descriptive information in the standup. Common-but frustrating-daily standup meeting comments we have heard are, “I am doing the same thing that I did yesterday,” “I am still testing,” and so on. This input is practically useless. The reason that we go through the typical standup protocol, “What I did since the last standup meeting,” “What I am going to do next,” and “What blocking issues do I have?” is to provide the opportunity to communicate about our work and help each other.

The same conclusions apply to teams that cross geographies and cultures. Everything that is important for local teams is also critical for cross-geographical teams, but communication alone may determine success or failure.

To succeed in agile, and even in your career, learn to communicate and learn to communicate well. Engage in live discussions, be willing to listen to feedback, be informative-but to the point-in your delivery, and most of all, keep trying to communicate better.

Share the Same Truth

For any team to succeed, sharing the same priorities and the same information is critical because each team member must continually make decisions. The basis for decision making for the team has to be rooted in the same priorities using all the information available. A prioritized backlog of work provides a mechanism to ensure team synchronicity, and good tooling can provide the mechanism for sharing the same information.

One of the most significant tools for keeping teams coordinated is a team dashboard or an information radiator. Good dashboard products provide a flexible way to create widgets that can integrate live data from external tools (such as separate source code management systems, separate test case repositories, separate build environments, and so on). Providing a single view of commonly viewed data gives teams a real-time view of the same “truth,” such as how many defects are active, where the latest build is deployed, what delta functionality is in the latest build, and how far along the team is on this iteration’s user stories. Several years ago, a team that I was managing-a large team that spanned the globe-started to use such a tool to coordinate our work. We quit using most other mechanisms of reporting information because our online dashboard solution encompassed all aspects of the project and did so in real time. Because the data that was displayed was live data, it was never out of date.

This dashboard capability moved our large team a lot closer to succeeding as a whole team. The Agile Manifesto calls for interaction over tools and processes, but do not discount the power of excellent tooling to help enable necessary team interaction and communication.

No Partial Credit

Whole teams get credit for the work they complete each iteration. Individuals on the team do not get partial credit for the work they accomplish during the iteration. Team members may give each other “high fives” for finishing work as they go, but agile works when teams embody the whole team spirit and succeed or fail together.

Encourage your team to avoid this kind of thinking: “I have my code written and now it’s up to the testers to finish testing while I move on to something else.” Encourage them to think instead about how to help the testers finish their work so that the team can move on together. Staying tightly coordinated to finish work enables teams to be more productive and achieve working software every iteration. The notion of “no partial credit” drives this point home. Working software is the team’s measure of progress. Having working software every iteration requires coordinated work from the whole team. They all get credit for achieving the goal.

This whole team “full credit and no partial credit” concept flies in the face of most companies’ Human Resource (HR) practice of reviewing and rewarding individuals for their accomplishments. To enable whole teams to succeed in such an HR environment, managers have to strike a balance between encouraging individuals to grow their own skills and encouraging individuals to be successful team players who encourage and help each other. Many of the best sports teams have demonstrated repeatedly that teams that work well together make it to the championships. Teams dominated by one or two individuals ultimately lose because the burden is too great for just one player or two players. Whole teams leverage the valuable skills of all the players. Team members need to set their goals around personal growth areas as well as team growth areas. These goals can naturally work together. To get to “Done!” as a team, each person should contribute to the effort using his strongest skills. But to make the team better, team members need to learn new skills so that they can help each other. When team members can help each other, they can better maintain working software, which is the measure of progress.

Offer Help

One critical aspect of whole team success is offering help. Each team member should offer to help other team members whenever needed. This may seem obvious, but it is contrary to mandates commonly practiced by development teams. Typically, individuals are instructed to get their own work completed, grow their own skills, and achieve individual feats to differentiate themselves from their peers. However, this focus on the individual has to be paired with the practice of individuals extending their time and skills to help others on the team. Teams that emerge from a traditional development culture may be unaware that their culture is not transforming successfully. They need to pay close attention to warning signs that they might be in trouble. For instance, silence should be painful if no one offers to help when a blocking issue is raised during a standup meeting. A whole team culture requires that team members get into the habit of offering help, even if they have to learn something new.

Every team has a go-to person. People usually figure out who it is and start to rely on her. The go-to person knows what the team is doing, how the code works, what the biggest issue is right now, and so forth. If that go-to person does not know the needed information, she will often start looking for it before you even finish asking. Agile’s emphasis on whole teams working together should inspire a whole team of go-to people. Go-to people are not afraid to stretch beyond their job descriptions; in fact they enjoy learning and helping teams to work together well. You may be afraid that you do not have the personality for this, but those that try tend to experience additional job satisfaction, which improves their contributions significantly.

Metrics

To validate that you have a whole team, track the team membership each iteration, beginning with the first iteration, and review it regularly. Confirm that the whole team starts together and finishes together. Yes, this may seem like a relatively simple (or even simplistic) thing to track, but if the goal is to have stable, dedicated teams, then having an indicator immediately available to confirm that this happens can be a big incentive to actually having stable, dedicated teams-especially if you need to convince others in the organization that problems with team stability are real.

As another simple metric, make a rough estimate for the time required to coordinate information across the team at the beginning of a release. Find a mechanism to share the same truth with the entire team. Use a dashboard, a common whiteboard, a wiki, an information radiator, or whatever works. Use that mechanism as a way to share information during the daily standup. Re-evaluate the time required to coordinate information across the team at the end of the several iterations. Compare the results. If significant progress was not made, or rather the time required for coordination did not decrease, try a new mechanism.

Breakthrough

Early in my experience with agile, a development team that I was managing was lucky enough to make a breakthrough with bullpens that transformed its behavior almost immediately. In fact, this breakthrough was so profound for the team that it changed my reflexive, waterfall-oriented thinking permanently. The team I was managing was having communication problems. A project consultant, Stan Rifkin, suggested we try bullpens to fix these challenges.

But let me back up and describe how we got to this recommendation. The first development team I managed that adopted agile got all the basics down quickly. Our daily standups became essential; we defined the work we planned to complete each iteration; and we demonstrated new functionality to our customers almost weekly. Despite our early success with many of the typical agile techniques, we were not working well as a whole team. Several developers would talk to each other in the hall, decide on a new development strategy, and then forget to tell the testers. An email discussing changes to how the product could be customized would go out to a part of the team, but the writers would be left off the email thread. Testers complained among themselves about the usability problems but did not bring them to the rest of the team. Tempers were mounting and disgruntled team members visited me saying, “He said this; she said that.”

I took a piece of advice Mary Poppendieck gave me during a conversation about “stop the line” thinking and identified just one problem to fix during each iteration. If we failed to find a solution to the problem, then we worked on the same problem the next iteration, and the next, and so on, until it was fixed. The team agreed that it was not a whole team. We tried everything we could think of but nothing worked. Over time the team was feeling demoralized, members were banding together to place blame, and the whole agile effort was losing ground.

Luckily we got consulting help from Stan Rifkin, a consultant with 40 years’ experience in data processing, management consulting, software engineering, and computer science. We reviewed our practices and issues with him. He suggested that we try bullpens. He explained that bullpens were multihour working meetings with the emphasis on working . Instead of meeting to discuss status, or to do planning, teams do real work together. Here are the rules for bullpens:

Everyone on the agile team MUST attend and pay attention.
Do real work together.

At first we struggled with what this actually meant. Do we write code together, do we test together, do we review documents together? In the end, it did not matter as long as we worked together and solved problems.

Interestingly enough, the majority of the team had a similar response to the suggestion, “No way!” (although a few people said, “Sounds great, let’s try it”). After listening to all the reasons we should not do it for more time than I can stand to remember, I pulled management rank and said, “We will try it beginning tomorrow.” The team grumbled off and planned for their first 2-hour bullpen.

The team floundered a bit, wondering how to start, but a tester broke the silence by talking about a set of tests that were failing. That quickly led to discussions on how the tests were run, disagreements about the expected behavior, and candid feedback about how the functionality could be more usable. With that, the team was off and running.

The first bullpen worked well. Problems were solved in real time, and the entire team learned what was going on at the same time. The team proceeded to schedule multiple bullpens weekly. Because the entire team was not in the same room, let alone the same country, we had to do this over the phone and with an emeeting-sort of “virtually sitting next to each other.” Adopting bullpens had the added benefit that when the team was not in a bullpen, it could get more focused time to work because most of the issues requiring cross-team communication had already been addressed.

Bullpens became so successful that the team started to use them for a variety of purposes. They had bullpens to jointly review code, discuss and solve difficult technology problems, code bash as a team, and more. We observed these positive outcomes: First, the team became a whole team. Accusations ceased and productivity increased. Second, the amount of email in my inbox dropped in size significantly. The team solved problems in real time with the whole team involved, so no additional communication was required.

Small agile teams that work in the same room usually develop a bullpen behavior simply based on their proximity. These may be called team rooms. Teams not residing in the same location can get similar value from bullpens. One advantage of bullpens over team rooms is that with bullpens, the rule is that everyone must attend, and it also leaves nonbullpen time to get focused work done that is less likely to be interrupted.

The story at the beginning of this chapter about the user interface design point that the tester disliked resulted from one of the first bullpens that I attended. The success of the meeting was stunning to everyone in the meeting. It forever changed our team dynamics and we were hooked.

When a team becomes a whole team, the team starts to think in a more agile way. When teams share the ownership of problems and their resolution, they can move faster together, leveraging everyone’s collective strengths. Most whole teams have more fun working this way and certainly experience higher productivity.

Summary