Release Vision Exercise

In late 2014 the delivery team working on the Copyright Hub as part of the Digital Catapult UK where a bit confused about the upcoming Beta Release. They were getting mixed messages regarding what the release was for, when it was due, and what were the most important features to be included. To resolve this situation I gathered the delivery team and the customer representative and ran a collaborative Release Vision Exercise, which is described below.

Release Vision (45 minutes)

Who? 
Who is the audience of the beta release?

What? 
At a high level what will the beta release contain? Aim for no more than five bullet points.

Where? 
Where will it be used? All industry sectors? All parts of England? Europe, etc.

Why? 
Why would the users and stakeholders make the painful effort to change their existing habits and migrate to this new product? 

Strap Line…
What is a one sentence summary that we could use internally? LITMUS TEST: Can the delivery team come up with a strap line that they and the customer representative agree with?

The list was brainstormed, then discussion followed by dot voting determined the winner.

Release Levers (10 minutes)
What is the order of importance of the following items? Please note they must be ordered, i.e. there cannot be two priority one items.

• Scope – number of features included in the release (more is important)
• Cost – project budget / number of people involved (low costs is important)
• Schedule – when will it be released (earlier / on time release is important)
• Value – Usefulness and usability of the included features. (user experience is important)
• Aspects – ilities of the system, i.e. Security, Maintainability, Performance, Adaptability, etc. 

The blue numbers are the aggregate result of the Product Owner and Customer Representatives separate votes.

The end result

This process surfaced some key issues that the customer representative and Business Analyst (acting as Product Owner) disagreed upon and allowed them to resolve these differences. It also provided clarity to the delivery team regarding what they were being asked to do. The end result was a successful release that has changed the face of copyright on the internet forever.

Tree Root Diagrams, a powerful problem solving addition to the Five Whys

Solving problems in this complex world can be a huge challenge. The Five Whys is a powerful technique in our hunt for the root cause of an issue; however it rarely provides the full answer. Combining Tree Root Diagrams with the Five Whys can ensure that your team gains a full understanding of the root cause(s) of the issue. Once you know the root cause(s) a permanent solution is only a few simple actions away.

A Tree Root Diagram captures all of the causes linked to an issue in a downward expanding tree of causes. These diagrams often look like the root structure of a large tree. They are most useful when a group of people is collaboratively solving a complex problem.

The approach is straight forward: on a large whiteboard write your issue (really the symptom) in the top middle part of the whiteboard. Ask “What caused this to occur?” Write a very brief summary of each cause that is mentioned and draw an arrow from the symptom to each cause. Now repeat for each cause, building up your tree as your examine each cause. For each Root Cause you identify, circle it and come up with an action or two to address it. List the actions near the Root Cause and draw a line from the actions to the Root Cause.

Benefits of Tree Root Diagrams

• Finds multiple causes of a single symptom; including related issues.
• Visualizes the relationship between the symptom and its many causes.
• Visually links actions to the Root Cause the group is addressing.
• Allows the group to discuss tangential topics then return to the core issue without losing track of what they were up to.
• Acts as a record of what the group discussed and agreed upon.

More Examples

A simpler example

An example of when it is quiet linear.

A complex example

How I stumbled onto Tree Root Diagrams

Around July 2015 I was coaching some new Scrum Masters in effective problem solving and usage of the Five Whys. I keep hearing myself suggest to them to write down each answer to Why that the team called out. My intention being to get them and the team realized that the first answer is rarely the root cause. I quickly realized I was not doing this myself and set out to walk my own talk. What I found when I made a concerted effort to write down the causes, was that there were often multiple possible answers to each Why. Hence my notes quickly turned into tree diagrams which I labelled as Tree Root Diagrams and have used ever since.

Ishikawa diagrams

Tree root diagrams are similar yet different to Ishikawa diagrams turned 90 degrees. Ishikawa diagrams focus on categorizing the different causes in a hierarchy. Tree Root Diagrams focus on the linkage between causes; of potentially very different categories.