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 TeamWhile 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.
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]
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]
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:
Dealing with Employer and Geographical DistributionOn 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 MemberThroughout 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.
|