Early on, Simon suggested the name CALM, and it stuck almost immediately. I like it for a couple of reasons. Mashups invokes the idea of “a creative combination or mixing of content from different sources”. That’s exactly what we want to do, and its the creative aspect that particularly appeals to me. A Cynefin, Agile and Lean Mashup will inevitably be created contextually. CALM also subtly counterbalances the XP extreme notion. While that’s not an intentional focus, I find it a mildly amusing reference.

My interest in Cynefin began back in around 2004 when Dave first spoke at XPDays London, and while back then I wasn’t smart enough to realise the full implications, fortunately others like Steve and Joseph were. I met Dave again at ScanAgile in 2009 and last year at the LeanSSC and ALE conferences. Simon also gave a great talk linking Scrum and Complexity more concretely at Agile2011, and I that’s when I finally figured out how Cynefin could match my interest in exploring the underlying theories behind Agile and Lean, and more specifically Kanban Thinking.

My personal goal for being involved in the meeting was to move Cynefin, and complexity science, from being something which is used as a justification, to something which provides meaningful explanation, and ultimately to new application. To keep the industry advancing, and to be able to apply Agile and Lean principles in increasingly challenging organisations, we need theory informed practices, as well as learning from our current success by evolving practice informed theory. In other words we need to take a scientific approach, which ties in nicely with my recent presentations on the Science of Kanban, which should make it to a blog post soon.

The primary outcome of the CALM meeting was the creation of CALMalpha. This is a two day residential conference to be held on the 16th and 17th of February 2012 at Wokefield Park in the United Kingdom. The alpha represents the notion that this is an initial safe-to-fail experiment where we hope to explore the subject in more detail, as we seek to find coherence, coalescence and convergence around what we do in the future.

More detail, including prices and booking information, can be found on the eventbrite page. I hope to see you there!

The dimensions I have used are the usual project management details, but can include the concerns of any member of a team or community. Let me know what other dimensions or data variants could be added, and what interesting techniques have you used to visualise them.

Scope

Scope represents the content of the work associated with an element.

• The size of the token can indicate the amount of work, with larger cards involving more functionality.
• An inscription can describe the scope, most commonly with a written annotation.
• A linkage can reference further details about the scope stored elsewhere.

Time

Time represents the when work starts and ends and how long it has been in progress for.

• Colour can indicate the aging of tokens, where lighter cards are newer, and older cards are darker.
• Graphics can also be used to represent aging, with a dot or other symbol, being added for each day. Different colour dots can further distinguish between what state the work is in for each day.
• A simple annotation of aging, or key dates can be written, using formatting to distinguish different information.
• Where a particular date or service-level is being targeted, an annotation can be added at key points in time, such as 50%, 90% and 100%+.
• The horizontal placement within a column can indicate time in progress, with the card moving further right each day.

People

People represent who the work is being done by (as opposed to resources!).

• Colour can identify the ownership of a token for small teams, or a primary functional or disciple group for larger teams.
• An avatar can be used as a graphic inscription to identify ownership.
• Horizontal alignment in swim-lanes can also group tokens and associate them with people or sub groups.

Cost

Cost represents the estimated effort required to complete the work.

• The size of the token can indicate the cost of work, with larger cards involving more effort.
• Colour can indicate the cost of the work, especially when using relative sizes or buckets, with larger cards representing bigger pieces of work.
• An annotation could be written on the token to indicate the estimated cost, such as a relative points, or t-shirt size.

Quality

Quality represents how well the work is being done.

• Colour can indicate whether the token represents value demand or failure demand. More failure demand indicates lower quality.
• An adornment can indicate the grading of a piece of work, where a lower grade (e.g. F) represents lower fidelity work, and a higher grade (e.g. A+) represents higher fidelity work.
• An annotation of the number of tests and/or defects can indicate the level of testing that has happened for a piece of work.
• The vertical placement of a token can indicate quality, with higher placement representing higher quality.

Priority

Priority represents how important the work is.

• Colour can indicate priority if using an enumerated scheme such as MoSCoW, where a mix of priorities is used to manage risk.
• The vertical placement of a token can indicate its priority, with high placement representing higher priority.
• Horizontal alignment in swim-lanes can also group tokens by Class of Service to indicate prioritization policies.

Status

Status represents what the progress of the work is.

• Vertical alignment in columns can indicate the current phase of a piece of work.
• The rotation of a token, such as making it portrait rather than landscape, can indicate that the status of the work has changed significantly, or that it is “done” for its current phase.
• An adornment can be used to represent key status types such as “blocked” or “done”.

Capability

Capability represents the amount of work that can be worked on at any time, managed through work in process limits.

