Are you a whole team?Posted: January 3, 2011
[The following is an excerpt from my presentation at the 2010 Agile Grenoble conference.]
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 software — can yield 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 a few “smells” that might indicate that you’re not optimally practicing whole-team approach, along with some possible remedies.
Smell: Emphasis on titles
On one team new to agile, a team member adamantly pointed to the “org 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. When a dominant team member asserts his status; a team fails to challenge its tech lead because of his 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: 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 – or win the lottery – 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.
If you feel the team reporting to the leader in standups, avert their eyes. The best team leads are not information hoarders but information sharers, almost trying to engineer themselves out of the equation by teaching everything they know.
Smell: 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 pairing and switching pairs.
Remedy: (Really) pair together
Pairing and 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 kanban. 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: 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.