Janet Gregory and Matt Barcomb are presenting "Patterns for Team Collaboration: Toward Whole-team Quality" at the Agile Development Conference West 2013. In this interview, they discuss the value of patterns and the meaning of "whole-team quality."
Janet Gregory: Our tutorial at the Agile Development Conference West is called “Patterns for Team Collaboration: Toward Whole-team Quality.” Maybe we should start by answering the question “What are the advantages to recognizing patterns?” Do you have any thoughts on this?
Matt Barcomb: Generally, I find patterns helpful in three major ways. First, they help people quickly identify situations and they give ideas about how to address those situations. Secondly, when a group of individuals shares the same knowledge of certain patterns, it provides a common language for understanding and working together in some domain. Finally, patterns are things to be applied, not implemented. Applying patterns allows us to take actions from principles, instead of mechanically implementing some checklist.
Janet Gregory: I find your third point very interesting. I looked up the definition of “pattern” and found that many descriptions use the word “model” to help describe the meaning. One model (or pattern) that I use to help teams is the Agile Testing Pyramid. [1] I think it demonstrates your points exactly. If people do not understand the principles behind it, they can completely miss the point. For example, there is not an exact ratio of the number of tests in each layer, but we want teams to create automated tests where they get the most benefit and get the fastest feedback to the team.
I use the term “whole team” very often and have some specific thoughts on it. I’d like to know what you mean by “whole-team quality.”
Matt Barcomb: At a high level, when I think of whole-team quality, I think of a cross-functional development team where all members feel responsible for quality and continuously work to understand and improve it. The team should understand that quality has various aspects and applications depending on context and that quality is more than just testing the software. Further, team members should work to understand how their particular specialties can improve quality efforts, especially when collaborating with other team members' specialties.
Janet Gregory: Well said. Team members each bring their own strengths and competencies to the team, and working together enables them to strive for excellence.
Matt Barcomb: So, now I'm curious. What kind of problems have you seen when teams don't use patterns?
Janet Gregory: Well, another simple pattern that I have introduced into teams is the “power of 3.” It gives people a common vocabulary to use and a framework for them to introduce “rules.” When teams don’t have that tool in their kit, I find they end up complaining about the lack of communication—for example, how the story changed and they didn’t know it. Once they have the pattern, they can talk about the problem in a positive manner and about solutions.
One team I was on created a rule that said if two people (from different competencies) were talking, the third had the right to interrupt and ask if the conversation was about a story. It didn’t take very long before everyone automatically looked for each competency before discussing any story.
Matt Barcomb: How do you see whole-team quality evolving over the next few years?
Janet Gregory: I see a positive move toward emphasizing competencies in a team rather than roles. As teams do that, I think we’ll see fewer “It’s not my job” excuses and more “How can I help?” conversations. I think team members will continue to have competencies in some areas more than others, but they may not identify as strongly to a particular role. For example, if I say, “I am a tester,” I really mean that I perform mainly testing activities because that is my primary passion, but I may help in other areas.
I have one more question for you before we finish up. What is one pattern that you think is helpful to facilitate collaboration within teams?
Matt Barcomb: So, a simple pattern, which is also one of my favorites, is from kanban; "visualize the work." Teams can visualize all sorts of things, like workflow, team norms, product goals, quality initiatives, etc. I find that visualization helps teams come to a shared understanding or build consensus more quickly. Plus, it can be fun.
Janet Gregory: I attended a quality discussion group today at lunchtime, and the presenter talked about how important visualization is to team dynamics. Her example was using mind maps for test planning—something I use and encourage with the teams I coach.
I am looking forward to our tutorial where participants will be exposed to some of these patterns and will be able to practice them during hands-on exercises.
References
- Agile testing pyramid: http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid
