Becoming a Learning Organisation the Kanban Way with Karl Scotland

Kanban Canvas

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…
One day…
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
Value/failure demand
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!

If you want to find out more about this visit Karl’s website the user guide.


Using improvisation to improve teams

Daryn who runs the Agile Practitioners Meetup has taken part in a number of improvisation classes and was impressed at how fast the facilitators build trust within the room. Within the first class he could see groups of people self organising and showing signs of genuine improvement, while enjoying the experience. He felt that the Agile world could learn from the world of improvised acting, therefore invited Paul Z Jackson, President of the Applied Improvisation Network, to come and give us a workshop and share some of the experiences of improvisation.

In this practical session, Paul Z Jackson shares secrets of improvisation and explores the deep connection with Agile.   It started with getting to know each other. Imagine the world, then stand where you were born and introduce yourself and say what location you are standing in when it’s your turn. Then we had to stand somewhere you wanted to go and say why to the group. Nice little ice breakers. We then had to find a partner, a group of 3 and a group of 5 to remember for the evening.

In the group of 5 you had to state your name again and why your name was special, a lot of interesting comments here and a realisation that all the names somehow linked to the bible! Then we needed to state why we were there that evening. It was a good exercise so Paul could gage where to go next, whilst we got to know each other and relax a little.

Then we got into our pairs. The task was for one person to draw a picture and the other to rest their hand on yours and follow the motion (yes, and). Each person got the chance to play both roles. Then you have to re-do the task but this time instead of resting your hand on the artist’s hand there needs to be resistance (no, but). The end result is a picture that wasn’t the one planned! I suppose this reflects the difference of working together and being resistant to the direction the person is trying to go.  This shows one case where you are working collaboratively achieving what the artist wants, the other working disruptively probably not achieving what either party wanted. It’s meant to highlight the importance of trying to work together.

The next game was also in our pairs we were asked to draw a face and name the face in silence. We were allowed to draw one item but if the pen left the paper the other person had to take over the next part, alternating between the pair. When someone hesitated with the picture then you had to name the face, one letter at a time, taking turns between the pair. Then we needed to present our ‘person’ back to the group and say how we felt about that exercise. Could we work out what the thing was your partner drew and build on it? How did it feel not be in 100% control, did the picture end up like you’d imaged? For me it’s not what I had imagined but working with someone else bought in creativity that I could build on.

We had to redo the exercise again, this time with a vision to be more creative. This was more interesting as the first time you start simply and safe. All groups started with a circle and the partners all interpreted this as the face outline. This time we all started with a different part and the pictures that were created were definitely unique!

These were all non verbal improvisation games so we moved onto the verbal games. We sat in a circle and were given a story and we could all add a line to the story to build it up. It was an exercise that should what sort of sentences help a story and what causes the story to crash and burn. For me it was a good way to highlight how easy it is to accidentally kill creativity in a team if you don’t encourage ideas. We re-did the exercise with a new story but we could had to start our sentence with “yes, and then”  to see how it was easier to keep the story going.

I really enjoyed the session and it does make you realise how easy it is to make or break the team dynamics. Some good ideas of how to get the team more relaxed together.

For more about Applied Improvised acting please visit the following links: 

Flow Chain by Bob Marshall

discussion1Flow Chain was a Meetup help by Agile Practitioners at Pearson’s given by Bob Marshall, known for his ideas on rightshifting. FlowChain is described by Bob as his model for how to organise a knowledge-work business along flow, synergistic and systems thinking lines. Organisations in the real world that have discovered and implemented (some) of the aspects of FlowChain include Reaktor (Finland) and Motek (California). Just to clarify Flow Chain is a framework to surface issues, not a methodology to resolve them.
Inband Improvement

