The Agile Practitioners ran a session with Karl Scotland who was presenting his Kanban canvas. He started with a basic game to get everyone involved and to highlight a fundamental part of delivering projects. You start by putting your right arm up in the air and start drawing big circles in a clockwise direction and then slowly lower your are to chest height. Then Karl asked us what we noticed. Depending where you are looking depends on your perspective.
Part of the issue with delivering a project is that people try and come up with the solutions before really hearing and understanding the problem. Karl’s canvas is a way to break down a project and get people to focus on the what you are trying to solve.
The canvas starts with the System:
This is asking what is the problem, what are the boundaries of the system.
The team need to understand stakeholders problems and look for patterns to solve the problems. A technique that is used to get to the problem Karl called the Pixar pitch which goes:
Once upon a time…
Because of that…
Because of that…
Because of that…
Until finally (changes)
This helps you work out the issues and come up with a list of changes that are needed.
Patterns, structure and mental models are things that can be looked at in the system.
The delivery team needs to review the impacts to review how the project is going, how does the team know it’s working. There needs to be fitness criteria set at the beginning of the project so there is a common goal to work towards.
There are 3 things that need to be reviewed for the output, the flow, potential and value.
This is all about process, getting to the perfect process
It has to be quick, reliable and efficient
Is the system doing the thing right
What is the impossibly good ending?
What is the impossibly bad ending?
Where is the project and how can it be moved to the good ending?
A project can have good flow but no value!
This is about the product ensuring it is doing the right work and being effective
Again what is the impossibly good ending and what is the impossibly bad ending?
Is the project sustainable and what is the long term potential.
Doing the sustainable thing.
Passionate people working on this, flexibility and euphoria – no need to use the stick on the people!
Don’t jump into solutions – look at impacts first.
Then look at interventions.
The next points are about getting to the solution.
Understand present environment, studying where the project is.
Learn about the customer, learn about them. This could be achieved with empathy mapping.
Spend time with the customer and feel the pain!
Saying, seeing, thinking, doing
Come up with the following – X Needs a way to do Y Because Z
Classes of service- not all work is equal
Delays, decisions, feedback – where are the delays in the process so they can be removed.
How are decisions made?
Where are the feedback loops?
Value stream mapping is a way to analyse this.
Align people and get them working towards the same goal.
Create visualisation of the project and the direction for the team but be mindful of information overload.
Look at scope, time, cost, quality and priority.
What is the status, capability, demand, value and issues.
Visualise the risks, constraints, dependencies and assumptions.
What do you as a team want to share information?
How do you want to share the information?
Maybe colours for type of demand or inscription or placement to convey information.
Communication is key.
This is the intent behind WIP limit.
You don’t want to constrain a system too much but also no constrain will cause chaos.
Create policies – what does it mean to move into dev to test etc
Define definition of done/ exit policy – baseline for improvement
The process is stabilise the work and then improve.
E.g. WIP limits
E.g. Entry/exit policies, Definition of done/ready, Quality criteria
This is how good are we.
What is the systems capability?
Are we getting better or worse?
Outcomes – more productive better
Customer satisfaction, reliability, responsiveness – lead time, quality employee satisfaction – what do we measure. Finish work before we start
Metrics – defects
Behaviours – stop cutting corners
Trade offs- maybe slows work
Feedback cadences -release everyday?
Retrospectives – could be number of items to discuss
What are all changes that you could make?
What are the best ones?
Run small experiments to analyse this (MVP).
If we change x will improve y because
Measures to validate/invalidate
Ability to recover safely
Create a framework to experiment to get your ideal solution.
This canvas is a good way to break down a project and can be used to get the team on the same page. It also focusses the mind at looking at the problem rather than jumping straight to the solution. Let’s see how it goes!