Lean & Kanban Conferences – Looking back and looking forwards

Its a month now since the Lean & Kanban Conference in Miami and I haven’t had chance to blog about it. There’s probably not much I can add that hasn’t been said elsewhere already. It was an incredible week; stimulating, inspiring, focussed, energising. I learned a lot, and made and met old and new friends. For those who couldn’t make it, the presentations are available for download, and the proceedings book is available to buy. All profits from the proceedings will go towards the formation of the Lean Software and Systems Consortium.

Plans for the equivalent event in London are taking shape nicely. Registration is now open and we have had 40 registrations in the first week so it looks like demand will be high – book early to avoid disappointment! We have a fantastic line-up of speakers confirmed, and the program has now been published. The vision was to create an event which generates discussion and debate with a format that is hopefully a little different from the norm. The mix of presenter talks with interviews is intended to stir up some debate, and the Masterclasses are an opportunity to discuss ideas more interactively with the speakers and fellow attendees – more of a roundtable than a teaching session.

Zurich Lean Agile Scrum Slides

I have posted my slides for the talk I did at the Zurich Lean Agile Scrum event on my downloads page. Inspired by the quality of some of the “Zen” presentations at the Lean & Kanban Conference in Miami, I created a new deck, and included some more slides on some Lean history. I have added some notes to the slides so I hope they have some use for those that weren’t in the room!

The conference closed with a speakers panel, including Ken Schwaber, when the question of “Is Kanban an alternative to Scrum” was asked! Fortunately Ken and I are still friends after the discussion, and the general consensus was that regardless of what we do and what we call it, the primary focus should be on doing the right thing.

Isn't Kanban Just a Task-board?

While the word Kanban comes from the Japanese for “visual card”, the term Kanban as used by the Kanban Software Development community, represents much more than a standard task-board, or team-board. Additionally, the Kanban Software Development community have not tried to replicate the mechanism of the Toyota Production System kanban tool exactly, but have taken the underlying principles in order to achieve similar effects in software development. So what is a Kanban System for Software Development?

A Kanban System visualises some unit of value. This unit of value could be a User Story, Minimal Marketable Feature, Plain Old Requirement or something else. This is different from a task-board, which generally focuses on visualising the current tasks.

A Kanban System manages the flow of these units of value, through the use of Work In Process limits. This is different from a task-board, which generally has no WIP limits, but aims to have all tasks complete by the end of a time-box.

A Kanban System deals with these units of value through the whole system, from when they enter a teams control, until when they leave it. This is different from a task-board, which generally only deals with the work in the build/test stage, but shows no information about what work is being prepared, or what work is ready for release.

By putting these 3 properties of a Kanban System together, we can describe a Kanban System for Software Development as one which allows value to flow through the whole system using WIP limits to create a sustainable pipeline of work. Further, the WIP Limits provide a mechanism for the Kanban System to demonstrate when there is capacity for new work to be added, thereby creating a Pull System. Finally, the WIP Limits can be adjusted and their effect measured as the Kanban System is continuously improved.

A task-board simply shows what development tasks have been predicted to be done in the current time-box, with their status.

Anxiety or Boredom Driven Process Improvement?

At the SPA conference recently, Joseph Pelrine talked about “Flow: The Psychology of Optimal Experience” by Mihalyi Czikszentmihalyi. The ideas behind this struck a chord with me as a way of describing something I originally said when discussing whether kanban is only suitable for mature teams. That is that rather than focusing on being Agile which may (and should) lead to being successful, Kanban focuses on becoming successful, which may lead to being Agile.

Mihalyi Czikszentmihalyi describes the state of Flow as having a balance between ability, and the skills required for a piece of work. If some work requires more skill than a person has ability, then they are in a state of Anxiety. If a person has more ability than the skills required for a some work then they are in a state of Boredom. Applying this to Process Improvement, we want to move teams up the Flow Zone so that skills required and ability increase equally.


Increasing Skills and Ability equally at the same time is unlikely, so in practice there are two routes to move up the Flow Zone. The first is what I am dubbing “Anxiety Driven Process Improvement”. Move a team into a state of Anxiety such that they need to improve their skills to cope. I assert that this is the approach that makes time-box based method so effective. Time-boxing forces teams into a place where they need to improve their skills in order to deliver working software every few weeks. Many teams push back, and a common approach to this is to make the time-box shorter to emphasis the point! The other route is to do “Boredom Driven Process Improvement”.  Highlight to the teams where they need to improve their ability, and allow and support them in doing so such that they are able to taken on work requiring more skill. I further assert that this is the approach that kanban systems take. Visualising queues and work in progress in order expose the bottleneck where the ability needs improving.


This might sound like I am suggesting the time-boxing and kanban are mutually exclusive approaches. That isn’t the case – I have already said that! Instead, I just find it an interesting angle to look at a different dynamic between two approaches.