Bob started with a Pecha Kucha, which is a deck of slides with one idea per slide, he spends 20 seconds per slide and then at the end we vote on what we want to learn about and then we spend about 10 minutes per topic voted for. These included:

  • Product Development Flow chain – How can we run organisations that are focused on new products?
  • Idealised Design – How would you rebuild a company if you were doing it all again?
  • Theory of Constraints – The company is only as strong as their weakest link
  • Companies are Organic – As the organisation perceives and accepts its organisational self-structure, more of its organic experiences, replace the present value system.
  • The Red Queen Effect –  Also referred to as the Red Queen’s Hypothesis, Red Queen or Red Queen’s race, is an evolutionary hypothesis. The term is taken from the Red Queen’s race in Lewis Carroll’s Through the Looking-Glass. The Red Queen said, “It takes all the running you can do, to keep in the same place.” The Red Queen Principle can be stated thus:
    In reference to an evolutionary system, continuing adaptation is needed in order for a species to maintain its relative fitness amongst the systems being co-evolved with.
  • Politics – Want to reduce the politics, keep calm and focus on priorities.
  • Covalency:
    – What is the need of all the stakeholders?
    – Can all of these be achieved?
    – What needs to be done to achieve this?
    Tom Gilb has done a lot of work in this area to ensure people quantify requirements properly
    – What isn’t working at the moment?
    – How does the organisation build products?
  • Single Piece continuous flow –  Agile methods are one or more steps nearer to the ideal of ‘single piece continuous flow’. BUT… they are inherently limited because they continue to create & disband teams, to establish & abandon value streams, to create and throw away know-how, at every opportunity. Need to keep this knowledge, not lose it.
  • In band improvement:
    – Plan, Do, Check, Act PDCA
    – Meaning sprint planning, do the work, retrospective and then feed in the output of the retrospective for the next sprints.
    – Toyota product development process was a good example of learning how to improve their process
    – Operational Value Stream Owners request something. This causes a backlog to be created, there are a pool of people who can work on these. Item moves into WIP (work in progress). The ideal item size is 1-2 days for 2-3 people.
    – In band is feeding back into the process of how that item can be better, an improvement suggestion and this can then be added into the backlog.
  • Evolution – Seeking the ideal
  • Emergence – Flocking behaviour, one alone isn’t great but together complex behaviours can happen. Pack is better than single.
  • Systems Thinking
  • YANGI – You ain’t going to need it
  • Self Organisation
  • Prog.nosis

Book recommendations:
The Phoenix Project
The Goal
Learning to See

The meeting was good and there were very interesting discussions from it, but it is one thing identifying the ideal solution, it is another to be allowed to implement it. How are these conversations broached, especially if you are a third party implementing as it suggests that you didn’t do it right the first time? I think you need to have a very open channel of communication with your customer and upfront book in time regularly to deal with technical debt and improving the deliverable. It would be good to hear from companies that are using this methodology and how it is working for them.

Tackling the 5-dysfunctions of a team

Sam Whiting who is a scrum master for New Bamboo gave a talk discussing Patrick Lencioni’s 5-dysfunctions of a team (Absence of trust, Fear of conflict, Lack of commitment, Avoidance of accountability and Inattention to results). He looks at the symptoms, causes and the behaviours so that they can be eradicated  from a team. This reviews how people can work together and build not a good team but a great team. Getting groups of people to work as a team can makes the difference in a project. When this happens continuous improvement can become part of the working culture and produce great results.

This talk for me was really interesting as it highlighted multiple points were a team could fall over and the difference a good team could have to being a great team. I have seen in teams a certain amount of apathy and when this happens how do you get people back working towards the same goal. Sam came up with some interesting ideas of trying to make the team personal, with the idea if you know a bit more about your team then this link will increase the urge to do better job within the group.

It would have been really useful to not have only listing the 5 dysfunctions but having real world examples of when this happened and using a methodology the team dynamic was resolved. I could relate to the issues but even with running retrospectives and team pub time I haven’t seen particularly successful ways of getting the team not only back on track but being better than good.

The session was recorded so if this is something you struggle with you can watch the session here.

Thanks Sam for a good talk (and Agile Practitioners for organising) and I enjoyed the presentation style, entertaining slides to hit the message home.