A whole-team approach is an agile practice in which an entire team works as a unit of generalists to share the responsibility for producing high-quality deliverables. It’s a kind of “glue” that holds a lot of other agile practices together. Lisa Crispin and Janet Gregory, co-authors of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley Professional, 2009), for example, consider a whole-team approach the No. 1 success for agile testing.

By uniting and supporting practices, this approach yields powerful benefits—like lowering risk to delivery, improving velocity and cycle time, producing better ideas, and reducing defects and other waste. As with other agile practices, though, a whole-team approach requires discipline and diligence. To that end, here are four “smells” that might indicate that you’re not optimally practicing the whole-team approach as well as some possible remedies to help you overcome them. Although many of the examples I provide below come from the software development industry, they apply just as well to other industries.

Smell No. 1: Emphasis on titles

We recall a team that was new to agile, and one of its team members adamantly pointed to the organizational chart to prove that the tester wasn’t allowed to be involved until the programmer had finished the story. But titles don’t have to be so formal that they inhibit a whole-team approach. When a dominant team member asserts her status, a team will fail to challenge its tech lead because of her role. When the team expects the “tester” to do all testing, we also risk our whole-team advantage.

Remedy: Decouple roles from activities. When you look at work simply as activities to be accomplished together, you break down role boundaries and allow team members to add value in multiple areas. For example, free up programmers for exploratory tests. Similarly, let quality-assurance leads into the application code when they find a bug they can fix.

Smell No. 2: Hero culture

We’ve all met him: the guy on the team who is going to stay late tonight or work during the weekend to get the release out the door. He did it last time, and he’ll do it this time. Here’s the problem: Heroism is a detriment and a risk to the project because it lowers your “bus number” (i.e., the number of team members who could get hit by a bus and the team still functions) and often takes the form of information hoarding (not always intentional). It’s a bottleneck to progress and learning. Sub-smells: Can anyone take a vacation at any time? How easily could someone move off the project?

Remedy: Let go of the controls. If you’re the only one who updates the team board or fixes that breaking build, see what happens if you stop. Take a vacation.

During stand-up meetings, if you notice that members of the team are directing their comments only to you (as the leader) rather than to all of their teammates, simply avert your eyes. Team members will naturally respond by addressing the others, fostering a shared commitment to decisions and ownership of the meeting. The best team leaders are not information hoarders but information sharers, seemingly engineering themselves out of the equation by teaching what they know.

Smell No. 3: People sit in the same places every day

Do people come in and sit at the same places each day? Does it matter which workstation you choose? Does each workstation have all the tools you need, and is it configured for you to accomplish all your tasks? If not, this could indicate that you’re not often pairing and switching pairs.

Remedy: Really pair together. Pairing is having two team members sit together at one workstation to collaborate on a single task. This practice helps reduce information hoarding and improves the team’s “bus number.” However, pairing and pair switching require discipline. If you’re not doing it, it could mean you simply don’t believe it helps. To share knowledge and skills, build in time for learning, and allow some slack in your schedule or kanban system. You may need to push back on customer demands, but the short-term loss will yield a long-term payoff: You’ll move toward the extreme-programming practice of collective code ownership and go faster by removing knowledge-related bottlenecks. Try creating a pairing chart.

Smell No. 4: Odd man out

Do you have a team member who is left out of key meetings? This can happen when there is a big disparity between skills, a team has a part-time or shared team member, or the team leader thinks involving everyone in meetings isn’t a good use of time.

Remedy: Use the power of three. Agile teams can multiply knowledge and ideas via the power of three. When you have a policy of involving a tester, programmer, and business representative in key meetings, you will help the team share understanding of requirements, reduce communication gaps, and get the most out of each person’s unique skills and perspective. Janet Gregory calls this the “power of three,” while George Dinwiddie, a well-known software development consultant and coach, refers to it as “three amigos.” Whatever you call it, it is a fundamental part of the whole-team approach.

So the next time you’re sitting in a retrospective meeting thinking of how you can improve the next iteration or simply wondering if you’re the only one who knows how to fix a problem, consider some of the smells that might indicate a lack of whole-team approach. Or, better yet, stop what you’re doing and discuss it with rest of your team.