People

Let's get something clear: Software development is intrinsically a human activity. People are the most important factor for the success of your project! In fact, people make the difference between success and failure for most team-based endeavors. ^[1]

^[1] We originally talked about people being the most important "resource" for your project. When we reviewed this chapter, Chris pointed out that speaking of people as resources takes away the real importance of people. We all agreed. Changing the names of departments from "personnel" to "human resources" has helped add to the dehumanization of the workplace.

There are many books about effective management, including books that are specific to software project management. See the Recommended Reading list at the end of the book for some of our favorites. If you are a software project manager or program manager, these books are great resources for you. We will not address management issues in detail in this book. We spend most of the chapter, however, talking about people. The rest of the book provides details about how we used process and tools on our project. Whether you are a project manager or an individual contributor on your team, you should read this section and consider how your current project team operates.

Harry and Gwen

We introduce this section on people with a short story. You may have heard about or experienced a similar situation, yourself. We assure you that this is a true story that one of our team members lived through.

People can affect a project's success. This story about two smart senior engineers on a five-person project happened a few years ago. There was a critical part of the system that needed to be written before we could move on. The first programmer, Harry, ^[2] took it upon himself to write this bit of code. Because Harry was the project leader he felt this was his right. Gwen, the other programmer, thought she had a better solution, but couldn't convince Harry. One day Harry wrote some code. That night Gwen checked Harry's code out and rewrote it to do things her way. The next day Harry saw the changes and changed the code back ”after having some choice words with Gwen. That night Gwen changed it back to embody her solution. This pattern went on for a couple of weeks. This was bad for the project because it delayed getting some critical code complete. What was worse , was that each time Harry or Gwen changed the code, they broke the system for the rest of us on the team.

^[2] As you would expect, the names have been changed to protect the innocent and guilty.

Egos and technical reputation came first for Harry and Gwen and the project and team came in a distant second. As you might expect, this project was never completed and it was cancelled without ever delivering a release to the customer. With a slight change in the personnel mix on the project and better management of the personal characteristics of the team, we might have been successful. At least we would have had a better chance.

It's About Communication

At Rational Software, we use the tag line "Software development is a team sport" to describe an approach to software development. As a company, we build tools to help teams . However, the key to success is recognizing that it takes a team to build software, not just a group of individuals with different agendas and different values. Getting the people on your team to work effectively is mainly an issue of establishing good communication between the team members. This leads to trust and respect, which are also necessary people ingredients .

Once two or more people are working on the same project, you have to deal with people issues. Great managers are the ones who enable the people on their team to work most effectively together. Being a great manager is hard work. It's more than just giving your team pizza and great T-shirts ”it's helping them to respect each other's abilities , work off each other's strengths, and help them work effectively as a team.

There are some simple people-oriented project guidelines we recommend you consider for any project, especially small projects. The guidelines might seem most appropriate for project leaders to consider, but all team members should look at their project team in light of the guidelines. The guidelines may seem obvious, but we feel they are worth stating explicitly. The following sections present each of these guidelines.

Team Composition

How do you put together a good team? You want people who can get the job done. Does this mean that you need a team of superstars? Not necessarily . The sports world provides examples of teams that have the highest payrolls, the biggest stars, yet end up out of the running for the championship year after year. And, of course, the coach is the one who gets the blame.

Some teams don't have any proven superstars but somehow manage to put things together and come in first. This admittedly doesn't happen often, but we love the stories where the underdog overcomes the odds to become the champion. These stories inspire us and enable us to dream of glory .

The great teams ”the really great teams ”are more than a collection of superstars. The great teams have a mix of superstars, talented rookies, role players, great coaches, and a great organization. Furthermore, the winning teams keep improving. Teams in business, especially software development teams, are no different than sports teams. Let's look at what we mean.

In software we have superstars. Some of them are great coders who can just sit down, start typing, and produce perfect code. Some are great architects who can understand complex problems and design the right solution. Some are great testers who are able to quickly identify defects and help the developers build better software. Each makes a contribution to the success of the team.

Our experience has been that a software team composed of just superstars cannot be effective for an extended period. There are several reasons for this. The main reason is that egos clash . Regardless of how well people "play well together," there are times when they don't. The Harry and Gwen story earlier in this chapter is an example of this. Experienced programmers have earned their reputations for technical acumen . They like to be the ones doing the hard technical work. They want to have others do the uninteresting work.

Product Guideline 1 deals with the composition of the team. It is no easy task to put together a team that has the right mix of skills and experience. As the team forms, make sure that:

• There are senior team members who can lead and teach the more junior members

• The senior members have experience with projects similar to your current project

• The team possesses technical expertise for the most critical aspects of the project

Project Guideline 1 Get the right mix of people on your project

Staff your project with people possessing different skills and experience so they complement each other.

