Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL

Part V: Maintaining the Team

Part V: Maintaining the Team

Peggy was an experienced program manager, but she was having problems with a project and was not sure how to handle some issues. This was a large multi-team TSP project with three subteams. Team A was in the application division in San Jose and team B was in the infrastructure division in San Diego. Team C, the requirements team, had members from both divisions. The leader for team C was in San Diego.

Since the members of team C had different backgrounds, locations, and management, Peggy had originally worried that they would have problems working together. However, that had not turned out to be the problem. The problem was that teams A and B were fighting with each other and were now seriously behind schedule.

Peggy discussed this problem with the leadership team. Bill, the leader of team B, suggested that they hold a team relaunch to see if that would help the teams refocus on the project goals and resolve some of the animosity that had developed. They decided to have all of the team members meet in San Diego for the relaunch.

They started the relaunch with an open management meeting at which Peggy and the leaders of teams A, B, and C described the situation and what they wanted the developers to accomplish during the relaunch. Meetings 2 (roles and goals) and 3 (development strategy) were handled as usual, but when they got to meeting 4 (overall plan), the A and B teams found that they could not make their overall plans. The problem was that the product had two principal parts—the Analyzer and the Generator—and the work for these products was split between teams A and B.

The lead coach then suggested that they form an Analyzer planning team and a Generator planning team with the members taken from teams A and B. They did this and these teams completed launch meetings 4, 5, and 6 with no trouble. For meetings 7, 8, and 9, the coach then told the developers to resume working in their old teams A, B, and C. Both the Analyzer and Generator teams refused. They said that they had worked together so well in making the plan that they did not want to return to the old team A and team B structure. The project then continued after the relaunch with three teams: Team C, the Generator team, and the Analyzer team. Each team had members in both the San Jose and San Diego laboratories, and each team had a team leader in one location and an alternate team leader in the other location.

What is most interesting about this example is that the teams worked more effectively and the team members were happier and better able to settle their issues when they were distributed between the two locations than had been the case when the teams were each in one location. The lesson of this example is that a common goal and plan are more effective than a common location for building and maintaining team spirit and cooperation. Common goals and plans are so powerful that they can overcome the communication difficulties of distributed teams.

Part V concludes the book with four chapters on developing the team, handling difficult team members, benchmarking, and being a team leader.

Chapter 15 discusses how to help your team and all of its members do truly superior work, both as individuals and as a cohesive working unit. This chapter is about teams in general and the steps you can take to address the most common questions teams have about the TSP process and how best to use it.

Chapter 16 deals with the team members’ needs, interests, and capabilities. Since a team’s performance is determined by the skills and capabilities of its members, you must develop and improve the capabilities of your people. You may also have some team members who, for whatever reason, are unable to work cooperatively with you or with the other team members. To build and maintain a productive team, you must either change the behavior of these people or get them off the team. This chapter discuss this and related issues.

Chapter 17 is about improving team performance. After your team has learned to properly use the TSP and after it is working effectively as a unit, your next concern will be improving the team’s performance. This chapter treats the team as an asset and your role in building and improving that asset’s capability to do future work.

Chapter 18 closes the book with comments on the team leader’s job and ways to make this job truly enjoyable. Being a team leader can be a great experience. Leading a team of motivated and skilled professionals while they build a complex and useful product is one of the most satisfying experiences of a developer’s life. This chapter discusses some of the more personal aspects of the team leader’s job and suggests ways to make it most rewarding for you and for all of your team members.


You are currently reading a PREVIEW of this book.


Get instant access to over $1 million worth of books and videos.


Start a Free 10-Day Trial

  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint