Coalescing into a Team

Gary often repeats a saying commonly used when talking about organizations ”that teams "form, storm , and perform." We did assemble the team fairly quickly. But forming the team took a while.

Forming the Team

While working at Rational, we'd all become acquainted with each other. Some of us had worked on small, informal projects together or talked to each other in the course of our work. ^[1] Some of us worked together on major projects. But we had never before all worked together as part of a team; it turned out that getting to know each other ”our work styles, strengths, and weaknesses ”took some time, more than we had anticipated.

^[1] Chris and Jas, for example, have talked on the phone, but have yet to meet face-to-face.

We originally thought we could settle into working as a team fairly quickly; we just needed to decide what to build, assign tasks to team members , and wait for the software to be written. This plan seemed straightforward enough ”what barriers could we possibly run into?

When we tried to work together, we found that we really didn't know each other very well at all. We thought we understood each other's abilities and strengths. We assumed that we were each making the same commitment to the project and that we would each be able to act on our commitment. It was not long before reality hit.

We all had good intentions. But we also each had a full-time job and other responsibilities in our lives. In this respect, the PSP Tools project was similar to an open -source project: We were a team of volunteers and we had to respect each other's ability to offer different amounts of time to the project.

When we describe our project, people say that it sounds like an open-source project. In some ways it is, but we think there are many active projects in large organizations that are similar to ours. In fact, there are probably more than you might realize. We see project teams forming and re-forming all the time. The practice of " borrowing " someone from another project for a short time is not uncommon. Managers frequently ask their developers to fit in some small project along with larger projects. All too often, this is done with the suggestion that the smaller project "should not take away from the rest of the work the employees are responsible for." ^[2]

^[2] Sometimes a team is formed for a short project that is critical to the organization. These teams are called by different names , such as SWAT teams or Tiger teams, to indicate their urgency.

We also had to learn to say no in response to requests . There were times when it was important to decline a request because we lacked expertise or time. In the beginning of the project, though, we each resisted saying no because we felt that we'd be letting the team down.

Of course, by accepting an assignment that we were unable to complete, we still let the team down. The team members were not disciplined about demanding results by the promised dates. As a result, we had to become more effective managers of our individual schedules and workload.

As an experiment, we tried working with well-formed requests ^[3] (described in Chapter 3), but soon dropped the practice. Looking back, we were all just as eager to accept well-formed requests as we were to acceptcasual requests, with the same frustrating results. Using well-formed requests did not make it any easier to decline tasks. ^[4]

^[3] Well-formed requests are also called "precision requests." They are a way for a team to communicate precisely what needs to be done, who should do it, and by when. When they are used effectively, they can help a team work in a highly productive manner.

^[4] See The Phoenix Agenda by John Whiteside.

We went into the project believing that we could all get started working right away. In retrospect, we realize that we should have held one or two daylong meetings to initiate the project. We were able to justify omitting the meetings because we were a small team. But by trying to save time in the beginning, we ultimately wasted a lot of time in the long run.

On our next project, we'd organize meetings to discuss the nature of the work and the organization of the team, including the following topics:

• Introductions: Who are you? What is your background? What are your interests at work? What are you good at doing? What new area do you want experience in?

• Moving toward a vision: What are the goals of the project? Can the team produce at least a draft of the team's goals? Who volunteers to polish the draft and send it out for review?

• Matching the team to the project: What roles are needed on the project? By examining experience and interest, who is best suited for each role? What are the first deliverables for each role, and when are they due?

• Establishing ownership of work: How will we assign work? How does a team member either accept the work or decline it? How do team members support each other?

• Next steps: Review deliverables; decide how the team will communicate; schedule next meeting.

Dealing with Employer and Geographical Distribution

On a typical small team, the team members work for the same company in the same location. This was not the case for us. Most of us work in the same town, but one team member lives 3,000 miles away. Another team member travels frequently, and the three of us who do work in the same town work in different buildings that are walking distance apart.

Originally, we all worked for the same company. Part way through the project, Jas left the company but wanted to continue working on this project. We had anticipated several risks but did not anticipate this one. One effect of this change was that we lost our comfortable way of communicating. We no longer all shared the same intranet, so we could no longer share calendars, use a common network location for files, or even have access to the same set of tools. We had to find other ways of staying in touch. And we needed to figure out how to continue to work together effectively.

Throughout the rest of the book we return to the topic of our geographical distribution and the problems it caused. This practice is becoming increasingly common, and with more companies encouraging telecommuting and distributed teams, it is sometimes even normal. The main difference between a distributed project in one company and our project is our lack of a common intranet for sharing our tools and data. Solutions exist today that address the intranet problems, and we mention some of them in the final chapter. Although the common intranet problem can be addressed by technology, most other problems are not solved by technology. They are solved by team members who pay attention to people issues.

Most team members enjoy the informality of being able to communicate by talking over the cubicle wall. We had to teach ourselves to pick up the phone and call each other, to have regular meetings, and to use tools to facilitate our communication.

Losing a Member

