Teams

Our children were competitive swimmers when they were in high school. For almost a decade our son's name was on the record board at the high school swimming pool until someone finally swam the backstroke faster and replaced him. We liked swimming as a sport because our son and daughter, three years apart in age, were in the same swimming club. They practiced together, went to meets together, and developed a mutual language and mutual respect. The sport demanded discipline and helped them develop good habits. But swimming didn't really teach them a lot about teamwork.

The difference between individual sports and team sports is fairly clear. In individual sports, contestants win or lose based on their individual abilities. In team sports, the entire team wins or loses together based on the team members' ability to work together. When our son was in college he was the coxswain of a crew team. He sat in the back of a long narrow boat synchronizing the efforts of eight hefty rowers as they sped down the water. Rowing is clearly a team sport.

We might call diving and gymnastics team sports because individual scores are totaled to a team score. But that's not the same as basketball or soccer, where team members have to synchronize their efforts in order to perform. We should keep the same distinction in mind with work teams. People who work side by side are not necessarily a team, even when they sum up their individual efforts into a collective result. A work group becomes a team when the members hold themselves mutually accountable to produce a "collective work product."^[8]

^[8] See The Wisdom of Teams, by Jon R. Katzenbach and Douglas K. Smith, Harvard Business School Press, 1992.

There is nothing wrong with individual sports, they're simply different than team sports. And there is nothing wrong with work groups, but they are different than teams. Putting a group of people together and calling them a team doesn't make them a team. The thing that turns a group into a team is the mutual commitment of the members to pool their various skills and work together for a common purpose.

What Makes a Team?

What got our son up early every morning to coast his bike down the steep Ithaca hill to the Cornell University boat house? After all, the bike ride back up the hill was punishing. But the team had races to win, and to win races they had to work hard every day to learn to synchronize their efforts so that they could row faster and smarter than the teams from other schools. If anyone didn't show up, or didn't put out his best effort, the team wouldn't make the progress it needed to make in order to win races.

Creating good software is a lot more like rowing than swimming. Software development involves constant problem solving; people make complex decisions many times a day, often with implications far beyond their own work. Pooling skill and knowledge from many different perspectives is critical to excellent results.

Teams need a challenge, a common goal, and a mutual commitment to work together to meet the goal. Team members depend upon each other, and help each other out. A wise organization will focus its attention, training, and resources on creating an environment where teams are challenged by their work and engaged with their teammates in doing the best job they can.

A group or a team?

1. At the morning meeting everyone reports on what they have done in the last day. After each report the project manager says "Great, Joe, today I'd like you to...." Everyone leaves with their assignments for the day.

   This is a group. By assigning work, the project manager has taken over the responsibility of making sure that everything gets done. Team members have not mutually committed to accomplishing the project goal.

2. At the morning meeting everyone reports on what they have done in the last day, what they expect to do today, and where they need help. Sanjiv reminds everyone that a tough feature is still waiting to be tackled by saying, "If someone doesn't get at that, I'm afraid it won't get done in time. I would do it," Sanjiv continues, "but I really have to solve this other problem first."

   In response, Mike says, "That's probably more important than what I'm working on, but it's not an area I'm good at."

   Sanjiv offers to take a couple of hours to get Mike started.

   Next, the ScrumMaster notes that the team is struggling with an interface to the firmware. She asks if it might help if she rounds up someone from the firmware team to meet with a couple of people that afternoon. Three developers jump on the opportunity.

   This is a team. The meeting is focused on figuring out how to reach the goal they have jointly agreed to meet. The ScrumMaster focuses on helping where the team needs assistance.

But it's not so easy....

1. I tried the team approach, but I can't get the team to take the iteration goals seriously. They punch the clock and go home at the end of the day. At the end of an iteration, the work the team supposedly committed to is not done, and no one really cares.

   You get what you expect and what you inspect. Do the immediate supervisors of the team members consistently expect the team members to commit to team goals and deliver on those commitments? What is their reaction when commitments are not met? When evaluation time comes along, what will be rewardedindividual accomplishments or contributions to the team that help it meet its goals? When the expectation and measurement system of the organization promotes individualism over teamwork, it is almost impossible to sustain healthy teamwork over time.

2. We have a computer system that assigns projects to teams. You work with one team for a few months, then another and another. It's really hard to get people to commit to a common objective.

   Indeed, you aren't going to have teams in an environment that keeps reshuffling people; you have continually reforming groups. An occasional group may become a team, but after they get split up, they rarely bring the team spirit to the next group.

