Recognize Team Traps

As you try to create collaborative cross-functional teams, you may encounter problems such as these:

• Your team is a component team.

• Everyone on your team is a narrow expert.

• The developers and testers don’t work together, but rather in staggered iterations.

• The team’s membership isn’t stable, so the team has trouble learning to work together.

• The team pushes to finish work.

• The team cannot solve its own problems.

• Team members have a history and culture of individual work, not collective work.

You can work to overcome these traps. Here are ways that might work for you.

Trap: Your Teams Are Component Teams

You have a cross-functional team, but the team works across the layers of the architecture. Or you have a cross-functional team that is missing some scarce person, possibly a DBA or a UX person. These teams need help from other teams or other people to finish features. Whomever you are missing, your team cannot deliver a feature through the architecture.

Here’s what you can do:

• Ask the person you are missing to join your team full-time for several weeks. While that person works with your team, pair or mob on everything that person touches. (See ​Work as a Whole Team to Create the Product​, for details on pairing and mobbing.) If you’re like me, you might not become an expert in that person’s area of expertise, but you will have more understanding. You might need that person less often. I have seen this work with UX and DBA positions.

• Explain to your management that you are missing a person with specific expertise. Your team doesn’t have all the roles it needs. Maybe you can hire someone to join your team.

• It’s possible you don’t have enough people because your managers are stuck in resource-efficiency thinking. (See the discussion in ​Managers Move from Resource-Efficiency to Flow-Efficiency Thinking​). Create a kanban board showing cycle time, as illustrated in the diagram ​here​.

I do not recommend a relatively popular alternative: adding “visitors” to a team. Visitors interfere with the team’s collaboration. The team will have to explain to each new visitor how it works. And the team will have to re-form as it learns how to work with other people. See ​Keep Teams Together​, for maximum teamwork and learning capability.

Trap: The Team Consists of Narrow Experts

For years, managers hired and rewarded people based on their ever-narrowing expertise. In agile, we need people with expertise in multiple areas, called generalizing specialists. Experts have one deep capability. Often, the more expertise, the deeper their capability in an ever-more-narrow area. Generalizing specialists have varying expertise in several areas, as illustrated by the following diagram.

Everyone has preferences for what they like to do. When I was a developer, I preferred to work on the operating system (also known as the platform level) and algorithms, what we might call the middleware level in a several-tier architecture. I could work on the user interface, but I wasn’t as comfortable there. I could test other people’s code, but not mine—certainly not very well—at the system level.

I was a generalizing specialist with expertise in several areas. Did I have a preference? Of course. Was I willing to work with the entire team to complete a particular feature or set of features? Yes. Encourage that kind of thinking in your team. You might be able to have fewer people on the team.

Here are some ideas to encourage that kind of thinking.

• Make sure your managers and reward system recognize flow efficiency, not resource efficiency. See ​Managers Move from Resource-Efficiency to Flow-Efficiency Thinking​.

• Ask the team to limit its work in progress, so that the team has to work together to finish features. You can measure cumulative flow to see how much work in progress the team has for a given time and for the project.

• If you find it useful, consider lunch-and-learns. At a lunch meeting, one person at a time presents his or her area of deep expertise.

• Consider pairing or mobbing to avoid reinforcing expertise. (See ​Work as a Whole Team to Create the Product​, for details on pairing and mobbing.)

I have found it useful to make sure experts work with other people in some way.

Trap: Developers and Testers Work in Successive or Staggered Iterations

I’ve worked with and seen many teams where the developers and testers were not united in a single cross-functional team. The developers finish their work in the first two-week iteration. The testers might even start their testing in that iteration, but they don’t finish in the same iteration. As illustrated by the diagram, the testers on this team were at least two weeks “behind.”

Here’s the problem. The iteration duration is the duration of development and testing, and whatever else you need to complete the work.

When developers finish first, they create WIP for the testers. They may also become interrupted when the testers find problems. That means the developers create WIP for themselves, which might be invisible WIP because it’s not predictable.

Sequential work based on expertise makes your iterations longer. What would it take for you to work as a team on stories and reduce the lag between the time the development is done and the testing is done?

Consider these possibilities to help create cross-functional feature teams:

• Create and use a kanban board to see where the work is waiting for people or specific skills/capabilities. Now you can see who you need.

