The Decantation Tank (DT) is a canvas created by Knowledge21’s Agile Expert Danilo Risada. Since its creation, we’ve used this tool with different clients in very varied scenarios. The main application is to help teams define their products while keeping a clear and powerful link to the business purpose.
What is a Canvas?
Canvas are boards, posters, or other physical or digital tools that help link topics necessary for organizing an idea.
In this post, the objective is to give a general panorama of this tool. If you like it and want to know more about how the Decantation Tank (DT) can be used, send us your feedback!
Applying the Decantation Tank Canvas
Look at the example below. Check out the post-its and understand how the tool works:
The Canvas
There are various types of canvas, each with a different purpose. For example, the Business Model Canvas is a well-known one and, like the others, has re-defined fields to be filled in and some simple restrictions regarding how to do this.
The Canvas, this post’s topic, is divided into five stages: Purpose, Problem, Ideas, Main Idea (Focus), and CCC (Card, Conversation, and Confirmation).
Purpose
The purpose should describe the business objective we want to achieve. It’s the reason the Agile Team or company exists, or at least, it’s the starting point.
Here are a few questions to help you define the purpose:
- If we didn’t exist, what would our clients/company lose?
- Why are we paid?
- What is my company’s strategy, and how do we fit into it?
Avoid weak purposes. For example, our purpose is to modernize system X. Probably, system X is being updated due to some business necessity. Find out what it is.
In the example in the picture, the purposes are: facilitate receiving food at home and searching for restaurants. Two very distinct purposes, but they’re strong because they are purposes with which people easily empathize.
The purpose can be strongly linked to the company’s purpose, as desired. But if the link isn’t visible, it’s essential that there be no doubt about the purposes chosen and why they make sense.
Problem
We have a business objective, so what are the issues we’re solving for our clients? Fundamentally, the problems are described from a business point of view and always connected to people or groups of people. Some questions which might help define the problem are:
- What is our clients’ primary affliction?
- What do our clients desire, and why?
- How do our clients resolve their affliction today?
Avoid using excessively technical problems; you might be describing a technical solution without finding out your client’s needs. Some examples: update the architecture of system X for microservices; doing Trade Marketing of product Y; Delivering all the demands made by the first quarter of the current year, etc.
Metrics
Does the problem you thought of exist? If so, how big is it? When we create a solution, how efficient is it concerning the problem?
Imagine your problem is to run a marathon (42 km). How do you know whether you’re at kilometer 2, 20, or 40? How do you know whether you’re running in the wrong direction and are now 53 kilometers from the finish line? Metrics will help you measure the size of the problem and to what degree it has been resolved. Read the post Metrics – How to measure your team’s agility. In it, we discuss business metrics that measure the efficiency of your Agile Team.
Having a team with no metrics is like navigating the open sea with no instruments. All you have are feelings and, as an old teacher used to say, only Morris Albert (composer of the song Feelings) has known feelings. Prioritizing your product will be based on the thought “I think…”. That will lead to endless discussions and failed initiatives.
Ideas
What are possible solutions which affect our metrics and help resolve problems? If the product you’re creating is a software, which functionalities most impact the most important metrics? You can use the User Story format:
I as <persona/client>
Want to <idea (functionality with the solution hypothesis for the problem)>
To <problem to be resolved>
All ideas are valid. The only restriction is that there should be a relationship of causality between each idea and the metric it will alter.
Focus
Among all the ideas we have, which is most important? Which approach best alters the metric of our worst problem? It should be the first to be validated in our product. It doesn’t mean that other ideas will be ignored, but our focus will be on the most important of all.
CCC (Card, Conversation and Confirmation)
The co-creator of the eXtreme Programming (XP) method, Ron Jeffries, wrote that a User Story should be made up of three Cs. The first is Card, which is the item to be placed in the list of things to be developed in our solution (Backlog). In the case of the Decantation Tank, the Card is the idea in focus written in the format described above.
The second C is the Conversation. It is the moment of discussion about how the idea will become a product. Let’s discuss what the idea is, what it isn’t, what it does, and what it doesn’t do.
The last C is Confirmation. It is the move where we check if all people involved in creating the product are on the same page and define the rules of the game. It is where we generate acceptance criteria, define aims for the metrics, deadline expectations, etc.
Filling it in
There is more than one way of starting to use the canvas. As in the explanations in previous paragraphs, we can begin with a purpose and go down, stage by stage.
There are situations in which you can start with the ideas you have at hand and do reverse engineering until you find a clear proposal. We’ve done this a few times and found that a problem the team was trying to resolve didn’t exist. Another time, there was no way of measuring whether they were addressing the problem or not.
During the filling in of the canvas, it’s important to see the relationship between each item. The problem we want to resolve leads us to which purposes? Which ideas impact on which metrics? In other words, we promote an MxN relationship in which all items on the canvas are linked, as are the team members. We can represent this graphically with a line between post-its.
Feedback
Our main intention is to spread the word about our tools so that people try them out and tell us how it went. We’re curious to know how their use can unfold in different scenarios, so feedback is always really welcome.
