It is a canvas that facilitates deeper understanding of the complexity of an issue. Where the pains are, where they come from, who owns the problem and ultimately derive use cases to design experiments for.

Frequently, teams within organisations find themselves attempting to solve complex problems from their siloed perspective.

An example of this would be development teams trying to solve speed to market issues by adopting Agile practices... only to find that the work before and after them is still using traditional waterfall methods. The result is water-scrum-fall; it doesn't solve the problem.

A second example would be an infrastructure operations team trying to solve speed to market by introducing a Kubernetes platform... but they fail to look outside of their silo to what their customers (software engineers) need from the platform rather than what the operations team think they want. The result is almost always an over-engineered solution that has taken too long to build and doesn't deliver the features the developers want; it's a 'field of dreams' approach only this time they build it but they don't come.

The purpose of the 5 elements canvas is to help identify areas of mutual interest and benefit between teams/ silos that are trying to solve similar problems independently to each other. This will enable them to identify where they can use practices to develop empathy, shared understanding and ultimately collaborate on a solution to which everybody is passionate about delivering.

The outcomes from running the practice will depend upon your role and your relationship with all the stakeholders; they include:

- Lowering silo walls and barriers to collaboration

- Broadening your stakeholder group

- Developing empathy with stakeholders by understanding their problem more deeply

- Earning the right to have the conversation

- Supporting stakeholders to raise the issue they face to leadership/ budget holders.

There is no set way around the canvas that is better than another. It generally depends upon the relationships you have with the different teams and the amount of time you can get from your stakeholders.

The first iteration of the canvas may be done with or without the stakeholders.

Steps:

1. Ensure the group has a shared understanding of the challenge. Using other practices such as 'target outcomes' may help.
2. Set a timer for 5 minutes and focus on your stakeholder group; e.g., Operations.

Place stickies (See silent brainstorming/ brainwriting in the links below) with pain points observed/ deduced/ assumed for that stakeholder group with respect to the challenge.

3. Extend time as required, use affinity mapping to consolidate responses.
4. Draw lines to show the causality/ source of the pain; e.g., Too much technical debt would have a line of causality from Product as it's the product owner's responsibility to prioritise the work that will enter a sprint.
5. Set the timer again and move to the next stakeholder group, ideally follow the source of the arrows. Identify their pains and see the problem from their perspective.
6. Repeat until all stakeholder groups are covered.
7. Identify who cares the most about the issue; e.g., using the technical debt issue mentioned above, whilst the engineers will certainly feel the pain, ultimately it's the product that will suffer as feature velocity will grind to a halt and costs will go up. Whilst everybody has their part to play in resolving the issue, if any group needs to own the issue, make a business case, etc. then it would be the product team.

Following these seven steps will develop a strong understanding of the problem, the causality of the pain, empathy for each of the stakeholder groups and a canvas around which a conversation can be facilitated.

This exercise is best done directly with the different stakeholder groups, but this isn't always possible. Running the exercise first and then using the canvas to validate your understanding with the different stakeholders is a great alternative. You'll be validating this with your stakeholders so it's ok not to be 100% correct! The stakeholders feel you have done your homework and validating/ pointing to what is missing is much more likely to achieve participation; in this sense you've earned the right to have the conversation.

The canvas helps each group understand and empathise with the other groups, plus clarify that they will not solve the complex problem on their own. This can either broaden your stakeholder group by team introducing you to key members of another team, and/ or help facilitate that conversation between the different teams.

Once validated, it is relatively straight forward to use the canvas as a springboard to identify use cases or experiments which can catalyse collaboration between the siloed capabilities.

Example: