This chapter is from the book
This chapter is from the book
This chapter is from the book
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.4 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.