3. In my organization, we have a ranking system. Everyone needs to hand to their supervisor all the ammunition possible to get the highest rank. Helping other people out on the team doesn't show up on the ranking system, and worse, the other guy gets credit for my good ideas.

   As long as you have an individual ranking system or an individual bonus system, you may as well forget about teams. Do the best you can with work groups.

4. People would like to commit to team goals, but they are working on five teams at a time. They never know when an emergency is going to arise on another team, and after a while they just get burned out.

   We are sure that our son would never have been a top swimmer in high school or a top coxswain in college if he had tried to compete in more than one sport at a time. He had two prioritiestop grades first, top athlete second. That's about the maximum number of commitments that anyone can honestly make at one time. People can be members of five groups at a time, but only oneor maybe twoteams.

Expertise

A crew boat is narrow, goes fast, turns slowly, and tips easily. A crew team has to concentrate hard on working together just to stay dry. Racing in water is all about current, wind, drag, and strategy. Consistently synchronized power is essential in order to keep the boat motion smooth and conserve energy for the final push. To win races, the rowers must first of all be excellent athletes, and secondly, they have to focus on synchronizing their efforts with their teammates every time they work out. It takes many workouts for powerful athletes to develop into excellent rowers.

Toyota believes that consistent excellence in product development starts with "towering technical competence in all engineers."^[9] And the company does not think that such competence is learned in college; it is developed over timeseveral yearswith experience and mentoring. Toyota starts by sending new engineers to automobile plants to make cars. Then they work in dealerships for a few months, selling cars and talking to customers. After about a half a year, new engineers are assigned to a department to work under the guidance of a senior engineer. The first thing they do is a "freshman project"an improvement project which provides a challenge and teaches the engineer Toyota's approach constant improvement. At the end of a year or so, new engineers start a rigorous, two year, on-the-job-training program in which they acquire a standard set of skills. Only then do they move up to entry level engineer and begin to be a serious team contributor. After this initial period, an engineer can expect to spend five or six years within the same specialty before being considered a first-rate engineer.

^[9] James Morgan and Jeffrey Liker, The Toyota Product Development System: Integrating People, Process, and Technology, Productivity Press, 2006. See Chapter 9.

The Bell Curve

1. We have hundreds of developers. When you have that many people, their expertise falls along the bell curvesome are excellent, some are average, some are below average.

   We believe that when an organization sets out to do so, it can consistently turn "ordinary people" into excellent contributors. The place to start is to make it the top priority of every manager to develop the capabilities of the people for whom they are responsible. At Toyota, "Developing people is fundamental to the manager's job. All managers view the performance of their teams as a direct reflection of their own ability. It is personal."^[10]

^[10] James Morgan and Jeffrey Liker, The Toyota Product Development System: Integrating People, Process, and Technology, Productivity Press, 2006, p. 169.

Excellent software products start with highly competent technical experts in many areasarchitecture, object-oriented technologies, coding strategies, data structures, test automation. This is not a function of the methodology used for development; behind every excellent product, no matter how it was developed, you will find excellent technical people. In lean development, we acknowledge this fact and focus organizational policies on hiring and developing such experts.

A development team should have among its members the expertise necessary to meet its goals. Team members should mutually commit to specific team goals, and reliably achieve those goals by working together, pooling their expertise, and helping each other out whenever necessary. It is easier to help each other out when there are multiskilled people on the team. As development progresses, there may be more need for testing and less for development, or more need for user interface coding rather than database work. Developers can help testers, user interaction designers can test user interactions, junior members can pair up with more experienced team members to help out and learn new skills. Every person on the team is first of all a member of the team, and second a specialist in some particular discipline. No one on the team gets credit for being done until all the work the team committed to is done, so everyone pitches in however they are able.

Specialists

1. Our team always gets hung up because the technical writers are all working on several projects at a time. User documentation is a critical part of our product, but the technical writers just can't keep up with the team, what with all their other work.

   Technical writers, as well as people with other critical specialties, need to be part of the team from the beginning. It's almost impossible for a person to really contribute to more than two teams at a time, and one team is much better. Yet there might not be enough work for technical writing to do at all stages of a development project.

   There are several remediesthe one you choose will depend on your situation. One approach might be to broaden the role of technical writers and get them involved in the design of the product. Perhaps they can help with user interaction designs or write user stories or use cases, since technical writers have to have a good understanding of the way users think. Technical writers might also help in testing, or they might write any necessary technical documentation as well as the user documentation.

   A second approach could be to rethink the way in which technical writing is done. New methods such as the Darwin Information Typing Architecture (DITA), which is essentially a technique for creating documentation incrementally and making it more reusable, can allow technical writers to spread out their work more evenly over the development cycle.^[11]

   Or perhaps someone else might take a first crack at user documentation as an assistant to the technical writer. For example, people from the technical support team know exactly how users struggle with the system and its documentation, so they make great team members who have a good idea of what kind of documentation users need.

