Crystallising Kanban with Properties, Strategies and Techniques

On the flight out to the Kanban Leadership retreat in Iceland last month, Katherine Kirk and I were chatting about Kanban failure modes that we’ve seen out in the field (e.g. quirky command and control interpretations by people who had not had experience in Agile first), and played with the idea of combining Kanban with Crystal (kind of in the same way that ScrumBan combines Kanban with Scrum). We jokingly referred to this as CrystalBan.

The reasoning behind our discussion was that Crystal and Kanban are both adaptable, context driven approaches. Crystal concentrates a lot on working with the ‘human’ side of the methodology equation – highlighting good, tried and tested Agile properties, strategies, and techniques – and Kanban is focussed on incremental improvement at a pace which respects people’s ability to absorb change. We discussed how, as an Agile/Lean community, we sometimes take it as given that Kanban for software and systems was pioneered by people from the Agile world, and therefore we often don’t explicitly state what to use from Agile to get the best out of Kanban. Maybe we should?

It was a fairly light-hearted conversation, so we didn’t pursue it in Reykjavik, but the idea didn’t die either as both of us kept coming back to it. We held an Open Space session at the UK Agile Coaches Gathering a few weeks ago which didn’t produce anything really concrete, but did get some murmurs of interest, so Katherine and I sat down this week to thrash it out.

Why Bother?

Kanban failure modes was a topic twice covered in sessions in the Kanban Leadership Retreat and, interestingly, difficulties with ‘humans interacting with humans’ were pinpointed as one of the common causes of Kanban failure modes. Crystal’s main properties, strategies and techniques deal a lot with the people side of the equation from the Agile perspective…. which opens up the idea that it might be a nice possible blend with Kanban.

So, are they compatible? Can they work together?

In his book Crystal Clear,Alistair Cockburn describes Crystal as “a family of methodologies with a common genetic code, one that emphasises frequent delivery, close communication and reflective improvement…” and he points out that, as it is context driven, that “…there is no one Crystal methodology”. As a result he admits that some groups can “have trouble with Crystal because it is too empty to start with.”

In his book Kanban, David Anderson describe Kanban as “an approach that drives change by optimizing your existing process”.  This makes Kanban relatively easy to start with because the “essence of starting with Kanban is to change as little as possible”.

Given that Crystal gives guidance on what a successful process will look like, based on a strong Agile foundation, and that Kanban gives guidance on how to improve an existing process, drawing from Lean, it seems that they are a natural fit to realise the benefits of both while avoiding the risks. A win-win.

Crystal Properties

Crystal describes seven properties of a successful project, the first three of which are core:

  • Frequent Delivery – e.g. “the single most important property of any project, large or small, agile or not, is that of delivering running, tested code to real users every few months”.
  • Reflective Improvement – e.g. “a project can reverse its fortunes from catastrophic failure to success if the team will get together, list what both is and isn’t working, discuss what might work better and make those changes in the next iteration”.
  • Close Communication – e.g. “information flows into the background hearing of member of the team, so that they pick up relevant information as though by osmosis”. (Referring specifically to Osmotic Communication in Crystal Clear)
  • Personal Safety – e.g. “being able to speak when something is bothering you, without fear of reprisal”.
  • Focus – e.g. “first knowing what to work on, and then having time and peace of mind to work on it”.
  • Easy Access to Expert Users – e.g. providing the team with “a place to deploy and test the frequent deliveries”, “rapid feedback on the quality of their finished product”, “rapid feedback on their design decisions”, and “up-to-date requirements”.
  • Technical Environment with Automated Tests, Configuration Management, and Frequent Integration – “such well established core elements that it is embarrassing to have to mention them at all”.

In order to achieve these properties, different strategies and techniques can be employed. This is where we see that Kanban comes into play.

Kanban Strategies and Techniques

One source of Kanban strategies is David Anderson’s Recipe for Success:

  • Focus on Quality
  • Reduce Work In Progress
  • Deliver Often
  • Balance Demand against Throughput
  • Prioritise
  • Attack Sources of Variability to Improve Predictability

What David calls “five core properties to create an emergent set of Lean behaviours” could also be thought of as techniques in Crystal ‘dialect’. David’s five core properties are:

  • Visualise Workflow
  • Limit Work-In-Progress
  • Measure and Manage Flow
  • Make Process Policies Explicit
  • Use Models to Recognise Improvement Opportunities

I have a different model I use which maps onto strategies and techniques. The strategies are:

  • Study the System
  • Envisage the System
  • Limit the System
  • Sense the System
  • Learn about the System

with the associated techniques:

  • Value Stream Mapping
  • Visual Management Board
  • Work In Progress Limits
  • Cadence and Measures
  • Quantitative Experiments

So What?

Katherine and I both observed that the Kanban strategies and techniques do achieve the top three Crystal properties of Frequent Delivery, Reflective Improvement and Close Communication, as well as help towards some of the others. However, because Kanban for software and systems in the most part has its origins in the Agile world, perhaps its time, as a community, to start to examine whether we should be a bit more explicit about all the good Agile resources that already exists – as Kanban starts to expand further into ‘non Agile’ territory.

People new to Kanban, and without Agile experience and knowledge, may easily miss the benefits from some of the other properties, as listed in Crystal Clear, which have been tried and tested by the Agile community for many years. In the same way that Alistair made the Technical Environment property explicit, despite it being so well established, we shouldn’t forget all the existing established strategies and techniques which can enable the other properties.

Further, this approach helps us understand how other strategies and techniques from outside of Agile can help towards successful implementations. For example the work of Chris Argyris, as promoted by Benjamin Mitchell, can help towards Personal Safety.

 


 

