Chapter 8. Teams

Toyota sincerely believes that teams are more effective and efficient than the sum of individuals, and that when they are given the skills and systems of problem solving, the sky is the limit [LH08].

But teams are the core building block for large product development—and team structure has a huge impact on productivity and cycle time. This chapter covers different team-related subjects and their influence on organizing work.

Team has

• a shared work product

• interdependent work

• a shared responsibility

• a set of working agreements

• responsibility for managing the outside-the-team relationships [SJS03]

• distributed leadership [Katzenbach98]

Try...Self-Organizing Teams

Self-organizing teams are the basis of Scrum and a widespread modern management practice. They go by different names such as self-managing, self-directing, and empowered, but the idea is the same. And what is that? Well, the team has the authority to design, plan, and execute their task and to monitor and manage their work process and progress [Hackman02]. In other words, the team—rather than a (project) manager—has the responsibility of deciding how to work.

In a healthy self-organizing team, the leadership role is also shared among team members—a hard thing for traditional management to change. Preston Smith, author of the first book on flexible product development [Smith07], notes that a “measure of a self-organizing team is how frequently the leadership changes [in the team].”

What does it mean to share leadership among team members? At the MIT leadership center, Peter Senge and three other MIT professors did a four-year study called “leadership in the age of uncertainty.” One of their key assumptions was that leadership “should permeate all levels of the firm ” [Ancona05]. They identified four leadership capabilities: (1) making sense of the world around us, (2) developing relationships within and across the organization, (3) creating a vision of the future, and (4) creating new ways of working together [Malone05]. In a self-organizing team, all members constantly exercise these capabilities and, depending on the situation, one team member takes a more or a less strong leadership role.

We worked with some product groups who, when moving to self-organizing teams, gathered the people and said, “From today you are self-organizing; go and do your job.” Afterwards, they sat back and waited. The team was confused and their productivity plummeted. Self-organizing teams do not just happen, they need the right environment. The organization is responsible for supporting the team development by creating the conditions needed for teams to succeed. Switching to self-organizing teams means the job of the traditional manager changes from directing the team to creating these conditions.

In Scrum, the ScrumMaster is responsible for creating the environment a team needs to succeed. To avoid confusion, Scrum introduced a new role instead of changing the responsibilities of existing roles. The change from a traditional (project) manager to a ScrumMaster is a change in mindset and attitude. Often, traditional managers experience a loss of power, or what we call “illusion of power.” Some helpful references related to this change are included in this chapter’s recommended readings section.

The foundation of Scrum is the work of Nonaka and Takeuchi [NT86], who studied innovation and knowledge creation in Japan. Their conclusion: Innovative new product development is done by self-organizing teams. According to them [NTI84], self-organizing teams require to be:

• autonomous

• cross-functional

• challenged

Autonomy is already covered and a later section covers cross-functional teams. The third requirement is...

Try...Set Challenging But Realistic Goals

The one thing all team literature seems to agree on is this: A team needs a challenging performance goal. Why? A clear goal results in a shared-work product with all team members sharing responsibility. This binds the team together and challenges people to cooperate, learn, and work as a team. The result: The combined contribution exceeds the sum of the individual contributions—a truly high-performing team.

In the work of Nonake and Takeuchi, the teams were responsible for the whole product. Other studies showed that when the team is responsible for the end-to-end result, their internal motivation is higher [HO80]. Feature teams and requirement areas create this end-to-end focus, thereby, increasing the teams’ internal motivation and creating the conditions for challenging and meaningful goals.

Try...Cross-Functional Teams

Self-organizing teams are cross-functional (or multifunctional ). A cross-functional team is a “group of people with a clear purpose representing a variety of functions or disciplines in the organization whose combined efforts are necessary for achieving the team’s purpose” [Parker02].

Why are cross-functional teams important? Imagine having a single-function specialist design team, a single-function specialist implementation team, and a single-function specialist test team. These teams ‘optimize’ their work according to their specific function—a local optimization. They hand off work to “the next team”—another lean waste. And they create queues between the teams, which increases the total cycle time, and reduces the feedback loop, thus decreasing the learning opportunities (see Figure 8.1). Cross-functional teams avoid these wastes by letting the team see the whole.