Kanban and Time-boxes

I had a brief exchange of tweets with Ron Jeffries, Keith Braithwaite and James Shore after the Miami Lean and Kanban Conference ended regarded Kanban and its compatibility with XP and time-boxes. Unfortunately I wasn’t able to follow up immediately, due to an urgent (and eventful) trip to South Beach 🙂 Rather than try and follow up late on twitter, I’ve decided to post my thoughts here to try and clarify my ideas.

The discussion started following a tweet about Kanban being easier to introduce than Scrum. This seemed to be a common theme at the conference, with several experience reports confirming what I have already written about whether Kanban is only suitable for mature teams. This led to the question of how much change (or not) a Kanban approach requires, which is where I jumped in.

A kanban approach introduces tools to visualise and measure queues and work in progress. While this is a change in process measurement, it doesn’t change the process itself. However, having highlighted the existence of queues and work in progress, it becomes easier for the process to be changed to specifically fix the issues highlighted. Thus a Kanban system sets a team up to begin continuous improvement. Time-boxing, used by XP and Scrum, is one way to manage queues and WIP, which is why they can be such effective processes, and why shorter time-boxes are becoming more popular. There are other ways of managing queues and work in progress, however, and thus Kanban is agnostic to time-boxing. This does not mean that XP is Kanban system however, because XP implicitly, rather than explicitly, manage the queues and work in progress.

Further benefits of time-boxing are the focus that they give, particularly given the finite or limited resources (i.e. people) within a team. Time-boxes give this focus not only by limiting the work-in progress, but also by setting the end of time-box as an SLA for when the work will be completed. Again, Kanban doesn’t lose these benefits, but provides for alternate means to limit work in progress and set SLAs.

To summarise, I believe that a Kanban approach is compatible with XP and Scrum in that it has a focus on managing queues and limiting work in progress, but also introduces alternate ways to achieve these goals which can be used alongside the XP and Scrum tools such as User Stories, TDD and Retrospectives.

Calendar and Download Updates

I’m pleased to have been asked to give a Lean and Kanban 101 talk at the Swiss Lean Agile Scrum conference in Zurich on June 4th.  I have added details to my Calendar page.

I have also now uploaded the slides from my “Kanban, Flow and Cadence” presentations at SPA and ACCU to my Downloads page.


Boris Gloger has written a couple of posts on Kanban. While I know Boris is a great ScrumMaster, Coach and Trainer, his interpretation of kanban is wrong in my opinion – although I may have misinterpreted his interpretation! My immediate thoughts were too wide and varied for a comment on his blog, and I was at SPA2009 so didn’t have time for an immediate response, so I made a number of tweets with the #notkanban hashtag.  This post is to follow up those tweets.

Boris says, “We need to tell the development teams what they have to do and we need to make sure that all activities: specification, requirements engineering, development testing will be worked on in exactly the right order, sorry FLOW”.  A kanban system does not prescribe a process (or the activities), but rather visualises the process in order to improve it.

Boris continues, “we need to make sure that all roles in the development team needs to know exactly when the owner of a role can do a piece of work. So they can really focus on their specialization.” He also says “This is definitely not SCRUM or the idea of working creatively together. It imposed specialization”. A kanban system does not insist on imposed and siloed specialisation with handovers, but rather recognises overlapping phases. This is actually closer to the Type C development style described in the New New Product Development Game than Scrum itself, which acknowledges Type C development as a primary source.

Next, Boris says “Development teams … do not need to think anymore. They do just need to work according to plan and we do not have any break in the deliver process anymore”. With a kanban system, teams do think. They should be continuously improving the process and value stream.  As James Shore reminded us (on twitter), Jeffrey Liker said in The Toyota Way that “TPS experts get very impatient… [when people] focus on kanban… kanban is something you strive to get rid of, not to be proud of”.

Boris seems to think that kanban is a process when he says, “So we do have now a very clear focused PROCESS that works much better than all the Scrum Framework”.  However, a kanban system is merely a tool to help visualise an existing process in order to improve it and enable work. It is not something which imposes a process and inhibits work.

Yet Boris also says, “So if we agree that it is a TOOL, that means CARD than we can not explain a way of development as KANBAN”. So yes, a kanban system is a tool, but it is not just having a taskboard with cards, but should also strive to limit work-in-progress in order to improve throughput and cycle time (via pull).

Boris also says, “The terrible danger of this approach is that we put the the thinking about the features before the development”. A kanban system is actually designed to achieve the opposite and not overly invest in features before development as this creates work-in-progress.

Finally, Boris says, “Why do we always look into processess of the manufacture world. Why does nobody tries to see the value of the work-processes that works in companies like PIXAR or IDEO. These are the companies in which creativity and coolness lifes”. A kanban system does not exclude creativity. The team is responsible for the process and the workflow and is empowered to inspect and adapt the system in whatever way it wants in order to maximise the value that it generates.