For example, consider beginning a project to develop a new Web site for a company. The site must present the company's catalog to the customer and allow the customer to place orders and enter credit card information. Would you trust this project to a group of engineers just out of school? They may know the basic technologies involved, but they would lack experience in the business aspects of your system. You would make sure that you had one or more experienced engineers familiar with your company's business systems and data assets. You would support them with other, possibly junior, engineers who could provide general programming and technology capabilities.

Provide a Learning Environment

Software developers get excited about solving problems and learning new things. One of the worst fates for a programmer is to implement a system where there are no challenges to meet or new technologies to learn. Maintaining a technical edge is the same as maintaining a competitive edge for software developers.

The most desirable companies for programmers to work in are those that provide a learning environment. Programmers will often join a company because they are promised the opportunity to work on something new. You can make part of your project a learning environment by making sure that everyone on the project has the opportunity to learn. Experienced developers can learn new technologies. Less experienced team members can learn about how software is built from the more senior people.

Project Guideline 2 addresses learning on the project. We recommend that you ensure that there is something to be learned by every member of the team. When you consider the possibilities for learning, it can help you decide which people are most appropriate for your team.

Project Guideline 2 Provide a learning environment

Make sure that every team member has the opportunity to learn on the project. Things to learn can be technical, organizational, or managerial .

There is a hidden trap in this guideline. Sometimes people get so involved in learning that they fail to deliver the product. Project managers need to be alert for the team members who spend all their time learning and forget the primary goal, to deliver working software to the customer.

There are times when a team member does not want to learn anything new on a project. That person has different motivations for joining the team. Project managers should not force everyone to have a learning goal. In general, a project team where people want to learn is more robust than one where people are just trying to get through the project, but there are times when we all want to just do a good job and send the learning parts of our brains on vacation.

Trust, the Glue for the Team

In his excellent book The Phoenix Agenda , John Whiteside presents a twelve-step approach to empowering teams. The most important one, in our opinion, is to generate trust. A lack of trust between team members can quickly cause a project to deteriorate to the point where there is little chance for success. The example cited earlier about Harry and Gwen is an example of a lack of trust. Neither engineer trusted the other one.

People often misunderstand what we mean when we talk about trust. Trusting your teammates doesn't mean, for example, that you give a new programmer a critical task, requiring technical skills the programmer doesn't have, and trust they will get the job done correctly. It means that you trust programmers to tell you they are not qualified, or they need help. It means that when they accept tasks , you trust them to do the job right. You trust that they will ask for help if they need it. You trust that the team will provide help when asked (see Project Guideline 3).

Project Guideline 3 Generate trust

Generate trust on the team. Help the team members trust and respect each other.

One of the best stories about trust and teams was told by Susan Butcher, the four-time winner of the Iditarod dog sled race in Alaska. Susan was the guest speaker at the 2001 Rational Users Conference in Denver, Colorado. Susan told of the time when she was out on the trail over a frozen body of water. Her lead dog kept turning to the right, off the trail. She kept demanding that the dog come back on course. This went on for some time until Susan just gave up and let the dog lead. Almost as soon as the dog took the team off the course, the ground where they were heading collapsed into the freezing water ”certain death for Susan and the dogs. The words of wisdom Susan gave to us about this incident were: "Sometimes you have to lead, and sometimes you have to let the team lead." What she was really saying is that you have to trust your team.

Disagree Constructively

Some people think that a high- powered team is one that doesn't disagree. Experience has shown us that this is false. Most of the effective teams we have worked with have had significant disagreements between team members about how things should be done. This has, in fact, led to solutions better than any individual had proposed. Healthy disagreement provides the team with a synergy.

Disagreement is good. But when disagreement gets personal and is allowed to get out of hand, it destroys a team. Effective teams are those that have established a way for team members to disagree constructively. They provide a forum for dialog and exploration as well as a way of resolving disagreements. If team members trust each other, disagreements are easy to deal with. People express their opinions , you trust that they are concerned about the team's success, and you work on an agreement. Even if you can't work out an agreement, you have a way of deciding on a course of action and everyone gets behind it.

Project Guideline 4 Allow disagreement

Allow team members to disagree. Provide a way to resolve disagreements.

We can look once again at sports teams for examples of how to handle disagreements. Each team member has some ideas about how best to win. In basketball , the high-scoring shooters want an offensive game where they will pump in basket after basket , not worrying about the other team's score. They are confident that they can meet any challenge by shooting more. This "run-and-gun" style can be effective in many, but not all, cases. There are times when you need to control the ball and slow down the game's pace. You then give the ball to your best ball handlers and put in defensive players who can steal the ball from the opponent and block shots. The coach has the responsibility for assembling a game plan and motivating the team to execute to the plan. The coach also has the responsibility to alter the plan when opportunities arise, or when the existing plan is not working. If a player notices that a defenseman on the other team is playing in a way that allows him to shoot for easy baskets , he tells the coach. The coach makes the final decision. If the situation requires more immediate attention, the team communicates on the floor and adjusts as necessary. Often, a team captain makes the final decision.