Figure 8.1. Scrum has cross-functional teams

By definition, a Scrum team is cross-functional. Its members include at least product marketing (Product Owner), software development, and testing. A cross-functional team implies breaking the organizational barriers between development and testing by putting them in the same team. For most organizations we worked with, this was already a major change. However, when traditional product development literature mentions cross-functional teams, they are not talking about specializations inside the product development function; instead:

Cross-functional means that team membership includes all the key functions involved in the project, usually Engineering, Marketing, and Manufacturing, at a minimum [Smith07].

True cross-functional integration in large product development is rare. Instead, we have frequently encountered cross-functional project management groups with management representatives of the different functional areas. They do not work. Some examples:

• Most organizations turn such important cross-functional decisions over to a management group, but this arrangement is usually slow to react in a turbulent environment. Such groups do not convene often enough or quickly enough to deal with constant change. In addition, they do not have information at hand regarding decisions the team faces today. The team would have to brief them, which wastes precious reaction time. When a team is encountering constant change, it needs the capability to make cross-functional trade-off decisions internally, which means that it needs an internal cross-functional composition [Smith07].

• Ford had formed cross-functional planning groups of senior managers and senior staffers to think about future technology needs. One reason for forming the groups was to provide guidance for research work, which they did. But the executives wrongly assumed that the groups would also naturally serve as a link between research and the operating engine-development groups, thereby making sure the latter would tap the former’s knowledge. But those links never materialized at the working level [BCHW94].

• Cross-functional project teams ... do not guarantee effective development. Even good “teamwork” may not be enough. In one American company ... we found a very coherent “project team” with a high level of team spirit. But the team consisted only of liaison people from each department; none of the working engineers responsible for creating actual drawings and prototypes was included. The liaison team was effectively an enclave that tended to be isolated from the working engineers, who referred to the liaison members as “the team people.” It took extensive clinical study to recognize that this high integration at the liaison level masked a lack of integration across the development organization [CF91].

• A large telecom company we worked with formed program management teams consisting of project managers from the different functions. These project managers commanded single-function specialist teams, resulting in a traditional sequential life cycle with huge queues between teams. There was never any true cross-functional integration and the “cross-functional program management team” served as another structure for traditional command-and-control management.

• Another very large company we worked with was ‘advised’ to use this kind of management structure by IBM who sold them their integrated product development solution. This boiled down to using a stage-gate sequential life cycle process with a cross-functional management team. This team was controlled by a product development team leader who commanded the different single-specialist project group managers. Ironically, the IBM integrated product development material [Mugge04] refers to the same sources as this book. The earlier two stories about the lack of true integration came from these.

Clark and Wheelwright, authors of “Revolutionizing Product Development ” [CW92]—the classic work on product development—simply conclude that “True cross-functional integration occurs at the working level.” An ideal cross-functional team includes all functions needed for shipping the product. This is not possible in large product development. For example, only a few teams include hardware- or manufacturing-related people, and thus these teams do the work most related to these functions. Other functional groups that spend even less effort in product development, such as HR, are best left out of the team and in a supporting role.

The first step for most organizations is to integrate analysis, interaction design, software architecture, programming, and testing. They need to realize that in the long run, to become faster and more agile, other functions also need to be integrated in the teams. They need to remember that “Successful implementation of multifunctional teams requires a fundamental redesign of the entire organization ” [Meyer93].

Try...Long-Lived Teams

Creating high-performance teams takes time. It’s sad that currently the most common way of structuring work is by projects. Once the team finally manages to reach a level of high-performance, they are broken up and the individuals are assigned to new project teams. We worked with one of the first Scrum teams in China that was broken up when they finished their project work. In their retrospective, the most important item that came up was “We finally know how to work together and now we get split up.” Ironically, the reason for breaking up well-working teams is ‘efficiency.’ Efficiency is often incorrectly measured by an “increase in resource utilization” (remember the baton and the runner). But, does this really improve the overall efficiency or is this another local optimization?