Throughout most of the book, we talk about our four-member team. For a while, though, we had a fifth member, whom we will call "John." John left the team partway through the project, shortly after we began our Inception phase. What happened ? We discuss it here, rather than in the Inception chapter, because it is a team issue, not an Inception topic.

Gary asked John to be the architect. Although John had limited experience in that area, and felt that he wasn't ready for the role, he reluctantly agreed to give it a try. Gary attempted to coach John by urging him to design the simplest thing that could work while keeping in mind future changes, but John seemed to be bogged down by "analysis paralysis." It appeared to the rest of us that John was afraid to do something wrong, so it was very hard for him to get started.

Because none of us were database experts, we identified the design of the database as one of our most important technology risks. We were all concerned about our ability to create a working database application. John had the most experience with databases and he wanted to tackle our database design. This was a good fit for the architect.

During this period we entered into a long cycle. John had difficulty getting started with the database design. He felt that he would fail us if he could not deliver. Most likely, his fears caused him to work slowly and carefully . The team wanted to support John and not pressure him. Our lack of feedback caused John to spend even more time perfecting the design. In retrospect, Gary says that he should have taken more of a leadership role to support John, and also to establish stronger expectations.

And then, John's commitments in his work and his personal life interfered with his ability to deliver work to this project. At the same time, it was hard for John to leave this project because he felt that we were depending on him and he would be letting us down.

We learned and re-learned many lessons on this most human part of the project.

• Listen to the team . When a team member says they're not ready to step into a particular role, the manager needs to make a delicate decision ”does the team member need to be encouraged to grow into the role or should the manager listen to the team member's response? For a long time, we erred by wishing John into this role, and perhaps by not coaching him enough. In the future, we'll know to be better listeners in this area, and perhaps to be better coaches, but we don't know if we'll have a happier outcome. This is one of the hardest areas of management.

• Become an effective coach . During our regular meetings, we'd ask John to produce a piece of work, and he'd say that he'd try. Because we were asking him to work in unfamiliar territory, we could have helped him succeed by having another team member work with him outside of the team meetings. In retrospect, we wish we had tried to use a pairing technique. ^[5] John worked and lived near other team members, so it would have been relatively easy to arrange times to work with him. In a similar technique, a coach works with a team member to produce a piece of the work together. Together, they create and review the work and produce another piece. By breaking the work down into smaller pieces, the coach can help the learner understand what it means to do this new work ”in this case, to create an architecture. For more about this, see the sidebar discussion of Couch, Mentor, Guru, Companion.

  ^[5] In a pairing technique, two teammates work together on a specific activity. The most popular pairing method today is pair programming , described in Appendix C.

• Allow a team member to leave gracefully . John felt torn between commitments he had made to the team and his personal commitments. We believed John when he said he would perform project tasks, and we held up the project waiting for him to deliver the work. It was hard for him to say no, and it was hard for him to come to the conclusion that he needed to step away from the project in order for us to make progress. We could have helped more by intervening earlier, instead of relying on him to resign; we should have made this a team decision rather than placing the onus solely on John.

Coach, Mentor, Guru, Companion

We feel it is important to have one or more people who act in an advisory role to the team. These people are known by different names, such as coach or mentor, but they all serve the same purpose ”to help the team function better as a team. Regardless of what you call these people, we recommend that you identify them and enlist them to help your team as early as possible.

We prefer the term companion to describe these people. Many spiritual traditions have the notion of a companion. This is a person who walks with you on part of your journey. The companion has been on this path and knows some of the pitfalls and stopping points along the way. Every path is different, but many are similar. The companion walks with you as long as your paths converge. At some point, your paths diverge and you bid farewell to each other.

The companion on a software development project serves a similar purpose to a spiritual companion. The companion has participated on projects in the same domain, technology sphere, or other area that is common to yours. The companion has learned some of the pitfalls and obstacles you will most likely encounter. The companion can talk about the experiences and relate them to what your team will experience.

The purpose of the companion is not to tell you how to do your job. It is likely that when you expect the companion to give you an answer, no answer is forthcoming. The purpose of the companion is to help you find your own answers and take charge of your own destiny. This is the only way your team can grow and develop its own unique culture.

Who Are Companions?

Companions can come from anywhere . You might discover an excellent companion who is already a member of your team. In organizations where work occurs simultaneously on multiple projects, you might enlist someone from another team. Or, consider hiring a consultant to help your team. We think the best consultants help your team grow and then leave, as compared to consultants who join a team, become the all-knowing oracle, and then perpetuate their own role from project to project.

Wherever you find them, companions need to gain the team's trust. The team must feel comfortable going to the companion with any type of problem and the companion must be a good listener. The companion shares his or her experiences, relating them to the team's current context, and the team takes the experiences and applies them as they see fit.

Look for people you can employ as companions for your team. Engage them to walk with your team on part of the journey that you call your project. Use them as sounding boards and learn from their experiences. When the time is right, thank them for joining you and wish them well as your paths diverge. When you have had a companion, you will look back on the experience and realize that the time spent with him or her was invaluable to your growth as an individual or as a team.