Collaborate with Customers: Success factor #6


May 18, 2023     Janet Gregory, Lisa Crispin
collaboration, quality, success factors     Collaboration, Quality

Font size:


As we mentioned last month, we’re doing a series based on our seven success factors from our first book, Agile Testing: A Practical Guide for Testers and Agile Teams. We’re bringing in some new experiences and showing why we still think they are important.

Success Factor #6 – Collaborate with customers

In the summary chapter of Agile Testing, we noted that one of our biggest contributions as testers is helping customers clarify their requirements using concrete examples of desired and undesired behavior. The team can turn those examples into executable tests to guide development from a business-facing perspective.

Many testers excel at learning the business domain (remember what we said last month about “Looking at the big picture”). They also communicate well on a more technical level with the rest of the delivery team. In Agile Testing, we talked about using “Power of Three” conversations – better known these days by George Dinwiddie’s term “Three Amigos” – to build shared understanding among programmers, testers, and product owners (PO). These conversations are especially helpful to do before team-wide iteration planning meetings (IPMs). Fleshing out user stories with the story goal, business rules and examples to illustrate those rules helps everyone on the team start out “on the same page” as they discuss each story. The planning meeting goes faster and there are other benefits such as ensuring all stories are a similar small size.

Today, there are multiple frameworks available to us to make these story readiness discussions more fruitful. Structured conversations and 7 Product Dimensions from Ellen Gottesdiener and Mary Gorman’s Discover to Deliver book promote lateral thinking and help ensure no quality attributes are overlooked. Having the product owner part of these discussions means that you can ask about risks and be able to mitigate those risks early. Tried-and-true techniques such as flow diagrams, state diagrams and context diagrams are still effective. Of course, today we need to draw those together on a virtual whiteboard in a remote video meeting!

An example would be handy right now…

Lisa was part of a team which was struggling with high “rejection rate” – they delivered stories to the product owner, only to have the stories rejected with a comment, “That isn’t what I wanted.” It resulted in long cycle times from when the team started on a new capability and when the customers could start using it. They had pre-IPM meetings, but these did not result in increased shared understanding, they were just hand-wavy discussions.

                                     

When Lisa learned about Matt Wynne’s Example Mapping technique at a conference, she showed it to her team and proposed experimenting with it at the next story readiness (pre-IPM) meeting. Two engineers, a tester, a PO, a designer and other specialist as needed, met to go over the stories planned for the next iteration. The structure provided by example mapping enhanced communication among the different team members. The combination of business rules and concrete examples, which were noted in each story in their online project tracking tool, helped everyone share the same understanding of what should be delivered for each story. When the product owner is not entirely sure of the answers, the examples can be taken to the client or end users to get their opinion.

At the IPM, the whole team discussed each story. Thanks to the example mapping, everyone quickly understood the goal of each story, along with its business rules. More questions came up, of course, but the discussions went much more quickly than in previous IPM meetings. The stories were already “right sized,” which saved a lot of discussion time.

Rejection rate for these stories was half the usual rate. The team continued using example mapping and found cycle time also went down by about half, thanks to this collaboration.

Imagine trying to achieve the same results with written requirements provided by a PO with little or no discussion with the delivery team. Real time collaboration is key, and techniques that help structure the conversations save time and get everyone on the same page.

Collaborating in our new all-remote world

Over the past decade, we’ve seen more and more teams with remote team members, and all-remote teams. Pre-planning and planning meetings are (hopefully) held in video conferences. Using techniques to structure conversations and visualize examples is even more important. Use online tools that let everyone collaborate real-time. These can be simple. For example, Lisa’s team used a Google Slide with pre-populated text boxes so that each team member could type in ideas, then group similar ones together. Google Drawings, Google Jamboard, online mind mapping tools, Google Sheets are just a few tools that are accessible to many teams, and there are many more sophisticated ones like Miro and Mural for teams that can afford them.

Summary

We’re in the continuous world and we need continuous collaboration with customers., We talked about building shared understanding before starting work on new features. We need to continue that collaboration as we test and code the features, showing our customers the new changes early and often. Business stakeholders collaborate with us as we deploy and release new changes, analyze production usage data, learn about problems our end users are having, and feed that information back to decide what new changes to make next.