I’d like to thank Katherine for her time, energy and passion in helping form this and collaborate on writing it up.

 

12 Comments

  1. Some nice thinking! I like that you articulate being explicit about studying the system first before changing it. I support the idea of getting knowledge in order to implement more effective actions. It seems similar to Check – Plan – Do.

    Thanks for the name check and the reference to Chris Argyris’ material on overcoming organisational defensive routines and encouraging double-loop learning. I’d love for more people to be part of a conversation on these topics!

    I like Crystal’s focus on create conditions of personal safety. I see these as a pre-requisite to being able to “discuss the undiscussable”

    When you provide an example of personal safety you say “being able to speak when something is bothering you, without fear of reprisal”. I think it may be useful to agree what you mean by “fear of reprisal”. I’d be nervous if people thought “I should be able to say what I see in whatever way I like without being responsible for the impact on others”. It is important to be able to say what you know but fear to say, but to balance this with saying it in a way that is minimally likely to create defensiveness in others.

    A challenge here is that people are often unaware that what they see may only be part of the situation and that in expressing their view (especially if negative and expressed without relating it to concrete situations) it can lead to others feeling insulted or unfairly judged.

    What’s your view?

    1. Hi Benjamin – thanks for the comment.

      I agree with you. The example was a quote from Crystal Clear, so in one sense I was being slightly lazy, but also trying to summarise in a line, what Alistair describes in 3 pages! He’s describing personal safety as a property of the environment, rather than an individual, which requires everyone to be safe.

  2. It’s surely a sign of maturity that the Lean Software community is finding the confidence to stand on its own, and try out successful strategies and methods from communities beyond Agile, adopting and adapting what works to improve its own approaches.

    Because if there’s two things that Lean *should* be it’s empirical and incessantly improving.

    (Personally I’d like to see a *lot* more of Mike Rother’s Improvement & Coaching Katas being adopted, and John Toussaint’s writing on Lean Management and moving from introduction of new methods to steady state is a revelation).

    Of course this means that each organisation should find its own way of expressing these principles – in some environments, strong process will be really helpful, without it being a wholescale adoption of an external process framework.

    One of the things I like about Kanban is that it’s not prescriptive in that way — pushing you to map your end to end process and follow it without defining what that process should be.

  3. I like the properties approach a lot – for example “reflective improvement” (which is what we really want) vs. “retrospectives” (one way to achieve reflective improvement).

    As you may remember I mixed Scrum, Kanban and Crystal in a presentation at the LAS conference in Zurich in 2009. The presentation itself was less than stellar, but the slides are reasonably popular:

    http://www.slideshare.net/jmeydam/scrumban-jmeydam

    I never understood why Crystal didn’t get any traction. Nobody seemed to care about Crystal.

  4. Hi, Karl & Katherine — really nice post. :). I propose you call it Crystallized Kanban rather than CrystalBan (which to me sounds either like a no-drug-zone or a deoderant :)…. even though I’ll lose on that request.

    Love the way you two are pulling these two “reflective improvement frameworks” together – they do fit well together (see http://alistair.cockburn.us/The+end+of+methodology )

    …and… I like that you are reporting out that people who take on Kanban without having the Agile background are missing the people factor – I would never have expected that, I’m so imbued with the agile mindset by now.

    (p.s. Jens: Crystal didn’t get much traction before, imho, because there’s no Shu-level implementation, so it’s too hard for beginners and too obvious-looking to experienced people, combined with I’m lousy at selling it. I think the CK (Crystallized Kanban) variant should get traction).

    If it’s called the “CK” approach, and “ck” is silent as in Cockburn, how do we pronounce it? 🙂

    Alistair

  5. Hi, Karl & Katherine,
    very good post – I am always fascinated about how many rivers flow into the same sea.
    Keep up the good work!
    Matthias

  6. […] @kjscotland on Crystallising Kanban with Properties, Strategies and Techniques […]

  7. […] It is possible to practice an Agile mindset with Kanban as a starting place for evolving the process. In this situation, the focus is around Agile values and principles where policies and processes are used to support people’s work. Such an approach may be appropriate where Scrum or XP are not a good fit for the environment. See CrystalBan as an option for integrating people into Kanban [Scotland – “Crystallising Kanban”]. […]

  8. Hi Karl,

    Too late to find this article, but I liked it!

    >because Kanban for software and systems in the most part has its origins in the Agile world, perhaps its time, as a community, to start to examine whether we should be a bit more explicit about all the good Agile resources that already exists – as Kanban starts to expand further into ‘non Agile’ territory.

    -Kenji

  9. […] It is possible to practice an Agile mindset with Kanban as a starting place for evolving the process. In this situation, the focus is around Agile values and principles where policies and processes are used to support people’s work. Such an approach may be appropriate where Scrum or XP are not a good fit for the environment. See CrystalBan as an option for integrating people into Kanban [Scotland – “Crystallising Kanban”]. […]

  10. […] It is possible to practice an Agile mindset with Kanban as a starting place for evolving the process. In this situation, the focus is around Agile values and principles where policies and processes are used to support people’s work. Such an approach may be appropriate where Scrum or XP are not a good fit for the environment. See CrystalBan as an option for integrating people into Kanban [Scotland – “Crystallising Kanban”]. […]

  11. Check your definition of command and control. There are actually two extreme poles of directive/non-directive leadership that both fall under the definition of “command and control.” Leaders since the early 1800’s — Lord Nelson, Klauswitz, Lee, etc. — have used mission and strategic intent and then allowed people on the lined make tactical decisions without heavy-handed superior interference. That is a legitimate form of Command and Control embraced by the agile and lean communities.

Comments are closed.