Karl Scotland – Using Agile to Deliver Value
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.
| Print article | This entry was posted by Karl on May 9, 2009 at 3:08 pm, and is filed under Agile. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
No trackbacks yet.
A Pattern for Using Scrum and Kanban
about 1 month ago - 5 comments
I’ve noticed a pattern that I’ve found myself using recently when I’ve worked with new teams that makes use of both Scrum and Kanban ideas. I’ve already said that I believe the two are complimentary, and this should help show how. I’ll often begin with a “Canonical Scrum” implementation. This gives a relatively simple introduction More >
The Flow Experiment
about 1 month ago - 2 comments
I put together a small simulation for the SPA Conference this year which seemed to go well, and which I re-ran at the London Limited WIP Society, and hope to run again. You can download the materials, and this is a short write-up of how it works so people can run it and experiment with More >
Does A Kanban System Eschew Estimation?
about 1 month ago - 5 comments
I was recently involved in a brief twitter conversation which started when Mike Sutton tweeted: estimation is not about the number that pops out. It is about exploring effort and discovering that you don’t know stuff. Paul Dyson responded: spot on! This is fundamentally what I don’t like about the kanban “if people find estimation More >
Aspects of Kanban in Methods and Tools
about 2 months ago - 1 comment
I wrote an article on “Aspects of Kanban” which has just been published in the Summer 2010 issue of Methods and Tools magazine. Download it, have read, and let me know what you think! Alternatively, there is now an html version available.
Kanban and Scrum – Intention and Implementation
about 2 months ago - 3 comments
In my last post I introduced the idea of a PVC System – one which exemplifies Pull, Value and Capability – and closed by posing the question as to whether Scrum could be considered to be a PVC System. In answering that question myself, I realised that there is another distinction which I will describe More >
Facilitating A Kanban Konversation
about 5 months ago - 2 comments
As I mentioned in my Scrum Gathering Musings, I came up with a twist on the Goldfish Bowl format which I used during the Kanban Exploration Deep Dive. Here are some more details. The Goldfish Bowl format works really well for facilitating a focussed discussion with a large number of people. It keeps the active More >
Scrum Anti-Pattern: NOT Prioritising Stories Within Sprints
about 7 months ago - 10 comments
Craig Dickson has published an article on Agile DZone claiming that prioritising Stories with a Sprint is an anti-pattern. He blogged this in December last year, when I noticed it and grumbled on twitter, but no more. Now that its re-appeared on DZone I feel compelled to say something, and that it warrants a blog More >
Process Safeguards and Ski Slopes
about 7 months ago - 11 comments
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 More >
Kanban Trail Markers
about 9 months ago - 2 comments
When talking about Kanban Systems for Software Development, I always try to emphasis that the Kanban System is more than the tool, and is a System that should be owned by the team, rather than being imposed upon it. By owning it, and being part of creating it, a team are more likely to evolve More >
Outcomes and Sync Steps
about 10 months ago - 4 comments
I met up with Jean Tabaka last week for a coffee and we chatted over various things, including Lean, Kanban, “The Don”, Tufte, and Systems Thinking. One of the other areas was around the origins and original intents of Scrum. Jean mentioned an early paper(*) by Jeff Sutherland, written before the current terminology became standard, More >
about 1 year ago
Great. I also think that it can really live together.
about 1 year ago
I have a feeling of deja vue.
Beck in the day I seemed to have a lot of conversations about XP that when something like this:
Them: XP sounds kind-of interesting, except for X, Y, and Z which I can’t even begin to make sense of
Me: well, yes, X, Y, and Z would be fairly crazy, but that’s not what’s recommended, P, Q, and R is.
Them: oh, is that all you meant? That sounds pretty good, but I think you’ll find that your sort of mature, reasonable approach to XP is not what a lot of folks are talking about.
I see the Kanban community running into this syndrome a lot.
What you describe here, Karl, is reasonable and is (for what it’s worth) compatible with XP, Scrum and almost anything else. It’s not very different form what I’m increasingly recommending that my clients do.
And then there’s this sort of thing: “Recently [as of early 2008] I’ve heard lots of discussion about Kanban style development — an approach that breaks that breaks the primary rule of today’s common agile practice: the fixed development time-box.” from Jeff Patton (http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html)
And then there’s all the “vs” and “switch” articles and posts.
Let’s be clear, as I’ve said elsewhere, I personally see fixed iterations as a transitional practice, I’ve seen lots of teams that were unable to deliver turned around by using it—and I know that teams can be successful without it. I worry that in a haven’t-though-about-it-too-deeply Kanban-oriented world I will have to work against a lot of propaganda stating that fixed iterations are a worthless practice.
about 1 year ago
Karl,
Nice peace. I think the concern stems from our the tendency to focus on the methodology rather then the problems teams face and their needs.
I don’t prescribe to a single “brand” of Agile. Over the years I’ve learnt to do what works borrowing bits and pieces from were ever and applying them when and where it make sense.
This in itself is a skill, that takes a fair amount of experience. I’ve done things very akin to Kanban in the past, athough my centre tends to be XP.
I like the way Rachel Davies talks about “Generic Agile”, and the idea of utilising an experienced Coach as advocated in XP. My advice to a novice team starting out would be to follow XP in full on say a pilot project with the help of an experience Coach, and then inspect and adapt from there.
My worry is that a load of inexperienced teams begin applying Kanban off the bat, with little exposure to sound “Agile” technical practices and end up in a worst mess then many Scrum teams today.
If this happens then the Agile gets a bad name and none of us wants to see that.
Paul.
about 1 year ago
I’m with Keith on this one. As I commented in Jeff’s article I feel Kanban done badly is going to be more harmful than Scrum done badly.
That people suggest it is easier to introduce as a concept is no great thing. It’s why Scrum beat XP and why there are a zillion crap Scrum teams out there.
I’m sure Kanban can be successfully implemented on immature teams, but only if the person implementing it knows Kanban and the principles of lean really well. Most people haven’t even heard of Demming or read any of the books around the Toyota Production System so I doubt this will happen very often.
about 1 year ago
“but only if the person implementing it knows Kanban and the principles of lean really well”
I guess the same could be true of anyone introducing any new practice/process/method; they need to know it and understand how to apply it really well.