One of the joys of working as a coach for EMC Consulting are the regular opportunities to have deep conversations on various topics with my colleagues when we are in the office together. For example, earlier this week myself and Simon Bennett began to discuss way of talking to our clients about process such that we can guide them towards the most appropriate choice. However much we may have our preferred approaches, they may not always be the best solution in any context. In the course of the conversation we compared various styles including waterfall, scrum and kanban, and looked at them on various scales, including risk, reward and control. None of these seemed satisfying as a language to use, until Simon suggested safety.

Different processes have different levels of safeguards built into them. Safeguards are used by processes to compensate for low skill, low maturity or low trust, but they also reduce speed or reward. With a waterfall process, the heavy up-front documentation is a safeguard to compensate for low trust (and often low skill and maturity). When a customer does not want to collaborate, then waterfall provides safeguards aimed at avoiding them rejecting the final delivery (not that those safeguards always work!). At the other end of the spectrum, extremely productive teams often have very few safeguards because of the high trust, collaboration and capability. Those safeguards that are in place (such as automated tests) are very different. Not having safeguards doesn’t make the process dangerous. It means that team doesn’t need them. So when we talk to customers about process, we can talk about the appropriate safeguards needed for the amount of trust that exists, the capability of the team, the desired delivery speed etc.

While exploring this idea, I became aware that at various points I was referring to kanban at different places on the safeguard continuum. At the high safeguard end was a kanban based process that looked like waterfall, but was limiting WIP and reducing queue and batch sizes. At the low safeguard end was a kanban process with extremely low WIP, no estimation and pure pull. That’s quite a wide range of processes. Similarly, we had Scrum down as a range on the continuum. Towards the high safeguard end, Scrum-but changes Scrum to add safety. Towards the low safeguard end, a highly productive Scrum team will just be using the raw essence of Scrum. Even at this end, however, the Sprint boundary in Scrum could be seen as a safeguard. It’s the opportunity to pause and reset if things are going awry.

In trying to articulate the different types of kanban system in terms of safety, I gave a nod to XP and labelled low-safety kanban “Extreme Kanban”, and high-safety kanban “Safe Kanban”. Not entirely happy with this we bounced some more ideas around and came to the Ski Slope metaphor. “Extreme Kanban” became “Black Kanban” and “Safe Kanban” became “Blue Kanban”. A further iteration led us to “Off Piste Kanban” and “Nursery Kanban”. The ski slope metaphor works quite well at a number of levels. Its a nice way of looking and risk and reward. As a beginner at skiing I don’t want to take much risk, but can get some reward on the nursery slopes. As my capability improves, and as I trust my ability (and instructor) more, I’m prepared to go onto more difficult runs and take more risk to get more reward. Nursery slope groups are generally more controlled, staying in a single file group. As capabilities improve, individuals are given more freedom to try things out for themselves. If I were ever to become an expert, I’d be happy to go off piste to get a high reward. Additionally, when I get to a level where I go off piste, I probably don’t need an instructor anymore, but I may need a guide.

Using the ski slope metaphor allows us to decide what level of process to start a new team with based on how good they currently are. We may want to stretch them a bit, but we may not want them to go straight onto a black run process. We also want the team to be able to move up to more challenging but rewarding levels as they improve. This is one of the reasons I prefer a kanban based approach. I believe it allows teams to start with an safer process to begin with and move to more rewarding processes later by removing or changing safeguards, as opposed to pushing teams straight into a process with less safety before they are ready.