• Measure the WIP to see how much work is waiting for which kinds of people or teams. Maybe that will encourage cross-functional team organization.

• If you have functional teams, see the suggestion in ​Ask Teams to Organize Themselves​.

Staggered development and testing is not agile or lean. It might be better than what you did before, but it’s not an agile approach.

Trap: Team Membership Is Not Stable

Some managers are concerned that the team is not working at maximum output. Those managers ask team members to work on a couple of teams or on several projects. Those managers are stuck in resource-efficiency thinking. See the discussion in ​Managers Move from Resource-Efficiency to Flow-Efficiency Thinking​.

The more stable the team membership is, the easier it is for a team to become a norming or performing team. The team doesn’t incur a cost of re-forming itself every time someone enters or leaves the team. The team members learn how to trust each other.

Every time a team changes membership, the team incurs a decrease in throughput. That’s because the team starts back at forming again.

Keep stable teams together.

Trap: The Team Pushes Its Pace

Sometimes teams push themselves. Sometimes managers want to push the team into doing “more.” Here’s how you can tell if your team is working at an unsustainable pace:

• The team pushes to complete work just before a demo.

• The team wants a break between one chunk of work and the next. (In iteration-based agile approaches, teams want days or a week between iterations. In flow, the team members want a break between the work they complete and the next item on the board.)

• The team is working overtime all the time.

Developing great products requires everyone to be their best at all times. Don’t expect or ask people to work overtime. In my experience, that’s the fastest way to destroy technical excellence and creativity. Instead, ask people to collaborate at a sustainable pace.

Trap: The Team Requires Permission from Distant Managers to Solve Problems

Your organization might have powerful functional managers (development, quality assurance, and others) or a powerful PMO (project-management office). Those people dictate who works on your team and when, and what your team can do. Too often, those managers—while they mean well—do not understand the problems the team encounters.

The functional managers think about people as a “pool” of resources, as in the ​“Shared Services” Often Aren’t​ approach to people. And too often, the PMO dictates the project documents or the approach to the project the team should take.

Too often, these folks want to dictate solutions for your team.

Consider this: these people want to do the right thing. Their experience shows them that the “right” thing is different from what an agile team needs. As a leader, you have at least these options:

• Ask these people to take a chance and allow the team to experiment with its process.

• Ask these people to empower you as the person who can facilitate the team’s problem-solving process.

• Build your influencing and upward-coaching skills so you can work with these people over time to help them understand what agile approaches buy the team, them, and the organization.

And you always have the option of not using agile approaches. See Manage It! [Rot07] for a thorough discussion of life cycles that might be easier than using agile approaches. And read Chapter 16, ​How Managers Help Agile Teams​, for ways you can help your managers learn to think differently.

Trap: Team Members Are Wary of Collaboration

Each person has his or her own preferred culture and way of working. Sometimes you can see these cultural preferences, as covered in Cultures and Organizations: Software of the Mind, Third Edition [HHM10]. Some people enjoy working as part of a team. Some hate it.

Sometimes people hate being a part of a team because the corporate culture creates incentives around individual work. (See Organizational Culture and Leadership [Sch10] for guidance about corporate culture.)

Regardless of where the wariness arises, you cannot tell people, “Let’s all be a team now!” Nothing you say will make a difference. On the other hand, there are things you can do:

• You can ask people to experiment in short timeboxes for how they can work together.

• If your organization still rewards people only for individual work, your attempts to use agile approaches are likely to fail. You have an impediment to an agile culture. Add this impediment (individual rewards) to your impediment list, and escalate that to management. See ​Visualize Problems with a Board​.

• Consider discussing the difference between flow efficiency and resource efficiency, as discussed in ​Managers Move from Resource-Efficiency to Flow-Efficiency Thinking​, with team members.

• Conduct one-on-ones to understand each person’s concerns. Once you do, you can start to address those concerns.

Whatever you do, don’t tell people they shouldn’t feel a certain way. People own their feelings and beliefs. You might have a person or even a team that is not interested in agile approaches. Do not force agile approaches on them. Work with them for some reasonable amount of time. Help create a system of work that invites people into agile approaches. If that doesn’t work, be honest. Are agile approaches for right this team now? Maybe not.