In my previous article, “ATDD: Not As Optional As You Think,” I explained why acceptance test-driven development (ATDD) is a key practice on agile projects that regularly deliver valuable running and tested features. In this follow-up article, I examine the retrospective design of the Agile Alliance Functional Testing Tools Program’s (AAFTT) Community of Practice Retrospective held on August 8, 2010.
As agile matures and its adoption increases, we continue to see mixed results and mixed opinions about ATDD. We hosted a community retrospective to share the successes and reflect on the challenges teams have experienced with ATDD on their projects. By increasing overall community learning, we can effectively focus our energy on individual, team, tool, and AAFTT improvements.
We were fortunate to have Rachel Davies, a renowned facilitator and coach, design and facilitate our retrospective. During the planning stages Rachel conducted interviews to understand the communities’ history, our motivation for holding the retrospective, and our goals. These discussions clarified how a community of practice retrospective differs from a project retrospective.
A project retrospective promotes continual improvement of a team working towards a common goal. Following a general framework, the retrospective facilitates synergistic problem identification and solving in order to identify the highest-priority action items that will be addressed in upcoming iterations.
A community of practice retrospective promotes the maturity of a practice that is performed in many different contexts. The retrospective facilitates deeper understanding of the practice through sharing a wide variety of concrete experiences. Based on insights gained, each participant builds an action plan for herself and her team. Taken collectively, these changes move the state of the practice forward or in a new direction.
Looking at how Rachel designed our specific community of practice retrospective, it is possible to suggest a general framework.
1. Representation & Alignment
In a project retrospective, the participant list is predetermined to include all members of the project team, and there is a focus on safety to ensure everyone fully participates. In contrast, a community of practice is a self-selected group of widely diverse people connected by a common interest in the practice. A community of practice retrospective is most successful when there is a broad representation of the community, including different roles, length of experience, type of experience, project context, and tool used.
Alignment of participants in a community of practice retrospective is accomplished in several stages. First, the registration process includes answering several questions that establish level of experience and commitment of each candidate. Next, the organizers review the list of candidates and decide whom to accept to ensure a balanced perspective. Finally, at the workshop, the goals and scope are reviewed and updated by the entire group to get full cooperation and commitment.
2. Temperature Reading
Our community of practice retrospective was focused on a central question: Is ATDD dead or alive? We got an initial indication of the various points of view through an exercise called Pleasures and Pain. Small groups collaborated to create a collage of drawings that expressed the positives and challenges about the practice. Drawing engages a different part of the brain and is a good way to collaboratively express ideas succinctly and concretely in a short time period. Not only was this a great way to get a group of individuals warmed up for a full day of collaboration, it also gave an overall temperature read: We can easily see the proportion of pleasure to pain and whether similar themes emerged across groups.
3. The Parts and the Whole
We engaged in several activities designed to see how our individual experiences fit in with the community as a whole. First, we built a timeline by having individuals identify key events from the start of the program to the present and into the future. Four different colored cards were used to distinguish between personal events, program events, tool events, and ideas. The timeline helped to make progress and connections visible.