Tuesday, May 26, 2009

UK Lean Conference Registration Opens

Registration for our Lean & Kanban European Conference is now open. Register now! Please book soon to avoid disappointment. There was a very strong pre-registration interest. We expect the event to sell out very quickly. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban

Friday, May 22, 2009

L&K2009: Speaker Presentations

The speaker presentations from our conference in Miami are now available for public download from the conference website. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban

Wednesday, May 20, 2009

Is Kanban Just a Tool?

Rob Bowley has suggested that treating Kanban as a methodology is wrong when it is just a tool. He seems to be suggesting that Lean is the methodology and questions why we needed to call out Kanban in the title of Lean & Kanban 2009 and UK Lean & Kanban 2009.

Israel Gat has responded to Rob with a thoughput piece titled It’s not What it is that Really Matters!

My response to Rob is that Kanban has evolved as the name (or “brand”) for true pull system implementations in software development. This is as opposed to the application of Lean Thinking to traditional project management or Agile software development and project management approaches. We specifically separated the tracks at the conference to give a day of material for people talking about generic application of Lean Thinking to software engineering, development and project management, while dedicating the rest of the event to people implementing full blown pull systems.

This difference is important. Pull changes everything! When implementing pull, you first have to embrace the concept (or paradigm) of flow. Flow and Pull are two of the 5 pillars of Lean. The other three being Value, Waste Elimination and Continuous Improvement. It is quite possible to adopt and apply the other 3 pillars of Lean without embracing Flow and Pull. Hence, I (and others) perceive a two-speed adoption of Lean in our industry. There are the (yet) few who have embraced all five pillars of Lean and have implemented true pull systems. Those folks resonate with Kanban as a brand -even the folks who’ve developed their own flavors or solutions - such as Joshua Kerievsky, Amit Rathore and Arlo Belshee (with his branded Naked Planning approach.) For those who haven’t embraced flow and pull they are still finding exceptional value in applying other aspects of Lean to their existing approaches. Indeed in the past I created my own Lean approach based on a more traditional agile project management paradigm, the MSF for CMMI Process Improvement method supplied with Microsoft Visual Studio Team System, is based on an Agile method and expands it with Lean ideas to give it coverage of the necessary CMMI process areas. I used to teach a class in MSF for CMMI Process Improvement titled “Lean Project Management” and I gave several presentations on the topic including this one. I came to Kanban and the five pillars of Lean having been down the road of pursuing Agile + Lean and embracing Value, Waste Elimination and Continuous Improvement. I suspect that many others will have to make the journey for themselves. They will eventually get to a kanban based pull system as they gradually add more Lean elements to their base Agile method.

It is likely that the current clear water between the Kanban folks and the Lean applied to Agile folks will disappear in future but for now the differences are significant.

I believe the root of the misunderstanding is in this quote from Taiichi Ohno in his book Toyota Production System

“The two pillars of the Toyota production system are just-in-time and automation with a human touch, or autonomation. The tool used to operate the system is kanban.”—Taiichi Ohno

People see the word tool and they look only at the mechanism of the signalling cards. The fail to see that without Kanban there is no system. Without Kanban there is no Toyota Production System. So if we introduce kanban (small “k”) as a tool to change our process and approach to software engineering should we called it “[Insert name] Development System” and explain that “The tool used to operate the system is kanban.” Which might give us…

“The two pillars of the Anderson Development System are just-in-time feature prioritaztion and automation through continuous integration and quality assurance tests. The tool used to operate the system in kanban.”

Personally, I’d prefer to stick with Kanban (large “K”) as a brand.

I like this quote which gives some clues that Kanban is more than a tool…

“I thought of [kanban] entirely in terms of reducing work-in-process, raising productivity, and illuminating problems. Of course, it is good for all those things. But your basic aim is something else, isn’t it? You use the kanban to create a positive tension in the workplace by reducing work-in-process, and that motivates people to do better than they ever thought they could do.”—Michikazu Tanaka

Kanban pull, visual control and the flow paradigm encourage people to: identify bottlenecks and resolve them releasing greater throughput; identify root causes to impediments blocking flow improving cycle time and reliability; identify waste and eliminate it to improve flow of value; and encourage a whole system view rather than a locally optimized developer-centric view.