2. We have silos in our company. For example, the graphics designers get much more esteem from designing a great screen than from getting it working with the rest of the system. The security people have their own silo, and they are paranoid about us writing any code at all.

   Silos are a pretty good indication that there are measurements and rewards at a functional level that encourage functional optimization at the expense of the overall system. This is most common in large organizations where it is difficult to see how to optimize the whole, so functional optimization is substituted instead. A possible remedy is use a value stream map to demonstrate how functional measurements are at odds with the overall good of the value stream. Substituting value stream cycle time for functional measurements can do a lot to promote cooperation between functions.

3. We are having a problem bringing junior people up to speed. We have teams of senior people working on the most critical projects, while the junior people work in other areas.

   Teams should have a mix of skills. Teams with all-senior people lack anyone to do the "grunt" work, have no one to bring a fresh perspective, and the experienced people are not passing on their skills to the broader company. Teams with all-junior members have to reinvent too many wheels, have no sense of the patterns that work in the business, and generally lack a high-level view of the problem. Mix skill levels as well as skill sets.

^[11] The OASIS standards organization approved DITA in June of 2005. DITA is an XML-based standard and a set of design principles for creating "information-typed" modules at a topic level. DITA aims to deliver content from a single repository directly to the point-of-use.

Leadership

During a race, a team of eight rowers needs a coxswain to focus on hydrodynamics, aerodynamics, and race strategy. The coxswain should be smart, confident, quick thinking, and weigh as little as possible. A coxswain is the "on-board" leader of a crew team, keeping the rowers focused on applying consistent, synchronized power so the boat glides smoothly through the water and air. During a race, the coxswain's job is to read the weather, the course, and the competition, to make quick decisions, to steer the boat, and to keep the rowers' effort paced so they have both a good position and enough reserve for the final sprint to beat the other boats across the line.

A large team without leadership is like a crew team without a coxswain. The team can perhaps go fast in the right direction, but it is unlikely to apply synchronized power and make the subtle course corrections that create a winning product. Toyota operates from the basic principle that teamwork is essential, but someone always needs to be responsible.^[12] We concur. All too often we find that "Everybody's job is nobody's job." In Chapter 3 we discussed the importance of a champion who brings to a development team a deep understanding of the market need and the technology that can meet that need in a unique way. The question we address now is this: Does a development team also need a process leader? How many leaders does a team really need, and what are the appropriate roles?

^[12] Jeffrey Liker and James Morgan, Ibid., p. 103.

Don't make the mistake of thinking that process leadership is a substitute for product and technical leadership. It is not. The role of champion remains essential; there should be one or two people who deeply understand the customer and deeply understand the technology. If there are two people, they should speak with one voice and have joint responsibility for the success of the product. When an organization puts a new process in place, a process leader may be a good idea. However, the process leadership role must synchronize well with the role of champion, either through close cooperation or by adding process leadership to the champion's role. If there are two people in the champion role already, three may be too many. If there is one champion, she or he may welcome the assistance of a process leader.

Leaders

1. We have ScrumMasters, but their job is to manage the process. They are not supposed to make product or technology decisions.

   We question why a ScrumMaster should be limited to process leadership, since product and technical leadership is so critical to the success of any large development effort. If the ScrumMaster is not supposed to provide this leadership, then look for it elsewhere. Once a team has become a high performing agile team, the process leadership devolves to functional management and to those providing technical and product leadership.

2. We have Scrum Product Owners, but they aren't very involved and don't really understand the technology.

   The champion or product manager is a full team member, deeply involved in the day-to-day tradeoffs of the team, balancing his or her customer instincts with the technology tradeoffs. Without this interplay at a deep level, you will get a mediocre product. A team cannot abdicate customer understanding to someone who is not engaged with the team and mutually committed to achieving its purpose.

