Are You a Whole Team?

This article proposes four “smells” that might indicate that you’re not optimally practicing whole-team approach in your Scrum software development project

Authors: Matthew R. Philip and Lori Cross, Asynchrony Solutions

Taking a whole-team approach has proved vital to getting the most out of teams developing software using agile practices. However, whatever industry or business your team is in, the following remedies can prove beneficial in improving team effectiveness and enhancing deliverable quality.

Whole-team approach – the agile practice in which the entire team works as a unit of generalizing specialists to share responsibility for producing high-quality deliverables — is a kind of “glue” practice: It holds a lot of the other agile practices together. Lisa Crispin and Janet Gregory, co-authors of Agile Testing: A Practical Guide for Testers and Agile Teams, for example, list a whole-team approach as the #1 “key success factor” for agile testing.

By uniting and supporting practices, it yields powerful benefits like lowering risk to delivery, improving velocity/cycle time, producing better ideas and reducing defects and other waste. Like other agile practices, though, whole-team approach requires discipline and diligence. So here are four “smells” that might indicate that you’re not optimally practicing whole-team approach – as well as some possible remedies to help you overcome them.

Smell #1: Emphasis on titles

I 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 formal to inhibit whole-team approach. When a dominant team member asserts his or her status; a team fails to challenge its tech lead because of their role; or 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 to exploratory test. Similarly, let QA leads into the application code when they find a bug they can fix.

Smell #2: Hero culture

We’ve all met him: You know the guy on the team who is going to stay late tonight or work this 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, since it lowers your bus number (i.e., the number of people on your team 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 their eyes — they’ll naturally respond by addressing the others, fostering a shared commitment to decisions and ownership of the meeting. The best team leads are not information hoarders but information sharers, seemingly engineering themselves out of the equation by teaching what they know.

Smell #3: People sit in the same places every day (a.k.a. my box, my chair)

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

Having two team members sit together at one workstation to collaborate on a single task is considered pairing. Pairing helps reduce information hoarding and improves the team’s bus number, but pairing and pair switching requires discipline. If you’re not doing it, it could mean that 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 a pairing chart.

Smell #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 lead thinks involving everyone in meetings isn’t good use of time.

Remedy: 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, well-known software development consultant and coach, refers to it as three amigos. Whatever you call it, it is a fundamental part of whole-team approach.

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

For further reference on this topic see:

Agile Testing (Crispin and Gregory) http://www.informit.com/articles/article.aspx?p=1316250

Ron Jeffries on whole-team approach
http://xprogramming.com/what-is-extreme-programming/#whole

George Dinwiddie, “Three amigos”
http://blog.gdinwiddie.com/2009/06/17/if-you-dont-automate-acceptance-tests

Play soccer, not football: How to foster a whole-team approach by thinking in activities rather than roles
http://toagileandbeyond.org/Matthew.Philip.PlaySoccer.pdf