Recently, with the growth of blog and Twitter traffic about Kanban, there have been several people who've come forward with commentary to the effect that "we've been doing that all the time." Some have left comments on this site. Some have replied on Twitter. Some have blogged.

While I have no doubt that there are teams out there who spontaneously decided that it would be a good idea to set a WIP limit and perhaps to go further and to signal the pull of new work based on completion of existing work, and that they added this concept to their existing implementations of XP or Scrum (or both), this does not mean that XP or Scrum always suggested this. They didn't!

To determine the truth of this we only need to look at the feature sets of the popular tools for managing eXtreme Programming and Scrum such as Rally, VersionOne, ScrumWorks, Mingle and very new tools like Borland Team Focus, to discover that not a single one of these tools allows you to set an explicit WIP limit. None of them provide a pull signal to start new work. Very few of them are even capable of reporting the quantity of work-in-progress.

It is fair to say that Agile methods have encouraged the management of work-in-progress though some methods such as FDD have made this management much more explicit. Stephen Palmer will talk about encouraging the team not to start too many things and to focus on finishing work as early as 1998. However, neither he nor I made the leap to setting an explicit limit or target for WIP. As we learned more about the value of managing WIP, we introduced concepts to encourage and enable it, such as the use of Cumulative Flow Diagrams (a.k.a. Burn Up charts) first posted to the FDD web site in 2002 by me. The Agile Management book appeared in 2003 and the manuscript of an earlier draft was available in 2002 to subscribers to the Yahoo! group. During 2003, I realized that you could influence quality, cycle time, velocity and predictability of the iteration outcome by explicitly managing WIP. I started to focus the team on the WIP and the visualization of the cumultative flow diagram. It was several years later before the Agile tool vendors added Cumulative Flow to their products. What stimulated this was elements of the Scrum and XP community preferring "Burn Up" to "Burn Down." Some had read about cumulative flow on this blog, or in the book or seen me or others present the technique at various conferences. This generated demand and the market responded.

So by 2005 many folks in the Agile community were appreciating the value of managing WIP but they still weren't limiting WIP.

Another aspect of Agile methods we can look at is how they handle impediments or blocking issues. The early Agile literature didn't have a lot to say on this but pointed out that impediments should be raised at a morning standup meeting, or scrum. Again the tools tell the real tale of reality. Very few Agile tools treat impediments or issues as first class work items. Earlier tools such as ScrumWorks only allowed items to be marked as blocked. They did not allow any tracking of the issue behind the block or for any escalation path to be implemented or tracked.

If there had been a real focus in the early Agile literature on blocking issues, impediment removal and their relationship to Lean flow then the tools would have implemented these features.

Meanwhile, Agile teams encountering an impediment would generally mark a story as blocked and go on to another one.

This is not the behavior you would expect on a Kanban team truly limiting WIP. Because the WIP limit will have been reached, an impediment causes idle time. The only course of action available to maintain flow is to pursue the impediment, track down its cause and resolve it. In a truly WIP limited process impediment removal is paramount.

So for those who would claim that Scrum and XP limit WIP and pull new work, such as Stephan Schmidt, I would point them to the feature sets of existing Agile tools. These tools do not impliment WIP limits, pull signalling nor are they particularly good at issue management and resolution. Recently, there are 4 new entrants to the Agile tools market. All of them producing WIP limiting Kanban tools including the same Mr. Schmidt. If earlier Agile methods had been truly WIP limited pull methods then tools from encumbent vendors would already reflect this. As a result there would be no market for new entrants such as CodeMonkeyism, AgileZen, LeanKit and RadTrack. More thoughts on managing WIP versus limiting WIP tomorrow... Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management, Lean