3. So where does a project manager fit in?

   If you examine the roles of highly successful project managers, you will find they provide the same product and technical leadership that are present in all highly successful products. Alan Mulally's leadership of the Boeing 777 has often been called project management at its best. He was chief architect of the aircraft, of the innovative design/build teams, and of the unrelenting emphasis on delighting customers.

   On the other hand, a project manager who mostly updates Gantt charts and tells people what to do probably adds little value to the team.

Responsibility-Based Planning and Control

Crew teams have coaches. The coach is usually in a motor boat with a mega-phone, organizing workouts and critiquing performance. But once the boat heads out to race, the crew team is on its own. All the coach can do is watch. Responsibility-based planning and control operates on the same principle: There is a time to stop telling well-trained experts what to do and expect them to figure it out for themselves.

The way this works at Toyota is remarkable. The product development process has specific synchronizing events such as vehicle sketches, clay models, design structure plans, prototype, and so on. The dates for each event are scheduled by the chief engineer. Every engineer and supplier knows that these dates will noteverbe moved. They know exactly what is expected of them at each synchronizing event, and they willalwaysbe ready with their contribution by the date. There are no excuses. Engineers are expected to obtain for themselves everything necessary to be ready on time. Thus, information is "pulled" by engineers as they need it instead of broadcast to long distribution lists. At Toyota, the engineering tasks required for each synchronization event are well known and standardized. But they are not tracked. The schedule is managed through the fundamental imperative that schedules are never missed. The rest is the responsibility of the engineers.

This may seem like an impossible development approach, except that you can find examples of the same approach being successfully applied in every major city in the world. Any city with a daily newspaper has a group of skilled people who develop a new product every day. They never miss a deadline, even when the news is changing right up to the cutoff, even when computers go down, and with surprisingly few exceptions, even while coping with local disasters. So if you would like to see a development process that never misses a deadline, go benchmark your local newspaper.

An important consideration to bear in mind when schedules become a commitment is that people must always have the time to do the job that they have committed to complete, and at the same time, the details of the job will always change. As we discussed in Chapter 5, if you expect teams to meet aggressive deadlines, you must limit work to capacity.

There is more than one way to accomplish this. Toyota has a good feel for how much effort will be required in any development cycle and staggers model development cycles so that the demands on each function are more or less leveled. Further, Toyota makes no attempt to schedule at the detailed level but expects that each function or supplier will back up their team members with additional help whenever it is needed.

PatientKeeper estimates features and tasks at a fine-grain level and dynamically adjusts that estimate daily. The new estimates give PatientKeeper an immediate alert when work exceeds capacity, and the amount of work is quickly adjusted make sure that there is no more work scheduled into a sprint than can be completed by the deadline.

Maintenance organizations maintain slack by working on routine requests that can be set aside, which provides the capacity to jump on emergencies when they arise. However you do it, remember that it is impossible to implement responsibility-based planning and control unless you understand the capacity of each team and limit the work expected of a team to its capacity.

Schedules

1. Shouldn't we schedule tasks?

   Most task schedules are deterministicthey don't have any flexibility for variation. If you use deterministic schedules with inherently variable things like task completion dates, the real task completion dates will always be at odds with the schedule. Trying to force out the variation from task completion dates is exactly the wrong approach, as Deming taught us, because it is inherent in the system.

   You have to change the system, and you have three options:

   1. You can add probabilities to the schedule with Monte Carlo simulations. However, this works best at a feature level.

   2. You can use a project buffer with the schedule as advised by Critical Chain scheduling. (See Chapter 10.)

   3. You can simplify your life by not scheduling tasks at all; use responsibility-based planning and control instead.

2. Don't we need a work breakdown structure?

   A system design is essentialthe major subsystems and their interfaces must be laid out. But this is a feature breakdown structure, not a work breakdown structure. Instead of tasks, decide what specific, working capabilities should be demonstrated, and when. Assign these to teams, making sure that the teams have the skill and capacity to deliver, and let the teams manage their own work. Expect them to deliver on time.

3. What about dependencies?

   First of all, do not assume that all dependencies are real. Break them whenever possible. The job of managing dependencies should fall to the systems design, not the schedule.

   At a high level, dependencies are handled by developing major subsystems in a logical sequence. At a detailed level, dependencies between subsystems should be handled through board information sharing across teams along with regular synchronization events. Individuals and teams should be expected to make dependent tasks happen so they can meet their goals. Simple, effective communication supported by an insightful systems design and an options-based approach to development (see Set-Based Design in Chapter 7) are the best tools for dealing with dependencies.