As Israel Gat points out, there is now significant evidence that adopting Kanban changes the culture in organizations. It encourages greater cross-functional collaboration and end-to-end value stream collaboration. Alan Shalloway has made the same observation. Kanban does this because it exposes the mechanism. It provides a “white box” approach where Agile methods like Scrum are “black box.” By exposing the mechanism, a workflow controlled by policies, it opens up the discussion about optimizing those policies to maximize the economic outcome. It lets upstream and downstream folks not involved in the development see the effects of their actions. Equally it allows middle and senior management to see the effects of their actions. This encourages empowerment and self-organization by encouraging pushing authority for policies down to the lower levels including individual contributors and by explicitly exposing policies, for example, pull prioritization and class of service policies, it allows the team to self-organize in a control and risk free fashion. Middle and senior management are not afraid of self-organization because the understand the mechanism - the policies in use - and have authority to change those if required. Kanban brings managers into the process while methods like Scrum shut them out and proxy for them with the Scrummaster. Kanban brings upstream partners such as marketing managers into the process rather than excluding them and proxying for them with a Product Owner.

So Kanban (pull) changes the underlying paradigm from project-centric to flow and value-stream centric. It changes the view of development from “black box” to “white box.” It tends to eliminate negotiation and replace it with collaboration. It fully implements all five pillars of Lean. While I talk about introducing Kanban as not changing anything - I mean this at the small level, at the practices, job titles, responsibilities and workflow level. What this message disguises is that Kanban changes the really big important thing - the paradigm under which the work is governed and scheduled. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban

Comparing Kanban to Scrum

Henrik Kniberg has written a white paper comparing Kanban to Scrum, “Kanban versus Scrum.” The connotation of “vs” has had negative side-effects when used on the Kanbandev list so I will avoid it and use the term “compared to” instead.

Mike Bria has posted a response on InfoQ.

While I respect Henrik’s work and it has proved to be both popular and useful to folks in the field trying to make decisions about whether to adopt Kanban or Scrum, I find some disagreement with Henrik’s assessment that both Scrum and Kanban support “pull scheduling” and “limit WIP.”

Kenji Hiranabe and I discussed this point over a year ago before his second Kanban article for InfoQ. I argued and I believe Kenji concurred that Agile methods like Scrum are really small batch transfer push processes. There is no explicit pull system within a Sprint and it’s a stretch to suggest that the batch transfer at the beginning of a Sprint - the selection of the backlog - is a truly “pull” process. It is never described this way. It is described as a negotiation where the team estimate a set of stories that the product owner wants done. They compare the estimate with the previously achieved velocity and decide what can be fitted into the available time in the Sprint. If it were truly a pull system then there wouldn’t be any negotiation. The product owner would have a prioritized backlog and the team would simply pull the top (however many) stories from it and start work.

We could go further and point out that Kanban doesn’t treat the development process as a black box. It is a white box with explicit WIP limits and “pull” happening along the value stream. It’s this that makes it a true “pull” system.

So I don’t agree that Scrum or other Agile methods based on time-boxed iterations limit WIP. What they do is match small batches of work to limited time periods. They limit time, not WIP. The side effect is smaller batches which is a good thing but it isn’t explicit WIP limitation. Meanwhile, they do not truly pull and if we did take the view that Sprint Planning represented pull then at best it is “black box pull” rather than a true “kanban pull.”

The comments on Mike Bria’s article are particularly worth reading and commenting upon. Adron Hall’s comment is for me right on the money…

Scrum still sounds like its for revisionist Waterfall practitioners than Agile"ish” in nature. All of this time boxing, scheduling, planning, and other errata ends in BDUF more often than not. Kanban however, the projects I know of, rarely fall into the BDUF trap and rarely get bogged down or frustrated as many do with Scrum.

Scrum like all early (first generation) Agile methods really do not change the project management paradigm very much. They still use projects as the frame of reference and still have the triple-constraint (iron triangle) of scope-schedule-resources as an underpinning. Agile methods chop the schedule into iterations to mitigate risk and they dispense with the dependency graph tracking paradigm, and take an explicit view on the triple-constraint trade-off - they fix schedule and resources and drop scope if the project is falling behind.

Kanban completely dispenses with the project paradigm altogether. Kanban is based on the paradigm of “flow.” The idea that a (development) team forms part of a value stream which pulls work and produces a continuous flow of value. In Kanban we have initiatives attached to value streams and program management that allocates resources across a portfolio of investments. As I explained in my paper for the Lean & Kanban 2009 conference (extracted from Chapter 21 of my forthcoming book) Kanban dispenses with the triple-constraint paradigm and produces a risk optimal outcome based on class of service pull policies that empower a team to self-organize content for delivery that optimizes value while minimizing risk.

