Thursday, July 16, 2009

Kanban Blogosphere Roundup July 16th

Jim Benson has been busy posting his continued series on Personal Kanban. He summarized a number of Approaches to Personal Kanban and then drilled down offering us The Time Capsule Approach and The Throughput Approach. This is demonstrating that there is no one right approach to Kanban. The core is a WIP limited pull system. Beyond that, you get to make your own rules. I hope that Jim’s posts inspire you to innovate with Kanban. Feel empowered! It’s not about copying what someone else has done. Kanban is about is defining policies that make sense in your unique situation.

Lee Brandt reminds us that Kanban is not a Methodology (at least not a software development lifecycle methodology) and as he suggests, neither is Scrum. Where I disagree with Lee is that Kanban clearly is a methodology. It is a methodology for managing change and enabling continuous improvement. There is a body of methods, rules and postulates. These are relatively simple in the core of Kanban. The rules are that you limit WIP, you provide visual control and visual signaling, and the postulation is that this will reduce variability in cycle time, improve predictability of delivery, improve quality, delay commitment, keep options open, improve risk management, encourage collaboration, and increase social capital across the value stream. In addition, as Jim Benson is showing us, you can choose to supplement the core rules and methods with your own context specific set of rules and methods to further enhance the postulation and better manage risk, encourage collaboration and so forth in your specific situation. So, to conclude, I agree with Lee, Kanban is a not a software development lifecycle or project management methodology but to agrue that Kanban is not a methodology at all would be wrong. The subtitle for my forthcoming book about Kanban is “Successful Change Management for Technology Organizations.” From this you might deduce that I am positioning Kanban as a change management methodology.

Eric Ries has posted a fantastically thorough review of Donald G. Reinertsen’s new book, The Principles of Product Development Flow. Don was perhaps the single biggest influence on my work and the instigator of the chain of events that led to kanban systems for software engineering. Don’s new work was 12 years in the making since his seminal Managing the Design Factory which greatly influenced my first book. Read Eric’s review then go buy Don’s book. Better still come to the UK Lean Conference and meet Don in person.

Yuval Yeret shared his Scrumban - taking Scrum out of its comfort zone slides from the Israeli Scrum User Group event this week. It’s great to see this. I think Yuval shows great courage and I hope his audience are open-minded enough to give his thoughts a fair hearing.

Ralf Rottmann posted a thoughtful and thorough review of Agile Zen, In Need of a Really Lean Project Management Solution? Love the screen shots in this review.

Si Alhir posts his idea of The Purposeful Enterprise. He references a lot of heavy management science including Gary Hamel and some lighter weight management ideas from Seth Godin and distills out the notion that Communities, Collaboration, Kanban and Tribes all below together in the same salad bowl. The actionable advice comes in the last paragraph with the advice that we need to foster tribal leaders who in turn should be either value champions or innovation champions. I’d like to see him drill down on these ideas a little further and explain what he means and how these roles would interact and how we might go about developing such individuals.

Mark Stringer uses his blog to provide feedback on Karl Scotland‘s Kanban, Flow & Cadence presentation at the mini-SPA event in London this week. Unfortunately, I just don’t buy Mark’s arguments. He clearly doesn’t buy into the concept of “economy of scope” and the essence behind domain modeling and software product lines. It’s quite clear to me that there is a lot of re-inventing the wheel going on in software development. It’s also clear to me that the effort required to develop unique pieces of software can be understood and modeled. In one of my classes I ask, “How long does a tennis match take?” People shrug. After a few minutes they agree that 5 minutes is too short but 5 hours is unlikely. After a few more minutes they develop a model with a mean and a band of variation. They suggest that perhaps 45 minutes is at the low end and 4 and half hours at the higher end with perhaps 1 hour and 45 as a mean. They then suggest that they could research the answer from historical data. Try the same thing with a set of developers but replace the words “tennis match” with “web part” or a similar technology component and see what answers you get?

Mark’s next suggestion that we Karl and I (and others in this community) are suggesting that we use Toyota’s solution to a software development problem is also wrong. See my earlier comments in this roundup. Kanban is a change management methodology where you supplement the core rules with a set of rules adapted to your context. Jim Benson is showing with Personal Kanban how you can have differeny sets of rules to produce differents types of outcomes. Pick the rules to suit the outcome you want. Don’t copy someone else’s kanban system blindly.

Finally, Mark provides Karl with some useful feedback that clearly he isn’t communicating the meaning of cadence. Cadence isn’t about variable length iterations but about regular delivery and regular prioritization. It’s about puting some certainty around the coordination activities required to add new work to the software development backlog, and to release newly completed work to the customer.

Mark does remind me that I published some considerable advice on calculating iteration length. I included this guidance in the MSF for CMMI Process Improvement process template shipped with Visual Studio Team System. I have also taught it in my Zen of Agile Management class since the spring of 2006. Mark also reminds me that I’ve never articulated this on my blog or in an article in a particularly consumable fashion. The closed I came was in June 2006 with these two articles Manage Value Creation not Effort Expended and Process Batch and Transfer Batch. These are a poor replacement for the detail in the class where I teach participants how to assess the transaction and coordination costs involved in a transfer batch in order to determine an appropriate iteration length. For a more thorough mathematical analysis read either of Reinertsen’s books, Managing the Design Factory or Principles of Product Development Flow.

And finally today, it seems that Agile Tester likes Kanban, How to Measure QA Velocity? It appears that the kanban limits are Sai’s friend. They help avoid overloading the testing team. Yes, indeed! Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management