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.