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.

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.

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.

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.