If anyone (especially Boris) wants to discuss these points (and others) more, then please join the kanbandev list. That’s where I and others are trying to find better ways of using and describing kanban systems for software development.

SPA 2009 Highlights

This week I was at SPA2009. Possibly one of the best conferences I’ve been to recently. Diverse people with lots of great ideas. There are my highlights.

Coaching Self Organising Teams

This was an excellent session but Joseph Pelrine, full of useful and interesting ideas I hadn’t come across before.

  • Behaviour is a function of a Person and their Environment. Thus while we can’t change a person, we can change their environment.
  • Thoughts on the strengths and weaknesses of the popular Forming, Storming, Norming, Performing model
  • An alternative cooking based model: Solidifying, Congealing, Stagnating, Cooking, Burning
  • Understanding Flow, in terms of balancing skills and challenges
  • The Cynefin ABIDE model: Attractors, Boundaries, Identities, Diversity, Environment
  • Social Networking theory

In particular, the ideas around  Flow (“the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity”) resonated with me. While this is different from the MMF based Flow of Value I tend to talk about, I did find some interesting other parallels for thinking about kanban systems. A topic for a future blog post.

Estimation Fallacy

This was a great goldfish bowl discussion around the value of estimation. A recurring theme was trust. Should we spend our time building trust so that we can rely less on estimation, or should we spend our time getting better estimates because we can’t achieve trust?  The output of the session can be found here.

Automated Ajax Testing

This was run by a couple of guys from Caplin, who have an extremely Ajax based Rich Internet Application. They presented their experiences and learning from using Selenium as their automated testing tool.  Their conclusions were that, while Selenium isn’t perfect, when used with its Custom Locator functionality, and a UCD/DSL approach to structuring tests, it can be extremely valuable. A good example of a positive, art-of-the-possible approach to automated acceptance testing.

The session also introduced me to WebDriver, which looks like it could have potential as a new emerging automated web testing tool.

Complex Adaptive Systems

Jurgen Apello ran a thought provoking session on “What’s next for Agilists”? He based his assertions on learning from Complex Adaptive Systems (CAS), so I found it a useful recap of those ideas. It also generated lots of discussion about whether Agile has already applied CAS ideas, whether there are new things we can learn, or whether the ideas don’t apply at all.  The slides can be found on Slideshare.


Probably the most popular topic at the conference was functional programming, and in particular Haskell. One keynote, two scheduled sessions, and at least three BOFs. I went to a workshop on TDD and Haskell, and we looked at an approach to testing a Java application, via the Slim framework using Haskell and Model Based Testing. While I didn’t fully understand all the Haskell concepts, and I’m probably not going to start using the approach on a day to day basis, it was hugely eye opening as a different way of approaching a problem. Another example of smart people being creative and practicing the art-of-the-possible.

Lean & Kanban

As well as running my Kanban, Flow and Cadence tutorial, I was asked to help lead a Lean & Kanban BOF which had a really good turnout. We had some interesting discussion and it was nice to see some interest in looking at being successful from a different perspective.


Finally, there as a special evening event with the Extreme Tuesday Club which involved a panel discussion with some of original XTC crowd. The main point of debate was around how optimistic people were about the future of Agile. Personally, I think there are enough new ideas emerging (e.g. kanban got a mention) and enough people doing great things (e.g. the Selenium and Haskell sessions above) to be optimistic.

Lean & Kanban 2009 Miami Promotion

A new program and pricing structure has been created for the Lean & Kanban Conference in Miami.

There is now a Lean Day and a Kanban Day, each with a single track. The idea behind the new program is that it allows everyone to be able to see all the presentations, as well as enabling people to only come for a single day.  Additionally, there is currently an Early Bird rate until April 13th.

The new pricing is:

  • Full Registration (May 6-8) for all 3 days is $700 (subsequently $800)
  • Lean Day only (May 6), including evening reception, is $335
  • Kanban Day only (May 7), is $295

I’m also pleased to be able to announce a couple of promotions for readers of this blog. Please email me (kjscotland-at-yahoo-dot-co-dot-uk) if you would like to register at these prices.

  1. A Super Early Bird rate of $550 for all 3 days. (Update: Book directly from http://www.leankanbanconference.com/availagility.html)
  2. A Corporate rate, which includes 5 places for the price of 3, at the Super Early Bird rate of $550. (5 places for $1650).

Kanban, Flow and Cadence at the Brighton Agile Forum

I’m going to be talking about Kanban, Flow and Cadence at the Brighton Agile Forum next week on Wednesday 18th March, 7.30pm. The venue is The Skiff, 49 Cheltenham Place.  More details can be found on upcoming.

If you’re in the area, I hope to see you there.