If you are truly interested in performance, then it is unskillfull to break up high-performing teams. Instead of regrouping teams to fit the work, you can regroup the work to fit the teams. For example, when using feature teams you give features to existing teams instead of regrouping the teams for each feature. The teams are considered the “unit of organizing work.”

How long should a team stay together? Ralph Katz—a professor of entrepreneurship and innovation—studied the relation between team performance and team longevity. His research shows that R&D teams increase their performance until they reach a peak after working together for four years [Katz82] (Figure 8.2).^1. After this, their performance dropped, probably because of the lack of fresh ideas. Therefore, keep teams together as long as possible. But sometimes rotate members across teams to create new insights. Of course, self-organizing teams can decide to rotate their members themselves.

Figure 8.2. team performance over time

Try...Team Owns the Process

One reason for the increase in performance over time is improvement in the team’s process. A Scrum team owns their process and is expected to improve it. In Toyota, every team member is expected to not just execute his task, but to also be responsible for improving his team’s work. The team member handbook at Toyota states:

All team members are expected to take part in developing and designing new ways of doing their work that continue to improve the job and productivity as well as the quality of our product. In the process, team members also learn to work effectively as a team and to help their fellow team members, when necessary, to perform their job duties [LH08].

Figure 8.3. large-scale Scrum teams

Of course, team members only improve their process if they feel they own it. When people are regrouped frequently, it is hard to get this kind of ownership. The result is that people “just do their job,” follow the process, and a huge potential in performance and job satisfaction is lost.

How can multiple teams work together if every team has their own way of working? Multiple teams need to agree on cross-team working agreements—standards. The Scrum “Definition of Done” is an example of a multi-team working agreement. Over time, the working agreement evolves because teams reflect, learn, and improve. Important: No separate group owns the cross-team working agreement; the teams own them together.

When transitioning an existing product development group to Scrum, the set of basic agreements is not yet established. Neither is there a way of reflecting working agreements nor a way of changing them. To kick-start the transition, management can take one team’s agreements and make them the multi-team working agreements without having consensus. After this, they need to let go and let the teams evolve these agreements. We have seen this in a large radio network telecom product where the “Definition of Done” set for all the teams was based on that of a single team. This “Definition of Done” was above most teams’ capabilities and resulted in a temporary slowdown in all teams because they had to learn and expand their capabilities. One drawback was that the teams did not feel ownership of the “Definition of Done,” so it was hard for them to evolve it.

Try...Team Manages External Dependencies

In traditional development it is common for someone outside the team—a project manager—to manage the external dependencies for the team so that the team can focus on their work. Surprisingly, according to the results of long-time team researcher and MIT professor Deborah Ancona, teams with an internal and external focus outperform teams with solely an internal focus. She calls these teams X-teams.

High-performance teams manage across their boundaries, reaching out to find the information they need, understand the context in which they work, manage the politics and power struggles that surround the team initiative, get support for their ideas, and coordinate with the myriad other groups that are key to a team’s success [AB07].

She is not alone in this. An article published by Manchester Business School reviewed research on cross-functional teams and their success factors. The researchers found that “teams need to be educated to consider boundary management as an important part of their task ” [HGG00]. Harvard professor and long-time team researcher Richard Hackman suggests establishing two outward-looking working agreements, of which the first one is:

Members should take an active, rather than a reactive, stance towards the environment in which the team operates, continuously scanning the environment and inventing or adjusting their performance strategies accordingly [Hackman02].

What are the implication for large product development? They are profound! First , each team needs a clear goal so that they know their boundaries. Establishing customer-focused feature teams helps. It results in code-focused, cross-team communication. Second , the organization needs to make it crystal clear that the teams themselves are responsible for coordinating their work with other teams. A team’s success must be measured by the whole product’s success to prevent local optimization. Removing official coordination roles such as project managers makes it clear to the team that coordination is their responsibility. Third , establish a whole product-wide continuous integration system. This creates the visibility teams need so that they can coordinate their work. The health of the product must always be visible to everybody.

