Claudio Perrone posted the following Experience Report to the kanbandev list:

Hi guys,

I’ve been using XP (and then Scrum/XP) for almost 8 years and I’ve fully embraced Lean and Kanban this year, with great results on all teams and organizations that I have been involved with.

As many claim here, I found that Kanban, in particular, has a lower barrier to adoption (I consider it a “non-disruptive enabler”, at least in apparence), it is applicable to a wider set of scenarios, and can be used to train teams on problem solving and root-cause analysis as soon as problems arise.

“Walking the board” on a daily standup (that is, focusing on work in progress rather than on the people doing the work) is an excellent device to enable this form of problem solving and team communication.

In my coaching experience, I found very effective to refrain to give all the anwers in advance. I often let issues emerge, and ease teams into “interpreting the board”. When a WIP limit kicks in, the typical initial reaction by some members is to ask to raise the WIP threshold. That is seldomly the right answer to the problem and soon other solutions arise (story too big or unclear deliverable, need more help, unaddressed impediments, etc).

As many people may agree, retrospectives can also be very effective to improve the way teams work (or even save entire projects!). I alwasy found very beneficial to stick retros within a cadence (in either SCRUM or Kanban) and never bought into the fad of JIT them or even dear considering them “waste”.

Is it all good? Well, yes. But I have one burning issue.

In sharp contrast with RUP or waterfall approaches that I used before embracing agility, I always find one specific benefit of SCRUM/XP timeboxes (when applicable): they boost creativity by forcing teams to find simpler solutions that can fit an iteration.

Yes, timeboxes are self-inflicted “artificial” constraints, but they are exactly the reason why, years ago, I learned to provide value by  focusing on the needs and outcomes rather than simply developing what the customer asked for as fast as I could.

Now that I learned such good habits, I’m not going to drop this approach of course ;-) Having said that, I’m not sure that focusing on improving average Lead Time alone automatically pushes a team into deliberately find cheaper/simpler/better alternatives.

Do you guys have any thoughts/suggestions?

All the best,

Claudio