In June, July and August of 2021, our blog posts were about engaging the whole team early in the discover and planning stages of the loop. We had several suggestions for practices that can help uncover hidden assumptions.
In this blog post, we look at quality within the ‘understanding’ stage of our holistic testing loop.
Lisa has often had this experience: The development team discusses a story during the iteration planning meeting, gives it an estimate, and starts working on it. They do a great job of coding and testing the story using good practices and delivers it to the product owner for acceptance. The product owner rejects it with a puzzled comment: “This isn’t what I asked for.” Grrr! So frustrating! The development team understood the story one way – the product owner understood it a totally different way. They failed to share the same view of the outcomes.
When teams work together with product folks and others in the discovery and planning activities, they start to build shared understanding. Once the high-level picture is established, it’s time to encapsulate that shared understanding in artifacts that will helps build the right thing. In our experience, there are a few factors to succeed with this effort.
Conversations among people with diverse perspective
In a recent episode of the “Making Tech Better” podcast, Lou Downe referred to Melvin Conway’s work, including this striking thought: “The quality of software is directly related to the quality of conversations we have”. Lou said collaboration is a privilege. Teams need to find ways to have conversations that often circumvent their organizational structures.
For example, the delivery team may use different terminology than people in other teams such as marketing, data and design teams, so the delivery team may need to collaborate with them, making the team knows how a particular feature is valuable to the customer, what it should look like, and how it should behave. There needs to be a safe space to talk with people in other parts of the organization.
Structuring the conversations
Once the team has committed to enabling cross-team collaboration, they can take advantage of the many frameworks and tools that enable them to get the most value from these conversations. The business rules and concrete examples that define how a capability should work can be turned into business-facing tests that guide development.
One practice that forms a great foundation for shared understanding is what we call Power of Three, or as George Dinwiddie dubbed it, Three Amigos. Before each team story planning workshop, a product person, a programmer, and a tester may meet to go over the proposed stories. These days, with our complex systems, we often need more folks, maybe up to four to six – a designer, a data expert, a marketing specialist, an operations specialist – whomever has valuable insight to the stories being discussed.
Keep these discussions quick and focused with a framework such as example mapping by Matt Wynne. Other visual collaboration tools such as mind mapping or simply using virtual sticky notes also help.
It’s important to ask questions. We like to use the “7 Product Dimensions” from Ellen Gottesdiener and Mary Gorman to think of good questions related to different quality attributes – along the lines of, “Where will customers be when they use the product? What interface or device will they use? Do we have test data? How many concurrent users do we need to support?” Asking these types of questions help to minimize the “unknown unknowns”.
Teams should also discuss risks that they can’t fully mitigate through testing. What events should be logged in the new workflow, to allow identifying and responding to issues once the feature is in production? What alerts and dashboards would be helpful? The answers add to shared understanding of the technical implementation.
The key is agreeing on the purpose of each story, its main value to customers, and specifying the business rules, with each rule illustrated with concrete examples. As shared understanding grows, the conversation will also uncover missing stories or ones that are too large.
These conversations may also produce low-fidelity prototypes, flow diagrams and other visuals that can be used to explain the desired outcomes to other team members and stakeholders outside the team. Last week, during a course that Janet facilitated, some of the participants were amazed at how much information they were each missing when they such a visual exercise. Share the outcomes with the rest of the team so everyone starts from the same level of knowledge when you have your team-wide planning discussion.
Guiding development together
Working together, programmers, testers and product owners can turn the business rules and examples from workshops into executable tests, using a domain-specific language that people outside the technology team can also understand and review. These tests form the basis for acceptance-test or behavior-driven development, where the business-facing tests guide development. They help to build the right thing the first time we try.
Using this holistic process of getting a cross-section of perspectives together to build shared understanding and produce artifacts that let us know what to code is a proven way to avoid re-work and waste due to stories getting rejected by the product owner or customer. Teams with strong shared understanding of what they’re going to deliver enjoy shorter cycle time. Looking further along the holistic testing loop, we can see that changes will get to production sooner, allowing for much faster feedback.