Process Safeguards and Ski Slopes

black ski slope 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.

11 Comments

  1. […] Process Safeguards and Ski Slopes (Karl Scotland) […]

  2. Nice post. You talk about if a team is high or low “productivity”, they have safeguards, but what about the possibility that the safeguards were chosen first, and are responsible for the correlated productivity?

    1. Hi John,
      Yes, a team’s safeguards could end up impeding potential productivity gains. I’m assuming continuous improvement to remove/replace safeguards appropriately to realise those gains.
      Karl

  3. Hi Karl,

    that’s what fascinates me about Kanban: it gives us a new, generalized language to talk about various development processes, just like Einstein gave a generalized theory to what Newton described in simpler and more specialized terms.

    Kanban allows me to talk to waterfall experts in a completely different way than before. I do not need to argue for Agile immediately, but instead I can just ask them things such as:
    * How large is the batch with which you go through the waterfall?
    * “How often do you go through it?
    * “Which queue size do you use between requirements analysis and design?

    Your post now gives me even more possibilities to ask, such as:
    * The large batch size in analysis looks like a safeguard. Against what are you trying to protect yourself?
    * How much reward would you expect when you let go of this one safeguard?
    * and so on…

    Thanks for bringing this up!
    Matthias

  4. […] Scotland hat einen sehr interessanten Blog-Post über Sicherheitsmechanismen in Prozessen geschrieben. Seine wesentliche These: Prozesse hängen […]

  5. One more question, Karl: How do you deal with false safeguards?

    Some safeguards look like safeguards but they actually provoke the behavior that they were trying to avoid.

    Example: The waterfall process with several signoffs between phases tries to make sure that the software will be implemented exactly as the customer needs it. However, because of the large batch size, the lead time becomes so long that the customer will finally get software that he does not need any more. Just like Job (Hiob) in the Bible: “For what I fear comes upon me, And what I dread befalls me.”

    I think it is important to talk about false safeguards, too, and make clients aware of them. In a way, it’s like this: If they would have taken more risk, they would have protected themselves better! Absolutely ironic, isn’t it?

    1. I agree false safeguards are something to be wary of. I like Paul’s concept of the safety blanket (comment below).

  6. Great post Karl,

    This is how I’ve come to see Kanban too. Infact I’ve come full circle:
    http://pab-data.blogspot.com/2009/02/post-agile-beyond-best-practice-and.html

    You offer a very powerful metaphor for organisational ability, one that is sorely needed. Not every team is ready for the black slopes. I would say most aren’t. Matthais makes a good point about false safeguards. We could label them “safety blankets”?

    Like with children perhaps it’s not a good idea to take away their safety blanket straight away. Maybe its best to be patience and do a little cajoling until the child is finally ready to let go…

    I did some coaching for a team which was managed by a friend of mine. He was adamant that the team and the organisation wasn’t ready for Agile. He as much as banned the use of the term Agile less it came to mean cowboy coding.

    Initially I was just going to show them how to do TDD, but we ended up focusing on finding ways for them to better manage their work load and interact successfully with the business. We still didn’t call it Agile though. I think we said that they were learning how to do iterative development or something…

    Anyway, Agile was mentioned, but in context, and we had an open and honest debate about the real obstacles that stood in the way of them becoming Agile, assuming that they wanted to get there at all.

    Thanks for this. It has cemented where to fit Kanban into my bag of tricks. If I was in that same situation again, I would be advocating Kanban. Not sure that I’d use the label though… 🙂

    No thanks for this. And thanks for putting up with me in the past. I see the light. This is powerful stuff.

    Paul.

  7. Quite good metaphors. They indeed may help to explain ideas to customers. The important thing is waterfall often fails dramatically to deliver what was expected. So safeguards don’t help here and it is a sign that this metaphor maybe has some internal problems in logic 🙂

    1. No metaphor is perfect 😉
      On the other hand, some waterfall safeguards are put in place precisely because the project may fail – in particular penalty clause related safeguards. We once failed to win a piece of work because the client deliberately chose a competitor who they knew couldn’t deliver because they also knew there were enough penalty clauses in place for them not to lose money. Safe, but low reward.

Comments are closed.