Lessons on Collaboration: Retrospective on Delivering the IIBA BABOK, Part 1

What are good practices for delivering a complex product for a broad global customer with a group of volunteers scattered all over the world?

This is a real-world question for me right now: I’ve volunteered to participate on the Agile-BABOK® (Business Analysis Body of Knowledge) addendum effort. Like the BABOK itself, this addendum can impact the practices of a broad worldwide community of professionals.

Learn From Those Who Have Been There Before

Two groups have tackled the problem of using volunteers to deliver an industry standard, so I figured we should “learn before we burn”. One group is the PMI Agile Community of Practice group, and the other is the BABOK Body of Knowledge Committee.

Ideally, learning what worked for these groups, along with their suggestions for what they would do differently were they to do this again, could help the Agile-BABOK addendum effort to start smart: leverage what they’ve found works, avoid or mitigate what didn’t work, and adjust their practices based on their experience.

In this post, I share the first batch of findings from the BABOK Body of Knowledge Committee.

Retrospective of Building the IIBA BABOK

To learn about the BABOK development effort, I started with 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 and started the process by interviewing Mary. Mary in turn interviewed 7 of the 9 committee members and summarized the interview data to share with both the interviewees and 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 this post, I look at the product side of what was learned about collective work. Next time, I address the process side.

Product: Learning Points

• Outline a clear, concise vision with a carefully bounded scope.
• Identify the owner and other stakeholders.
• Visualize internal and external interfaces.
• Don’t underestimate the power of a glossary.
  • Defining terms can be emotional, frustrating, and time-consuming.
  • Don’t start developing before you get agreement on key domain terms.
• Define conditions of satisfaction (“doneness”) for all deliverables.
• Before developing, use clear criteria that are understood by all stakeholders to clarify how you’ll know when a deliverable is done.

It looks as if this list reflects the practices of agile teams. I’m not surprised.

Will this agile comparison hold up when I look at the practices of the group in terms of the process itself?

Stayed tuned for my next post.

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” article,  Sam Kaner on sustainable agreements (I first learned about decision rules and decision making processes from Sam), and how I use decision rules in workshops (snip from my first book, Requirements by Collaboration).