Amazon.com’s Journey to the Cloud
John Rauser presents the architectural and technological evolution of Amazon retail websites starting with 1994 and ending with adopting Amazon Web Services.
Article
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Are You a Whole Team?
Posted by Matthew Philip on May 12, 2011
If your team develops software through agile methodology, taking a whole-team approach is vital to getting the most out of agile practices.
RelatedVendorContent
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
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 — is a kind of “glue” practice: It holds a lot of the other agile practices together. For example, whole-team approach is #1 on Lisa Crispin and Janet Gregory's list of “key success factors” 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 a 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
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 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 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.
About the Author
Matthew Philip is a former agile coach at Asynchrony Solutions, but he prefers to be known simply as an “agile team member.”
For more information, visit this blog.
For further reference on this topic see:
- Agile Testing (Crispin and Gregory)
- Ron Jeffries on whole-team approach
- George Dinwiddie, “Three amigos”
- Ralph Waldo Emerson, “The American Scholar”
- Play soccer, not football: How to foster a whole-team approach by thinking in activities rather than roles
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
Power of three and a half...
by
Matthias W
Posted
-
Regarding smell #4:
...involving a tester, programmer and business representative...
I wonder if a system architect should be considered some kind of experienced programmer here. What's your experience on this subject? May incorporating a system architect here lead to kind of "predominant decision maker" issues, or does he/she generally has a different role in agile teams?
1 comment
Watch Thread Reply