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.
This led into small-group sharing of our project stories, where we were encouraged to try to identify the things that contributed to the success or challenges expressed in the story. This exercise helped everyone distill his or her own thoughts.
The full group reassembled for a goldfish bowl that specifically addressed whether ATDD is dead or alive. As the discussion progressed, the facilitator recorded the list of forces identified as supporting or weakening the practice.
4. Dig Deeper
The afternoon was set aside for open space sessions, where subgroups self-organized to discuss topics they identified as important. This is a valuable opportunity for people to form closer ties by addressing a focused topic in more detail, and is usually where any concrete outcomes or action plans get their start.
Next, lightning talks summarized each open space session, and provided a final opportunity for people to share their thoughts in five-minute presentations to the group.
5. Action plan
The retrospective was concluded by brainstorming ways that the AAFTT program could be improved to serve the needs of the community better and ways that the community can get more directly involved. A set of concrete action items was created to ensure that the energy created in the workshop continued after we dispersed.
The design of this community of practice retrospective enabled participants to see a variety of perspectives and gain an understanding of how everything fits into the overall picture. The widespread crosspollination of ideas and stories answered some questions and raised new ones, promoting continual learning and growth within the community. Mission accomplished!
A brief history of AAFTT
The AAFTT program began in 2007 with a mission to improve how agile teams perform ATDD, with an emphasis on tool support. Face-to-face workshops and an email discussion group are the main vehicles we use to build a collaborative community of ATDD practitioners and tool developers. Elisabeth Hendrickson explains more about the program in her 2008 interview.