Coordination roles, such as the project manager role, tend to result in inward-focused teams who blame their failures on the coordinating person or on the other teams. They are victims. Removing these roles makes it crystal clear that teams are responsible for coordinating their work—managing their boundary.

The problem with coordination roles was painfully visible when we worked with a telecom messaging product. This product used Scrum and had ScrumMasters creating the conditions for self-organizing teams, but they refused to remove the project manager role. The result? The project manager became responsible for the coordination among teams and even for the communication to the Product Owner. He became stressed and overloaded with work. When we told him that his role is not needed, he laughed, and pointed out the amount of work he was doing. He did not realize that his role attracted the work, and that the work—the major bottleneck in the product group—would disappear if his role was removed.

Another product group did remove project managers and let the teams coordinate their work. One of the line managers of this group reflected on this change and said, “Nobody ever missed them, and I have fifty percent more ‘free’ time.”

Try...Dedicated Team Members

Avoid non-dedicated team members or “partial allocation.” A team member who is in multiple teams does not have the same commitment and shared responsibility as the other members. “Part-time people equate to part-time commitment. Part-time commitment leads to team failure” [Jensen96]. To the maximum amount possible, all members are 100 percent allocated—fully dedicated to their team. The amount of management waste that disappears is amazing. In the past, we worked with some traditional sequential life cycle product groups and saw that the amount of time managers were spending on “allocating resources” was non-trivial.

Try...Multi-Skilled Workers

In Scrum, a team develops the product in priority order—based on customer value. This results in a mismatch between the selected Product Backlog Items and the skills of the team, especially with long-lived dedicated teams. For example, the next iteration the team works on Backlog Item one and two. These items require work in ABC and ADE. However, the team consists of specialists in ABCEFG. There is no D specialist and there is no work for the F and G specialist (see Figure 8.4). What to do?

Figure 8.4. mismatch between Backlog Items and skills on the team

This mismatch is common. It means team members need to step out of their knowledge area and learn new skills. Learning multiple skills—developing multi-skilled workers—creates flexibility and understanding of each others job. Multi-skilled workers are common and important in Toyota:

Cross-training...has many purposes and benefits. To have members know as many skills as possible and to rotate among the team helps teamwork... and helps the team make improvements in order to raise their capabilities and improve productivity for the company. It also helps the flexibility... If a person already knows four or five jobs... [he] will be able to move to a new team and set of jobs and quickly and efficiently learn to perform them. On the other hand, if... [he] only learns one job and gets wedded to that job, or spends years developing the seniority to get assigned to an easy job, ... [he] will not want to move, thereby reducing flexibility [LH08].

When we talk to senior management about learning and multi-skilling, they tell us they worry about efficiency. When people are learning, they are slower. Therefore, the view is that it is more efficient to have the specialist work on the specialist things. This might make sense from a traditional Tayloristic^2. manufacturing mindset (though Toyota uses multi-skilled workers in manufacturing to increase efficiency), but from a product-development-as-knowledge-creation perspective [NT95], this kind of thinking is silly. Learning is the major activity in product development. In the long run, reducing learning reduces efficiency—not increases it. Sherman, in Fortune Magazine :

Workers will be rewarded for knowledge and adaptability. Specialization is out, a new-style generalism is in. The most employable people will be flexible folk who can move easily from one function to another, integrating diverse disciplines and perspectives... people will need the ability not only to learn fundamentally new skills but also to unlearn outdated ways [Sherman93].

Potential skill—How can this work in large-scale product development? The key is to think about potential skill instead of actual skill. A person has a potential skill when he can learn the skill in a reasonable amount of time. For example, people with a computer science degree can learn a new programming language within a reasonable amount of time. Even more important, when they already know five programming languages, then learning the sixth is even faster. Therefore, people should be selected to teams for potential skill rather than the teams being changed to utilize current skills. That way, people grow in their jobs and teams are kept together for a long time. When do you know your team is working well and learning? One perspective:

You will know your teams are working the day an engineer begins sounding like a marketer, or vice versa. Effective teams operate like a small startup in that people take whatever role is required, with little regard to function or rank. Leadership roles will also rotate when the team is working at peak effectiveness. The designated leader will step back and let leadership emerge from the parties either most knowledgeable or responsible for the issue under discussion. There is not an absence of leadership, but rather an increase and balance of leadership from all team members [Meyer93].

NSN has a central support coaching group, called Flexible Company , for agile development. The group was created as a cross-functional team with specialists from development, testing, quality management, CMMI, and some other areas. Each Monday morning the group held a meeting dedicated to learning. Lots of conflict—learning—happened during this meeting. The result? After a couple of months the areas started blurring and people outside this team could no longer recognize the original specialization of the persons.

Try...Team Makes Decisions

Self-organizing teams make their own decisions. However, many people grew up in a command-and-control environment where management made decisions for them. What happens when such people move to self-organizing teams? Endless discussion without decisions. This is painful. A ScrumMaster can help the team learn how to make decisions. There are many decision-making methods, such as voting, consensus, and “expert decides.” A team agreement on how to make decisions is more important than the specific decision-making method. That said, most healthy teams apply some kind of consensus decisions making method [KLTFB07]

We worked with a product group building network optimization products; they had fallen in the not-know-how-to-make-decisions trap. After a discussion of their current problems, it was obvious that they knew how to solve their problems except that they could not agree with each other on the solutions. We introduced the Decider protocol [MM02], which is a quick and easy way of making consensus decisions. This helped the team move forward because finally they could agree on which solution to implement for their problems.

Paul Nagy is a ScrumMaster in NSN Hungary. In one design meeting, his team could not make a decision. The team was split exactly fifty-fifty on the two design alternatives they had. After long discussions, they desperately asked their ScrumMaster, Paul, to decide for them. He asked the team to explain the two alternatives. Then he grabbed his wallet, took out a coin and flipped it. “Heads... alternative one,” he said. The team looked at him angrily and said, “You did not even think about it!” He answered, “You asked me to make the decision.” The team never asked him to make a decision again—they always made it themselves.

Try...Open Team Conflict

People working together creates conflict. That is not a bad thing. But conflict needs to be resolved. Unresolved conflict has a negative impact on team performance and creates a dysfunctional team atmosphere [Lencioni02]. Resolved conflict, on the other hand, creates learning and trust, both of which have a positive impact on performance. Conflict is an opportunity for the team to improve their performance, and hence a good thing.

Team conflict keeps a ScrumMaster busy. Without apparent conflict, the team is in trouble. You, as ScrumMaster, need to discover why. Are members avoiding discussion? Is something hidden? Are members truly committed to the team? When there is conflict in the team, a ScrumMaster observes the team to make sure they resolve the issues. Good teams resolve their own conflict; teams who were just formed need help. Well-working teams naturally have conflict but can express and resolve it.

We have worked with teams all over the world, and cultural differences are fascinating to us. North-East Asia (China, Japan, and Korea) has a very strong conflict-avoidance culture. People would rather shut up than create “social instability.” When working with or in these cultures, it is important to realize this and to sometimes open the needed conflict.

Effects on Organization

Self-organizing cross-functional teams have a major impact on the organization. To repeat an earlier quote,

“Successful implementation of multifunctional teams requires a fundamental redesign of the entire organization” [Meyer93].

Some points are covered here, but most of the organizational impact is discussed in the Organization chapter.

Avoid...Phase-based “resource allocation”

In traditional sequential life cycle development, each phase has phase specialists. For example, requirement specialists in the requirements phase, design specialists in the design phase, and developers in the implementation phase. The requirement specialist would only be on the release in the beginning—she was only allocated in the requirement phase.

Scrum is not the waterfall. There are no phases. With its self-managing, cross-functional, long-lived feature teams, it balances the “resource need” over the release. The same people stay on the release from the beginning until the end.

Avoid...Parallel releases (a symptom of imbalanced groups and work)

