Ensuring the team is working on the right thing
In the previous article in this series, we outlined some simple open practices to start forming a team using the Open Practice Library. Now, we will describe some practices that can be used to define the team’s work.
It starts with a vision
Every great product ever invented started as an idea, a vision of a solution to a problem plaguing the inventor or their intended stakeholders. Understanding the problem the team is attempting to solve leads us to define the vision of the solution. We will outline some practices that can define the vision but also turn that vision into consumable work items that produce the functionality that solves a problem.
Start at the End
Start at the End is a practice whereby the team comes together to identify questions and assumptions that must be tested to achieve their goal. Often, this exercise starts with the question, “What does success look like?” The many answers to that question are then distilled down to define “the goal.” Examples of possible answers to that question are:
The product has the right automated tests and is universally trusted
One million downloads in one month!
Users find the Graphical User Interface to be beautiful and easy to use
All teams in the enterprise adopt the tool
This leads us to our Vision Statement, which may look something like:
“To be the defining technology company of the 21st century; and through our actions strengthen the social fabric by continually democratizing content and technology.”
- Red Hat, Inc.
From there, the exercise continues, and we try to answer the following question: “What are all of the ways we can fail?” Examples of possible answers to that question are:
Inability to agree slows development to a crawl, missing the deadline
Lack of stakeholder buy-in causes deprioritization of the project
Team skill level in technology causes too many bugs
Lack of automated tests reduces trust in the product, blocking adoption
Those are only a few possible answers; undoubtedly, the team will identify many more during a full session, which usually lasts one to two hours. These answers and questions arise as a result of this practice are then put through our next practice.
Affinity Mapping is a means of grouping things together by commonality. In essence, we are taking ideas that share a common theme of some kind and grouping them. In our current context, we will use affinity mapping to create goals that contribute to achieving the team’s Vision Statement. An example best serves this, the output of a fictional Start at the End exercise:
We can group these eight items by commonality.
Success item 1 and Failure item 1 are similar; they both represent Stability and Performance, so we would group them together and then label their topic as “Stability and Performance”.
Success item 2 and Failure item 2 are also related; we can group them under “Security”. Success item 3 and Failure item 3 are related by “Compatibility” with major mobile platforms, so that’s the topic in which they are grouped. Finally, Success item 4 and Failure item 4 are grouped under “GUI”.
Our final Affinity Map now looks like this:
We would then prioritize these topics using our team’s Priority Sliders from the last article to organize them for our next practice, Impact Mapping.
Impact Mapping is used to understand a strategic initiative and make the value of that initiative clear. This is typically used to achieve strategic alignment and a shared understanding of the team’s goals and problem statements. An optional output of this practice is a collection of Stories, which are then placed into a Backlog. In the context of this series of articles, we will use Impact Mapping to reinforce the team’s understanding of the vision, align on deliverables, and produce Stories for our new team’s Backlog.
There are five headings for our Impact Map; in order, they are: Goals, Actors, Impacts, Deliverables, and Stories. The input to our Impact Map is a Goal. For this exercise, our Goal is “High level of Stability and Performance”. Note that we’ve taken our “Stability and Performance” topic output from Affinity Mapping and have framed it positively. This is important because the change we are trying to drive with our solution is always positive.
An Actor in the context of an Impact Map can be a person, system, or process. Something that acts on our goal to make an impact. It’s important to note that the Actor does not have to readily exist; it can be something or someone that has yet to be created or hired to achieve an impact. An example of this might be an Automated Test Suite or a continuous integration/continuous delivery (CI/CD) Pipeline. Let’s use those two Actors for our current exercise:
We need to think of the Impact each of our Actors has on our Goal of high stability and performance. Let’s focus on our first actor, “Automated Test Suite”. What are some Impacts an “Automated Test Suite” can have? A couple of examples might be:
For this exercise, we’ll stop there. Focusing on our one Actor, our Impact Map now looks like this:
The next item we need to identify is “What deliverable results from this impact?” Let’s focus on the “Presents errors” Impact and see if we can come up with some Deliverables. Think about every test you’ve ever taken in school. The result of that test was usually a score or grade granted by whoever reviewed your test answers. That would lead to a report of all of your scores on something like a report card. With that example, some deliverables might be:
Number of errors
Number of successful tests
These example deliverables would go under our Deliverables heading in our Impact Map and be visually connected to the Impact that originated them--in this case, “Presents errors”.
Now that we have identified some Deliverables, we can take the next step to identify Stories on our map. If we take our Deliverables as a whole, we can group them under the topic of “Test Reports”. We know we want to have something that shows the number of errors a test presented and the number of successes, and we want some kind of stability grade. We can achieve this by creating a report that assigns a grade to whichever feature was being tested based on the number of errors and passed tests. So we may have some Stories such as:
Define stability grade formula
Generate a test report after each run of the suite that shows feature stability grade
Send test report to team email distribution list
We would repeat this process for each identified Goal, Actor, Impact, and Deliverable until we have a list of Stories that can be placed into our team’s Backlog. Those Stories would then be further refined using our team’s Definition of Ready before we begin work.
It is important to note that Impact Mapping can be a very time-consuming practice, but it can yield many benefits. The team can more easily visualize the direct connections between Stories, Deliverables, Impacts, Actors, and Goals related to their Vision Statement. With Impact Mapping, every team member shares this understanding and contributes their expertise to creating work items that will achieve the team’s vision. It is recommended that the team be prepared to allocate two to four hours for an Impact Mapping session, not including breaks, depending upon the Vision Statements and Goals..
In this post, we described some slightly more advanced practices to ensure the team is working on the right thing. We were able to define a vision, goals to achieve that vision, risks, actors, impacts, deliverables, and ultimately, stories that represent units of work. Most importantly, we described how, through these open practices, team members could align on and understand everything from the vision down to those work items to maximize the team’s ability to succeed.
At this point, our team has everything prepared to begin planning a release, executing on their stories, and showcasing their completed work, something we will dive into in the next article in this series.
Open Practice Library series on the Red Hat Blog
Learn more about our community-driven collection of exercises for making incremental progress along the product delivery cycle from the full Open Practice Library series:
About the author
Brian Tomlinson is a Senior Architect with many years of experience contributing to Linux and FLOSS communities as a user, administrator, and contributor. His work at Red Hat includes delivery of Red Hat Open Transformation, Kubernetes Operators, Container Application Development, and Hybrid Cloud Infrastructure for Red Hat Services customers.