• Where tokens are grouped through alignment in rows and columns, an adornment of the grouping can indicate the amount of work than can be taken in within the group.
• Alignment groups can also have a fixed number of “slots” which indicate the amount of work that can be taken on within the group.
• Graphical adornments such as avatars for team members can be limited and attached to tokens to indicate who is working on what.

Demand

Demand represents the amount and type work being requested. Demand could show failure and value demand types such as defects and features, classes of service, such as regular, fixed date or expedite, or investment allocations such as portfolio items.

• Colour can indicate the different types of demand for a relatively small number of possibilities.
• Shape or material can also indicate demand, and can be combined with colour to show combinations of work type, class of service and investment allocation.
• Horizontal alignment in swim-lanes can also group tokens by demand type.

Value

Value represents the benefit of completing the work

• Colour can indicate the value where a granular enumeration is being used such as High, Medium and Low.
• Size can also indicate an enumerated value, with larger tokens representing more value.
• A formatted annotation can be written to indicate the value where a more precise number is being used.
• The vertical placement of a token can indicate its value, with high placement representing higher value.

Externals: Issues, Risks, Constraints, Dependencies, Assumptions

These are all factors which are external to the represented work, but which impact it in some way. Issues represent things that might impact the progress of the work. Risks represent things that are impacting the progress of the work. Constraints represent things that limit the way in which the work can be completed. Dependencies represent things that must also be done as part of the work. Assumptions represent things that are expected to happen in order to complete the work.

• Adornments can be used to represent these external factors, with colour being used to distinguish between the different types.
• A separate token can represent each external factor, with colour being used to distinguish between the different types.
• The placement of separate tokens relative to the main work item can show the relationship of external factors, either horizontally or vertically as sub-states, or in a more free-form manner such as mind-map.
• A linkage can reference further details about the external factor stored elsewhere.
• A annotation can be written to provide more details about external factors. Formatting can help identify the different types.

Why create an other brand?

I’m in the camp that believes we need to create more brands, rather than reduce everything down to “common sense” or “good practice”. To paraphrase Alistair Cockburn, every successful team should create its own branded processes to describe the context and the solution.

Why another “Kanban” brand?

By using the name Kanban, I am acknowledging the roots of my current approach in hearing David Anderson talk about Kanban at Agile2007 in Washington DC. I consider that to be as important a turning point in my career as when I first read about Extreme Programming in 1999. Further, my response to calls to provide a single, clearer definition of Kanban for software development, is to encourage more definitions of Kanban. The more definitions there are, the less dogma there will be, and the more people will have to think for themselves about what Kanban means to them.

Why the “Thinking”?

As I mentioned when I blogged about Agile Thinking at the start of the year, thinking should be a core part of what we do. Alongside Lean Thinking, A3 Thinking, Systems Thinking, Complexity Complexity Thinking and Design Thinking, I want to make this explicit. Emphasising the thinking is also intended to make it clear that action is also required to succeed. Kanban Thinking is not a silver bullet as the right action is needed for each context.

What is Kanban Thinking?

Kanban Thinking is systemic. It takes a mindset of optimising the whole system, whatever the boundaries of that system are defined to be. Part of the thinking is deciding what those boundaries are. They do not naturally exist but are created by us to help frame a context.

Kanban Thinking strives to achieve flow, deliver value and build capability.

• To achieve flow is to have smooth, regular and frequent progress of work. Kanban Thinking looks to eliminate delays rather than eliminate waste.
• To deliver value is to focus on doing the right thing in order to delight the customer (and other stakeholders). Kanban Thinking looks to maximise value rather than minimise cost.
• To build capability is to develop people and knowledge as a foundation for business success. Kanban Thinking looks to develop people as problem solvers rather than their tools to solve problems.

Kanban Thinking involves studying, sharing, limiting, sensing and learning.

• Studying the current system helps understanding of the existing context.
• Sharing the understanding gives everyone knowledge about what is happening.
• Putting limits in place bounds the system to help stabilise it.
• Sensing how the system is performing gives an understanding of current capability.
• Learning from the systems performance allows for capability to be continually improved.

I hope its clear that doing as such would be insane! But why? Maybe “single leaf flow” would be better? Why did my instincts shout out otherwise? The answer, as I have learned so often recently, comes down to making an economic trade-off. Every decision has a value and a cost, and finding the right balance is key, preferring higher value and lower cost.

Each leaf cleared from my lawn would have value in progressing me towards my goal of a tidy garden. However, the transaction cost of removing each leaf individually would be far too great. Therefore, a more sensible trade-off was to batch the leaves into piles, so that transaction cost was spread over a larger number of leaves.

