Does your team have an improvement objective? If you don’t, you’re probably not improving. So work out what you need to improve! Then you can use this canvas with your team to co-create a fit-for-purpose team improvement metric.
UPDATE: You might want to watch this 30 minute video I just made about using the canvas.
I’ve been playing around with “constraint mapping” as part of a crowdsourcing thing Cognitive Edge did earlier this year. They are moving to different terminolgy now and already have methods. I first did this with Civilian Applications as part of my research project with UTS but I thought I’d share the full method here and keep this post updated as I improve on it.
Introduce the idea that we’re here to make a “flower”. Have some examples of colourful finished flowers from previous sessions but with the words blurred out
Clearly state what we’re here to work on or make sense of - eg. “our company”, “this team”, “the current pandemic in Australia”, “the new product we want to make”
If < 6 people, make one group. If there’s > 6 people, break into groups of 3 - 4 people. If possible, put people who work together or know each other well in the same group - e.g. a group of managers, a group of designers, a group of friends. The idea is to encourage group convergence
Start with a blank slate and introduce the idea of the full entropy/chaotic state where all things are equally possible and nothing can happen
Introduce the idea of enabling constraints
Go through the typology of constraints with examples. Discussion and questions are good so ask questions if there aren’t any coming in - NOTE: The Cynefin typology is depricated so I might use my own at some point
Containers:
Invite each group to draw a dotted-line circle in the middle of their blank field with a diameter about half the smallest dimension of the field. Say, “ok, that’s ——————“ (whatever situation we’re here to work on).
Invite them to consider what Rigid/Fixed constraint is making this situation happen or will make it possible (if it hasn’t happened yet). Demonstrate drawing a teardrop shape around the situation with a sticky-note label in the pointy end of the teardrop. The sticky should say the name of the constraint and “Rigid/Fixed” as well. Explain that an unbroken line means it’s a “Robust” constraint, and that a broken line will mean it’s a “Resilient” constraint when we get to those.
Give a time-box of 20 minutes and ask the groups to go through each type of container from left to right in the table. When they find one example, draw and label it, then ask if there are any more of the same type. If there isn’t, move on to the next type and pick a new colour for it.
You can walk around and help people if they need to clarify the procedure. Resist the urge to suggest examples.
Connections:
After the time-box is up, demonstrate putting two stickies inside the container. Give them generic labels like “person” and “thing”. Connect the two stickies with a solid line to show a Robust/Fixed connection. Remind them, that a solid line means “Rigid/Fixed” and a broken line means “Resilient”
Set a timebox of 3 minutes and ask the groups work as individuals and generate stickies for all the different kinds of people and things that might be inside the system. Ask them not to use names.
Set a timebox of 5 minutes and ask them to share and consolidate their stickies, removing duplicates
Set a timebox of 20 minutes and ask the groups to go through each type of connection from left to right in the table. When they find one example of the type of connection, draw and label it with a sticky (only one sticky is needed for each type because they’ll all be the same colour). Ask if there are any more of the same type. If there isn’t, move on to the next type and pick a new colour for it.
You can walk around and help people if they need to clarify the procedure. Resist the urge to suggest examples.
I hear people say that agile is a commodity. I think it’s true. The real, authentic agile still exists but there is another agile that is more about off-the-shelf practices. In large organisations in particular, this can be what agile is. It works to some extent. It’s fine. I always try to pull things back to the essence.
Lately I’ve been doing lots of sketches for various purposes at work. Here’s a selection. If you need any illustrations for any agile-related concepts, drop me a line.
Icebreaker:
Working from home:
Mob programming:
Self-selecting teams:
Experimentation:
Lean Coffee online:
Remote online coaching:
Mob programming with a distributed team:
Sprint Review online:
Online meeting with video:
References:
Cynefin: https://youtu.be/N7oz366X0-8
Deming: https://en.wikipedia.org/wiki/W._Edwards_Deming
Sir Francis Bacon: https://en.wikipedia.org/wiki/Novum_Organum
Eric Ries: http://theleanstartup.com/principles
This is just a comic version of this video: https://youtu.be/N7oz366X0-8
The original paper from 2003: http://alumni.media.mit.edu/~brooks/storybiz/kurtz.pdf
Cynthia Kurtz was co-author on the 2003 paper (https://www.cfkurtz.com/). This paper opened my mind to the fact that all four domains are always present in any situation: https://www.cfkurtz.com/Kurtz%202009b%20Wisdom%20of%20Clouds.pdf
These videos of a full day workshop with Dave go deeper:
https://youtu.be/PFi9mIlp2NY
https://youtu.be/pFtOOm29kQU
https://youtu.be/PG8QvF5qLE8
https://youtu.be/2fBFBLuB6RU
https://youtu.be/joefmyXr_0Q
I use Cumulative Flow Diagrams for spotting problems and as a communication tool for discussions with the team. I’m using Google Sheets to keep track of how many cards are in each column of our Kanban board. Every morning I have a coffee and add a row for the day before.
In Google Sheets, the CFD is a “stacked area chart”. A CFD based on real team data is crazy looking compared to most examples you see, which are usually simplified views of very stable systems. A real CFD shows the peculiar conditions of the team. I value that more than the throughput, cycle time and lead time metrics although these are important metrics that can have real value for the team.
At the LAST conference in Sydney a couple of months ago, the keynote speaker was Henry Mitzberg. When he said “efficiency is the enemy of effectiveness”, I was shocked - mostly at myself for not questioning the idea of “efficiency” before.