Cloves Almeida’s comment about Critical Chain misses the point.

Critical Chain Project Management is a “straight to project” implementation of TOC and Lean philosophy. It uses much of lean principles like Kanban, but deliver the concepts more practically.

Many folks in the Theory of Constraints community seem to miss it too. They get caught up in “Critical Chain is the TOC application for Project Management” and forget to question whether the project management paradigm is the right approach. The basis of my work since 2002 has been to see software development as a flow problem and to apply the TOC application for flow problems - Drum-Buffer-Rope (DBR). DBR is another variant of a pull system. It is a close cousin of Kanban. The differences between them are quite esoteric in nature. I make some explanation of why I switched from DBR to Kanban in Chapter 2 of my book. The essence of which is Kanban is easier to say, to explain, to adopt, to understand, and is more graceful in recovering for an outage in the bottleneck resource.

So Cloves is correct that Critical Chain is “straight to project” but my argument has been that this is not useful. In my view Critical Chain is what folks like Alan Barnard of Goldratt Consulting call a “symptomatic fix.” It is an improvement on the dependency graph, triple-constraint paradigm of project management. However, the root cause fix is, in my opinion, to change the paradigm. So I disagree with Cloves at quite a fundamental level. I do not believe that Critical Chain delivers the “concepts more practically.” I have discarded Critical Chain from my toolbox and never discuss it with clients. I focus on re-orienting them to the flow paradigm instead. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, TOC, Critical+Chain, DBR

Monday, May 18, 2009

More blogosphere buzz about Lean & Kanban

John Strickler has this thoughtful piece about Lean & Kanban and how he was introduced to Agile via Mary Poppendieck and Alan Shalloway following a background that including reading Factory Physics and learning Six Sigma. Nice to see someone with a background in reducing variation and an understanding of queuing theory talking about this stuff. So few Agile folks seem to understand what I mean when I say Kanban has an underlying model.

Meanwhile, Jeffrey Palermo picks up on my piece for Borland on why you should just say “No!” to an formal Agile transition initiative, Why Agile Transition Initiatives Might Fail!

Margaret Rouse highlights Kenji Hiranbe and I and observes that Kanban is a way to visualize bottleneck in a software development project.

Keith Henry’s been researching how to tailor agile to your organization. While he cites my work on Agile+CMMI he might enjoy my series for Borland more: Agile Transition Initiatives - Just Say No!; Creating an Agile Culture!

Jason Yip rediscovered one of my older gems identifying that liberal versus conservative culture is a bigger influence than high trust versus low trust in driving Agile adoption.

Pascal Van Cawenberghe asks “Why Estimate?” and cites several leading thinkers on this space including Amit Rathore, Joshua Kerievsky and me.

Richard Veryard tickled me with his wittily titled Restaurant at the End of the Universe over at his Demanding Change blog.

Defense Industry Daily was so impressed with my Top 10 rated talk at the SEPG conference that they suggest it’s time to Sharpen Yourself a Kanban System for Software Engineering. Yes indeed! :-D We already have a Kanban implementation with the Danish Department of Defense. I’m hoping for more traction in the defense sector in the next year. I really do hope that Kanban becomes the unifying force that brings the Agile world and the big software and system engineering firms together.

Hillel Glazer noted that my SEPG session on high maturity metrics and Agile was packed and locked out and no one left early. I wonder who I impressed? His notes from Wednesday tell the tale of the Agile + CMMI open space with a super picture of how many people we had at that session and then with another wonderful picture of one of my slides we get Hillel’s take on my Agility & High Maturity talk - naturally Kanban is at the heart of it but Hillel calls it correctly - set high maturity behavioral expectations early and choose metrics and data wisely. His Tuesday notes cover the CMMI + Agile: Why not embrace both talk given by Mike Konrad and supported by Hillel, Jeff Dalton and I.

The folks at Enthiosys (Luke Hohmann et al) have been thinking about Agile maturity models and comparing my work on Agile + CMMI with Bas Vodde and Jeff Sutherland’s Nokia Test.

Allan Kelly gives us a list of 10 Things to Know About Kanban Software Development. Very handy! Allan also helps us to Make Sense of Kanban.

Meanwhile, Boris Gloger describes my use of Kanban as “harmful for software development.” How many people actually doing it believe that? I wonder if Boris has ever tried it? Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, CMMI, Software+Engineering, Project+Management