Further, like Geoff, I also considered the risk of creating multiple piles before bagging them up. I could also run out of bags, or have the piles blown away. However, I knew I had plenty of bags, and it was an unseasonably still day, so I created multiple batches before bagging. I was even able to safely have lunch between batching and bagging without any regret. In other words I made another trade-off between the value (in terms of addressing risk) and cost. The value (or risk) wasn’t great enough to justify the cost.

I may not have designed a Kanban System to rake the leaves, but I did apply some economic thinking to decide what to do. If there’s one main lesson I’ve learned over the last few years, its that there is rarely a ‘right’ answer, but that there are trade-offs, and they are usually economic.

I was reminiscing about this with Rachel Davies, who facilitated the Open Space at both Gatherings, and she shared the photographs she had taken of the output, which she still had. Here they are for posterity. I expected to find much of my thinking had changed since then, but apart from having less focus on waste and inventory now (preferring to know emphasise value and flow) it still seems relevant.

Here are the photos – thanks to Benjamin Mitchell for being the scribe. I’m hoping to add some of the audience which I know are out there somewhere.

[Show as slideshow]

• Token
• Inscription
• Placement

Token

The Token is the element which represents some piece of work, with the attributes material, size, colour and shape all able to represent information.

Material

The material is the base composition of a Token. Common materials are index cards and sticky notes, although anything which can be easily inscribed and placed on a kanban board will do.

Size

To add a further dimension, the material can be used in different sizes to show some relative relationship between similar elements. Index cards, sticky notes and other adhesive shapes all come in a variety of sizes.

Colour

Similarly, the material that is being used for a visualization element can have different colours to show some enumeration. Again, index cards, sticky notes and other adhesive shapes also come in a variety of colours.

Shape

As well as typical rectangular index cards or sticky notes, other shapes, such as stars or circles, can differentiate between various elements. Similarly, a variety of shaped annotations or adornments can convey further information.

Inscription

The Inscription is any detail added to the token about the work. Common types of inscription are annotations, graphics, linkage and formatting.

Annotations

Annotations are any written information added to a token to give basic details about what the token represents.

Graphics

Graphics can also be used to illustrate information related to the work in a more symbolic manner.

Linkage

Linkage can provide references to further information, or related work items, in order to keep the inscription focused on the most relevant information.

Formatting

How information is presented on Tokens can help to make them readable. Clear and consistent layout, using a tabular arrangement or zoned areas, ensures that any inscription is easily consumable.

Placement

The Placement is how the Token is positioned on the kanban board, with the location, alignment and rotation all being relevant.

Location

Where an element is positioned can convey meaning, with horizontal or vertical placement being significant on a relational board design. The importance of location can also extend to elements such as cards themselves, with the position of annotations proving important.

Alignment

When location is significant, then alignment can show a relationship between different elements, usually horizontally or vertically. Alignment is often used to create columns or swim-lanes with which to create an association. Other options include zonal alignment in a map-based format, or proximity alignment in a mind-map format.

Rotation

The rotation of an element can mean different things, particularly with rectangular shapes which can be positioned in either landscape or portrait mode, or at some other angle.

When designing a kanban system’s visualisation, thinking about how the TIPs are used can help come up with solutions which are creative and contextually appropriate, and help avoid falling into the trap of copying known and sometimes simplistic examples, as highlighted by Keith Braithwaite.

In a future blog post, I intend to demonstrate how different dimensions of a kanban system might be visualised with a TIP. In the meantime, I wonder if you think I have missed any other techniques?

For the retrospective, run by Eric Willeke, we asked participants for things that they had learned which were relevant to software development. Here’s the list:

• Focus on quality
• Communication is essential
• Let go
• People and process
• Experience is useful
• Being prepared
• Its important to know why
• Improve through collaboration
• Practice makes perfect
• People are responsible
• Ask & listen – don’t assume
• Redistribute work
• Power of whole team
• Lots of communication
• Simple visual metrics
• Integration is hard
• Don’t be attached to your process
• Knowing good enough
• Allowing for variance
• Be engaged
• Do it – inspect and adapt
• Variety is motivating
• Understanding impact of change
• Change is disruptive
• Shut up!
• Dress appropriately
• Common purpose
• Relentless improvement
• Communication without words
• Reacting to reality
• Be lean – JIT happens
• Building relationships
• Rhythm is fun
• Visualising progress
• Visualising WIP
• Adaptability in context
• People – not resources
• Cross functional to eliminate bottlenecks
• Single point of failure
• Self organising team
• Focus on the work
• Good communication
• People self-organising

Update: Eric has written his own post of the experience

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.

Flow Games

• When: Wednesday 10th August, 11:00-12:00
• Stage: Hands-on Learning
• Venue: LA Olympus
• Session Type: Workshop
• Audience: Introductory
• URL: http://program2011.agilealliance.org/event/a29c520db5d7bf4649bb9538adc6d1cf

Designing a Kanban System for the Enterprise