In traditional development, when a requirement analyst finished analyzing the requirements, what would she do? Would she wait for the testing to be finished so that the next release can be started? No...

Most organizations want to achieve a high “resource utilization.” Therefore, when the requirement analyst has nothing to do, she can start analyzing the requirements for the next release. That way, the ‘resources’ are used ‘efficiently’ and the time-to-market is improved. However, as seen in Queuing Theory , cycle time increases when “resource utilization” is high in a system with variation.

Figure 8.5. parallel release for so-called efficient resource usage, a local optimization “watching the runner rather than the baton”

Wishful thinking. Learning happens and requirements change. When the product is in a later phase, the requirement analyst is needed again. She spends her time on the previous release, thereby delaying the next release. Parallel releases increase waste—a lot. It causes multi-tasking, handoff, and extra processes. Ironically, the (misunderstood) “father of the waterfall” warned about this in his classic paper that was incorrectly used to justify waterfall development [Royce70, Larman03].

Parallel releases caused problems for many products we worked with. Product groups frequently decide “to do the next release with Scrum.” Scrum requires a cross-functional team from day one. However, the testers are still busy testing the previous release, and thus they are not included in the ‘cross-functional’ team. The result? Even with good intentions, the product group reverts to sequential development.

Without parallel releases, does the time-to-market degrade? The opposite is true. The removal of the waste in product development decreases the cycle time and therefore improves the time-to-market. But some products have large features for which development takes longer than one release. This is common in the telecom industry. The trick is to split up the large feature and deliver parts of it over multiple releases. These feature parts are integrated, included, and released, though they might be disabled from use until complete.

Avoid...Staircase branching (a symptom of imbalanced groups and work)

Functional teams and sequential life cycle development leads to parallel releases. Parallel releases lead to waste—and one of these wastes is caused by merging branches.

Traditional development scenario: When a feature in the first release has been coded completely, the developers start working on the second release. But, of course, release two development is not allowed to interfere with the first release. Thus, they create a release-two branch based on release one. The same happens with the release three, which is created by branching from release two.

We have seen this branching model with many large products and call it the “branch early” strategy. Berczuk and Appleton, in their classic Configuration Management Patterns [BA03] call it staircase branching (Figure 8.6).

Figure 8.6. staircase branching

This branching model maximizes waste. It causes developers extra work to synchronize all changes over all branches. We have seen products where developers spend most of their time on these synchronizations. What is the alternative? Branch as late as possible. Keep developing on the mainline and only branch off just before the release (Figure 8.7). This requires the development to use continuous integration.

Figure 8.7. mainline development branching model

Avoid...Projects in product development (a symptom of imbalanced groups and work)

Valtech often does relatively short-term projects. A client orders a ten-month project and when it is done, it is done. Xerox, Ericsson, Microsoft and many other companies develop products. A product has many releases and the code base stays around for a long time.

Traditional development with single-function teams, phase-based “resource allocation” and staircase branching leads to using projects for product development. Every definition of the word project (for example, [PMBOK04]) includes its temporal nature, resulting in a focus on short-term goals. Using projects for product development is fraught with local optimizations—short-term over long-term thinking.

Self-organizing, cross-functional, “resource-balanced,” feature teams work iteratively on the mainline by selecting work from a Product Backlog: This leads to a better balance between long and short-term goals that are needed for product development. The concept of project does not belong in this type of product development.

One large multisite product group has completely abandoned the concept of project in development. All feature teams get their work from the Product Backlog, and at certain points the Product Owner decides to release.

Conclusion

These different—but proven—team concepts cause major change in organizations.

• Self-organizing teams require a change from command-and-control management to manager-teacher. Instead of focusing on what people do, management should focus on how to create the environment for the teams to succeed.

• Cross-functional teams require breaking functional boundaries and working together across the whole organization to optimize delivering customer value. Instead of boxing people in functional groups, management should focus on cross-functional learning.

• Long-lived dedicated teams require giving work to existing teams and letting them decide how to do it. Instead of considering individuals to be the unit of performance, the focus needs to be on complete teams.

Table of Contents for
Chapter 8. Teams