The Power of Requests

What motivates you more: when someone demands or requests something from you? Everyone prefers a request to an order. Requests are the topic of Project Guideline 5.

Project Guideline 5 Ask, don't demand

Make requests, not demands.

When we say that you should make a request, we don't just mean any type of request. Make a well- formed request . Gary learned about well-formed requests from John Whiteside when John was Gary's mentor on a project at Digital Equipment Corporation. John calls this type of request a precision request in his book referenced earlier in this chapter. ^[3]

^[3] Chapter 6 in The Phoenix Agenda .

A well-formed request has certain attributes:

• It says what needs to be done.

• It says when it needs to be completed.

• It says who should perform the work.

• When appropriate, it states where the work will be performed.

Let's look at two examples of requests. Which is well-formed, and which isn't?

1. "Liz, will you review the Vision document and produce the first draft of the Glossary based upon the domain-specific words in the Vision? Can you send me the draft of the Glossary by noon on Friday?"

2. "Gary, we need to see some results on the architecture soon."

Clearly, the first request is well-formed. It identifies what needs to be done, a Glossary based upon the Vision document. It states who should do the work, Liz. It states when the work is needed, noon on Friday.

The second request is very vague. The only attribute of the well-formed request that it contains is the name of the person. It does not qualify as a well-formed request at all.

There is one other type of statement you should avoid when you are making well-formed requests. Consider the following statement: "John, have your code ready to go by Monday morning. "

This is not a request at all. It is a demand. Demands are ineffective . They often have the opposite effect of what you want. People do not react well to demands. They feel they have no control of their own destiny. Remember one thing about well-formed requests: It isn't a request if they can't say no! This is important. If you make a demand, you do not allow the other person to give an honest response if they cannot meet the demand. If you follow Project Guideline 3, Generate Trust, you need to trust your teammates to tell you honestly whether they can do the work you request. If they cannot meet your requirements, then you can negotiate a different delivery time, ask someone else, or decide upon a different set of deliverables. If you do not have an environment of trust on your team, these negotiations are impossible .

There is another benefit of using requests. By accepting a request, a person takes ownership. If someone asks you to do something, and you agree, you have a feeling of responsibility to deliver what you promised. If someone tells you that you must deliver something by a certain time, you have no ownership. The task may be impossible. You may have already scheduled a day out with your family. There are any number of reasons why the work may not be done by the specified time. If you are not able to freely agree to deliver the work, you will not take ownership. If you are free to accept or reject the work, you will do whatever it takes to meet your commitments.

It takes practice to make well-formed requests. This is time well spent. Whiteside presents data showing that the number of requests satisfied is approximately constant. This means that a team with an 80% completion rate satisfies 8 in a week that 10 well-formed requests are made, and 40 in a week that 50 are made. This leads to the obvious conclusion that Whiteside states: "To increase your productivity, increase the number of precision [well-formed] requests you make." Clearly, there is a limit to the amount of work that any team can do. When you use well-formed requests, you tend to converge on an optimal request rate for the team.

If you decide to use well-formed requests on your team, set up a simple system to track requests. You can do this with a simple text file or spreadsheet. You might try something more sophisticated, but it is not necessary. Tracking requests allows you to see how well the team is doing with well-formed requests and if there are any problems on the team.

Recognize Achievement

How do you feel when someone says "Thank you?" Most people feel good, as long as they feel the thanks are sincere. They know they have been recognized for something they said or did for someone. One of the most important skills you can develop as a member of a team is the skill of saying thanks; or to put it differently, the skill of recognizing achievement. This is Project Guideline 6.

Project Guideline 6 Recognize achievement

Recognize achievement ”sincerely and often.

Sometimes you need to be creative about recognizing achievements. Some people are uncomfortable when they are publicly recognized. You may have to deliver the kudos privately. That's okay. The important thing is that you say thanks and you are sincere about it.

You can overdo recognition. When recognition is not sincere, or it is done habitually for day-to-day accomplishments, it loses its effect. You should say thanks for people doing their job well, even if there are no outstanding achievements or hurdles they have overcome . Just don't do it every day. If you went to work every day and your manager greeted you with "Thank you for the work you did yesterday ," how long would it mean something to you? Not very long.

Another example of overdoing recognition can be seen in many companies today. These companies provide different "benefits" to their employees , for example, free lunches, popcorn, pizza, soft drinks, T-shirts, and so on. People feel good about getting these things. However, " familiarity breeds contempt." After a while, people begin to comment that their favorite drink isn't provided, the T-shirts are the wrong color , and a litany of other complaints. What was originally meant to be a way of saying thank you becomes an annoyance.

Be careful and creative about how you thank your team. Make it special. One of the simplest, most special ways is a heartfelt "Thank you."