• When: Thursday 11th August , 13.30-15.00
• Stage: Enterprise Agile
• Venue: GA: Imperial Ballroom C
• Session Type: Tutorial
• Audience: Introductory
• URL: http://program2011.agilealliance.org/event/fad223cfed25bd3ad1a69cc0bbfad301

Note that while the program page for “Flow Games” suggests that we will play a selection of games, the final time constraint of 1 hour means that Eric and I will probably only be able to play one game, which will be the Ball Flow Game. Fortunately, there is another similar session (Lean Fundamentals with Michael Sahota) which will run the other games we had in mind, so we encourage you to go along to that if you want more!

To recap, the Ball Flow Game is based on the Ball Point Game, with the following rules:

• Participants play as a whole team
• Balls must have air time between people
• No passing to a direct neighbour
• The start person must be the end person

The aim is to complete 20 balls (as opposed to complete as many in 2 minutes). Thanks to Rally colleague Eric Willeke I now add some fun context as well. I tell the team that they are producing magic balls. Magic is added to a ball only when everyone has touched it. If two people touch a ball at the same time, the magic is dispersed. Further, magnetic fields mean that passing a ball to a direct neighbour also stops magic being added. The start/end person is the customer wanting magic to be added to the balls. Its silly, but it adds an extra element of fun, and reinforces that the rules are constraints in the context that can’t be changed.

I use a spreadsheet to help automatically capture data about the performance of the team. (Download the template). It works using four macros, which are assigned to buttons and hot-keys:

• Begin (Ctl-B). Begins a round by starting a timer.
• In (Ctl-I). Captures the time a ball is added into the system.
• Out (Ctl-O). Captures the time a ball come out of the system.
• End (Ctl-E). Ends a round by calculating the metrics.

Once the metrics are calculated, three charts on the worksheet will populate themselves.

• Lead Time. The time each ball took to work its way through the team (assuming balls enter and exit in the same order). The dotted line is the average.
• Throughput. The number of balls the team completes every 10 seconds
• Cumulative Flow Diagram. The number of balls either not started, in progress or done every 10 seconds

Upper and Lower Control Limits can also be calculated and displayed for Lead Time. They are currently commented out in the macro code because I found that they weren’t necessary for the core learning objectives. You may also need to tweak some of the macro functions for different versions of Excel (I use Windows Excel 2010). The template has worksheets for 5 rounds. For additional sheets, simply one of the existing rounds.

One of the things I’ve noticed is how the dynamics of the conversations are different from when I run the traditional Ball Point Game with teams. In particular, the team I was working with today really understood the idea of scientific management and made very small, quick and focussed changes each round as experiments, hypothesising on how the metrics would change. With the Ball Point Game I find teams want to debate in depth all the options in their attempts to get an improvement.

Note that as I said in a post of Balanced Software Development, “scientific management is still relevant for knowledge work, when the workers are the scientists.”

Here are the results. (Apparently we started with only 19 balls due to a facilitator error!)

Round 1

In this round, the customer ‘pushed’ balls into the system when he could. You can see the lead time increase as the WIP increases in the CFD, up to a point when a natural system limit is reached. Towards the end the customer stops adding more balls to let the system flush itself out a bit, which shows as the step in the CFD at about 60 seconds, the drop in lead time, and the spike in throughput. The final two balls went through when the system was virtually empty. Notice the short lead times again!

Round 2

In this round the team decided to limit the WIP to 6 – one per person. However, interestingly (to me at least) they decided to batch them, by getting all 6 through before they started the next 6. Lead time is much more stable this time. The spike is because the customer forgot to receive the last ball of the 1st batch before starting the 2nd batch, so it got stuck! Throughput is wildly variable though because nothing comes out for a while, and then all 6 come at once. You can see the batching in the ‘steps’ in the CFD.

Round 3

In this round the team wanted to experiment with an low extreme WIP limit of 1. Lead time is significantly better, but throughput is low because there is too much slack in the system now. Notice the smooth flow in the CDF. The patches where WIP drops to zero are because the customer’s process between receiving a ball out, and adding a ball in, added a noticeable delay.

Round 4

In this round the team increased the limit to 3, but continued to process those 3 in batches. Lead time remains the same, but with improved throughput. The CFD still shows signs of the batching with the customer delay between batches, but is much steeper due to the improved throughput.

Round 5

Finally, the team decided to remove the batches and solve the customer’s delay issue by re-organising themselves. This time the customer added 3 balls into the system, and then only added another when one came out. Lead time is slightly increased, probably due to the fact that there were always 3 balls in process which added some complexity. Throughput is improved again though, and the CFD is looking very smooth.

As you can see, the team made significant improvements over the five rounds by making small changes informed by the data they had about their flow and capability.