I enjoyed this well written article. It helped me explore even more about Kanban position into the Agile world dominated by now traditional Scrum and XP. I also like to share my perspective about Kanban vs. Scrum through this small article from my blog http://tsk.ro/2010/07/scrum-vs-kanban-its-like-football-vs-soccer/ . Thanks

I agree with Karl though, I would be very interested in hearing your definition of the Kanban in the middle of the diagram.

I also agree wholeheartedly that the areas in the graph should overlap. I tried a drawing with overlapping and it was unreadable. That’s when I decided to use dashed lines to show where a process style plays best.

I also think areas you created should overlap with each other. There are many projects where at least a few approaches would work well, including non-agile ones, and a specific choice would depend on people in the team, not on organization or project.

What is clearly seen however is how far is maintenance work (support Kanban) from work on a new product (Scrum/Naked Planning). This is where differences between different approaches play their role. I always found time-boxing hard in maintenance teams, especially those with fixed deadlines for applying bug fixes. The same would be probably with production line although I have no experience in the area. But these areas are pretty far from each other and that’s why different approaches would work best.

When we discuss surrounding areas there aren’t as many differences and interchanging, adjusting or mixing different methods would work well. Actually it should be encouraged as I believe you should adjust tools to people, not the other way around.

Marko – You ask a difficult question … maybe you should answer as you are the expert on your process? Overall, this feels like Naked Planning since there is just a big TODO area for team. I would put it more in the direction of repeatable because of the high level of structure in your definition of Ready. Seems like you attain focus through stop-the-line.

I agree with your notion of looking at the long run as I am a believer in Kuhn’s theory of scientific revolution – I believe this is where the origin of paradigm shift comes from although you did not mention it explicitly.

I had a similar reaction to you when I first heard the theory of the 7 year run. I am not saying I subscribe to it or agree with it – I don’t have enough data. My purpose was to share with a larger audience what I saw, heard and digested out of the conference. The timeline sketch I heard is 1990 – Waterfall, 1998 – XP, 2004 – Scrum, 2011? – Kanban. This timeline doesn’t match what I see for Toronto (a bit of a laggard due to banks), however, I can see this matching the story in the U.S. So, perhaps this is more about shift within the Agile community than within the overall industry.

I appreciate the complement on the article.

- Michael

The level of precision is also suspect. When did Scrum “start”, and how will we know when it’s over? Scrum was first mentioned at OOPSLA in ’96, but I hadn’t heard of it until XP burst on the scene around 2000, and many others probably hadn’t heard of it until then, either. Either way, that would mean that Scrum is already long dead, a notion which is supported by neither anecdotes nor statistics ( http://www.indeed.com/jobtrends?q=scrum ) …

I think there is a lot of truth in Scrum, and the truest parts will leave a lasting imprint on our profession, even if the word “Scrum” disappears from our vocabularies forever. And who knows when that will be? Or cares, provided that our industry is changed for the better?

Let me put another bee in your bonnet: 30 years.

At the XP/Agile Universe conference in 2002, I heard Martin Fowler’s keynote speech, where he wondered aloud about whether XP was a paradigm shift. I thought “oh no, I hope not!” You see, I had been hoping that Agile would sweep the industry in the next few years, certainly by ’05 at the latest, but one key thing about paradigm shifts is that they take about 30 years to become widely accepted. The reason is, the old generation has to pass away first.

Consider a previous paradigm shift: Object Oriented Programming. It started around sometime around 1967/68 with Smalltalk. Broad industry-wide acceptance of OO? Late ’90s. About 30 years.

Well, eight years have passed since that speculative speech by Fowler. I have to say, it’s looking like he was right. It looks like Agile coaches have their work cut out for them for the next 20 years.

Note that I am not saying that some people are incapable of “getting it” and you just have to wait for them to pass away. It’s not that they can’t; it’s that they won’t, if you’re not there to explain it. Those that we can reach can be helped, but you can’t walk in uninvited. So, what I’m really saying is that, looking at the big picture, expect invitations from the last hold-outs around 2030, after which hiring an Agile coach will seem about as strange as hiring an OO consultant today.

(I apologize for this being tangential to the main point of the original post. The article as a whole is very good and thought-provoking. Thank you.)

Alan