I'm unable to post these roundups everyday so they aren't always as timely as would be ideal. A couple of these blog posts appeared within two hours of me posting the last roundup on June 30th.

Karl Scotland stirred up a lot of debate with his Fifth Primary Practice of Kanban that a goal is to reduce the number of kanban tokens and reduce the overall WIP and cycle time as a result. I agree with Karl though others have stimulated a healthy debate with some dissenting opinions.

David Draper looks at Managing WIP with Scrum and manages to get to pretty much where I'd got to when I published MSF for CMMI Process Improvement in 2006. He's right adding Lean techniques like cumulative flow diagrams and managing the WIP will make Scrum better. And in my opinion, will lead people to go the whole way and adopt a Kanban style approach.

Luminis switched from Scrum to Kanban for a Week at the end of their product cycle as budget ran out and Scrum sprints no longer made sense for the tail end of the project. Sounds like the transition went well. They did the right thing - kept all the engineering practices the same - dismantled the Scrum Sprint bureaucracy and switched to single kanban prioritization scheme and kept the product in a shippable state awaiting the final deadline.

Check out the arrival of Simple-Kanban - another one of the new tools. The guy behind this Stephan Schmidt has been highly critical of me from Scrum-bashing. He seems to struggle with the idea of discussing Scrum's appropriateness. There are too many people with a vested interest in Scrum being appropriate even when it's not. The Scrum philosophy seems to be rooted in the idea, Scrum works, so change your context and adapt to Scrum. That's fine! No one disputes that Scrum works. What many of us dispute is how easy it is to change a context. Kanban is rooted in the opposite philosophy. That changing a context is very difficult and it is easier to adapt incrementally. The mechanism for kickstarting that gradual change is to limit WIP and institute a pull system. The method for taking this approach to change has come to be known as Kanban (with a capital "K"). Apparently, saying this is Scrum-bashing! :-S

Kelly at All About Agile blog seems to be having success with Scrum but reports that Sprint Planning is onerous at times. A fascination with Kanban is building, they the explanation of cycle time left me baffled, Kanban Applied to Software Development: from Agile to Lean. The conclusion that Kanban is easier to adopt on "business as usual" maintenance is clearly correct. When you switch to a full blown Kanban approach on major projects you have to change the whole approach to governance. The traditional project and portfolio paradigm requires estimates and costs to drive plans, commitments and business cases. Kanban takes a whole new approach to risk using option theory. This is a relatively new area and one I'll be presenting on at Agile 2009.

Sylvain St. Germain seems to have received the Kanban and Collaboration message I've been promoting more and more recently and it seems to be resonating with him. Good! We need more people that see this sociological benefit of Kanban and recognize the softer people-centric benefits to what seems like a purely mechanical approach to process. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management