Lessons on Distributed Volunteer Collaboration: Retrospective on Delivering the IIBA BABOK, Part 2

In my earlier post, I talked about a project I am working on: an all-volunteer effort to write an Agile-BABOK® extension (now we are officially calling it an “extension”, vs. an addendum).

I had suggested we learn from a similar effort—the development of the BABOK itself.

I figured the agile extension effort would be an ideal opportunity to document and leverage the lessons learned in conducting a project staffed by our geographically dispersed volunteers.

What works? What doesn’t? How can we adjust our practices based on our experience?

To learn about the BABOK development effort, I interviewed Mary Gorman, the person I consider the most knowledgeable about the BABOK (except for Kevin Brennan, IIBA’s VP, Body of Knowledge). (By the way, Mary’s BABOK Navigation tools are being freely provided to the business analysis community on our EBG Consulting web site.)

I volunteered to put together a list of retrospective questions to ask the Body of Knowledge Committee members (see Part 1) and started the retrospective process by interviewing Mary. She then interviewed most of the other committee members and summarized the interview data to share with the Agile-BABOK group.

Mary’s findings reveal the ingredients of successful collaboration and also bring to light special considerations for distributed, volunteer teams. In Part 1, I talked about what the group has learned about the product side. This time I turn to the process. Here’s what was learned.

Process

• Develop the product iteratively and incrementally, integrating larger community reviews into product development. Even though the process is iterative and the product is released incrementally, a big view of the product is essential. Test small chunks early on with reviewers. In that way, you can amend the conditions of satisfaction throughout the entire development effort.
• Establish rules of engagement, or working agreements. You can think of this as project “chartering.” As you define a shared vision, describe the way forward to achieve the vision. Here are specific actions to take when you’re chartering the project:

• Identify roles and responsibilities: who does what, by what deadline, and with what conditions of satisfaction. Openly share each other’s strengths, weaknesses, and personal learning goals. Agree on a rough estimate of the required effort for each work product, and then find out who wants to create which work product. Let people volunteer for work they have the energy, passion, and interest in delivering.

Have clear, consistent means to assimilate new volunteers as well as ways to end a role.

When necessary, be prepared to “unvolunteer” someone who is not fulfilling commitments.

• Agree upon mechanisms for doing this up front, so that everyone knows how to communicate (e.g., email, real-time discussion) and who will be involved.

• Resolve conflict and disagreements quickly and respectfully. Discuss mechanisms for doing this up front, so that everyone knows how to communicate (e.g., email, real-time discussion) and who will be involved.

• Establish and use transparent decision-making rules. Everyone should know what the decisions are, what decision rule will be employed, and when the decision will be made. Be prepared to use different decision rules for different types of decisions.

You will accelerate delivery if you practice transparent and swift decision-making. To get speed without sacrificing quality, sometimes it’s more efficient to use a decision rule “person in charge decides after discussion and polling.” Just make sure that the “person in charge” is able to represent the voice of the end customer and has the authority to make decisions.

Consensus is a good decision rule for high-stakes decisions that have a somewhat relaxed time frame. If you follow clear protocols, you can “check in” with a distributed group by using a gradient of agreement . If you choose consensus as the decision rule, be sure to learn the thinking behind people’s decision choices. This deepens the wisdom of the entire group. However, remember, with a volunteer group, consensus is not always the best decision rule.

• Communicate frequently, mixing modes. Build community, momentum, and motivation by sharing information regularly. Build trust. This allows healthy conflict to surface and permits people to test their inferences and assumptions. Include rich communication methods (not only asynchronous tools like email), and combine visual and auditory tools. Be sure that communication is facilitated by someone neutral to the content.

• Incorporate face-to-face collaboration. This is the ideal way to build trust, use physical space (e.g., wall work for large-scale visualizations), and deliver complex work products. Short, focused face-to-face sessions can save time and increase overall product quality in the long run.

• Learn continually by pausing regularly to conduct brief retrospectives. This allows the team to inspect and adapt the process and product incrementally.

I’m not surprised that this list of retrospective lessons represents practices of agile teams.

And no one should be surprised that as a volunteer on the Agile-BABOK addendum effort, I expect we’ll run it as an agile project! After all, we should eat our own dog food, eh?

Resources

• Retrospectives: Team Retrospectives article and a short article on Retrospectives, Norm Kerth’s seminal book on Retrospectives, Diana Larsen and Esther Derby’s fabulous book on Agile Retrospectives
• Wiki page for the agile business analysis knowledge base
• Info on the IIBA effort to create an agile addendum to the BABOK
• Fun mini video on agile business analysis
• “Decide How to Decide”, Sam Kaner (who first used the idea of decision rules and decision making on decision making), and how I use decision rules for workshops.