In February, March and April I'll be repeating my highly successful Kanban Coaching Workshop from London this October. These coaching workshops are designed for experienced agile, project management or process coaches and consultants who are looking to add Kanban skills to their toolbox of offerings. This intensive 3 day collaborative workshop is designed to enable participants to go out in the field and successful implement Kanban and Lean with their teams and client firms. Attendees will receive a recommendation from me that they can use with clients and will be listed on my (yet to be published) "trusted Kanban coach" web page.

You can't learn everything about Kanban in 3 days but those attended in London learned lots of ideas and gained the benefit of lots of experience that will enable them to make significant and valuable progress with clients.

Read what Rachel Davies had to say after attending the London workshop.

In February I'll be facilitating two workshops. The first in Cape Town, South Africa with Scrum Sense, Feb 5-7, and the other at the Conrad Hotel in Miami, Florida February 22-24.

In March, I'll be giving my only European coaching workshop in the first half of 2010 in Stockholm with Crisp. Check out crisp.se for details. Email me if interested in attending meanwhile. I also hope to announce a similar coaching workshop in Brazil, most likely Sao Paulo, March 8-10. Email if interested in attending.

In April, I'll be facilitating another north american workshop in Orange County, California, April 14-16. [venue to be announced soon]

Attendance at my own events in the United States is strictly limited to 8 participants to maximize the quality of the discussion and learning opportunity. So far we have 4 confirmed attendees in Miami, 4 others tentative but uncommitted. So there are 4 places open. Please book soon if want to attend this event. The Orange County workshop has some more possibilities with 3 confirmed attendees and 3 others currently tentative. Please email if you are interested but not ready to sign up immediately.

In addition to these 5 open workshops, I am also holding a closed private client workshop in Seattle in January 2010. If you'd like a closed Kanban coaching workshop at your firm, please get in touch via email. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Project+Management, Software+Engineering, Process+Improvement, Change+Management

I'm teaching a few Kanban classes over the next two months in Europe and South
Africa.

[December]
The first of the 2 day classes in Stockholm with Crisp next week

[January]
Followed by a class in Krakow, Poland and another in Paris, France with Octo

[February]
I'm then heading down to South Africa from Paris in early February for a class with Scrum Sense in Cape Town.

[May]
Week of May 3rd class in Israel to be announced soon. Email for more details.

These 2 day events are aimed at Kanban beginners and team members from companies
trying to adopt Kanban or thinking about alternatives to existing agile or
traditional approaches to change and improvement. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Project+Management, Software+Engineering, Process+Improvement, Change+Management

The first Lean Software & Systems Conference will be held in Atlanta, Georgia, USA between April 21st and 23rd 2010.

Registration and the Call for Papers is now open at atlanta2010.leanssc.org

The first 50 registrants enjoy a super early discount rate of $800 plus entry to the exclusive speaker luncheon and a special limited edition Ltd WIP Society t-shirt, sponsored by David J. Anderson & Associates.

The Call for papers closes on December 14th.

Use the Twitter search tag #lssc10 to filter tweets about the event. Follow @lssc10 on Twitter for news from the organizing team.

If you are speaking or attending the conference you might like to tell people about it by adding these buttons to your web site design. If you want to use these assets on your site just paste the HTML code provided straight into your web source code or content management system.

Source: <a href="http://atlanta2010.leanssc.org/"><img alt="Atlanta 2010 Attendee" src="http://www.agilemanagement.net/lssc10/Atlanta2010Attendee.png" border="0" /></a>

Source: <a href="http://atlanta2010.leanssc.org/"><img alt="Atlanta 2010 Speaker" src="http://www.agilemanagement.net/lssc10/Atlanta2010Speaker.png" border="0" /></a>

Conference Chair: David J. Anderson

Track Chairs: Alan Shalloway, Joshua Kerievsky, James Sutton, Eric Willeke, Chris Shinkle, Richard Turner & David Anderson

Event Planner: Kelly Wilson
Organizing Sponsor: Software Engineering Professionals (SEP)
Event Team: Dennis Stevens, Janice Linden-Reed, Aaron Sanders, Eric Landes

Sponsorship opportunities email info@leanssc.org

This week at QCon I am launching a new Limited WIP Society supporter T-shirt design. The new design is also available as a button that you can place on your web site to show support for the adoption of Kanban.

If you want to use these assets on your site just paste the HTML code provided straight into your web source code or content management system.  

Source: <a href="http://www.limitedwipsociety.org/"><img alt="Go Lean Limit WIP" src="http://www.agilemanagement.net/ltdwip/GoLeanLimitWIPOrange.png" border="0" /></a>

Source: <a href="http://www.limitedwipsociety.org/"><img alt="Go Lean Limit WIP" src="http://www.agilemanagement.net/ltdwip/GoLeanLimitWIPGreen.png" border="0" /></a> 

Source: <a href="http://www.limitedwipsociety.org/"><img alt="Go Lean Limit WIP" src="http://www.agilemanagement.net/ltdwip/GoLeanLimitWIPBrown.png" border="0" /></a> 

 Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management

This presentation from the Software Engineering Institute's SEPG 2009 conference in San Jose was voted one of the top 10 best at the event. In it I synthesize experience from team with Kanban and the CMMI model. I make the observation that some teams using Kanban to drive change towards improved agility have also exhibited accelerated achievement of model level 4 behaviors.

[Download the slides 7MB PDF]

David Joyce has posted a quite remarkable blog summarizing the results at BBC Worldwide since they introduced the use of Kanban, to drive process improvements, one year ago.

Improved Predictability as well as Business Agility

Many people will review this post and look only at the data. As David himself summarizes, the average lead time fell by 8 days from 22 to 14. This does demonstrate improved business agility, a 33% drop in lead time is not to be sneazed at. However, the more careful viewer will observe the dramatic drop in the spread of variation. The upper control limit drops from 70+ to well under 40, almost a 50% drop in spread. What this means is that the team is much more predictable in delivery of new functionality. David is also verifiying that the newer data shows genuine special cause variations outside the limits. While he isn't stating categorically that the system is stable, in an SPC sense, as there may be some special cause variations hiding inside the limits, the performance shows a dramatic improvement in stability since Kanban was introduce. This is further evidence that the team is performing in a much more predictable fashion. It also implies that the team ought to be experiencing a much smoother working environment with far fewer events that randomize their schedule and distract their attention away from immediate customer-valued work.

Evidence of Little's Law Cause and Effect

The chart for development cycle time shows direct evidence that Little's Law is true and that the quantity of WIP has a direct causal relationship with cycle time. The mean drops from 9 days to 3 days but again the spread of variation drops even more dramtically from 31 days to 7 days. Again this is evidence that the team has much greater predictability. Reducing WIP not only reduces cycle time but it dramatically reduces variability too.

The Engineering cycle time chart simply reflects more of the same. Reducing WIP and the policies of Kanban and its expectation that blocking issues will be escalated and resolved quickly has a dramatic effect on both lead time and variability and shows significant measurable gains in both business agility and predictability as a result.

Improved Configuration Management Discipline and Reduced Deployment Transaction Costs

The Throughput chart doesn't tell us how much value is being delivered but it does show a dramatic increase in the number of releases to production. This rises from one every one or two weeks before Kanban to one almost every working day since Kanban was introduced. To make this possible there must have been an improvement in configuration management discipline and capability and an equal reduction in the transaction and coordination costs associated with a release. This is all indicative of an organization that is maturing and improving in capability as well as an organization that is considerably more "Lean" than it was a year ago, as waste associated with making a release has dramatically reduced.

Bugs decrease with less WIP and Improved Organizational Maturity

The final chart showing defects per week shows that quality did not suffer as a result of introducing Kanban and limiting WIP and that after some time for changes to kick-in that might be associated with an organization growing in maturity and capability the variability in the defect rate dropped dramatically with a small decrease in the mean number of bugs per week. Again this indicative of an organization that is much more predictable.

Conclusions

David is using the SPC charts as report cards. In Donald Wheeler's scale of adoption of SPC, this is the lowest level of maturity, and SPC as report cards doesn't fully qualify as quantitative management associated with level 4 in the CMMI model. However, we can conclude that this team exhibits significantly improved performance. They exhibit significantly lower variability and greater predictability and any use of SPC indicates a leadership that is determined to drive process improvement in a quantitative fashion. There is significant evidence of behaviors associated with CMMI model level 4 and this growth in maturity has been achieved in only 12 months.

This seems to be further evidence to back up my claims from my SEPG North America 2009 presentation that Kanban is proving to be a method that leads to accelerated organizational maturity and catalyst of organizational process improvement. We've now seen two teams at two significant companies in London adopt statistical process control and show significant progress towards higher maturity behaviors and performance. Perhaps it isn't a coincidence? Hopefully we'll see more like this emerge from the Kanban community over the next 12 months.

I'll be holding my only Kanban class in North America this year in San Francisco on November 16-17. The two day class is now divided into 2 parts:

• Day 1 - Mechanics of Kanban
• • The first day focuses on case studies, theory and exercises to map a value-stream, model a flow and design a kanban board, identify work item types and classes of service and set WIP limits
• Day 2 - Kaizen
• • The second day focuses on creating a Kaizen (continuous improvement) culture in your organization and using Kanban as a catalyst of change. Attendees will learn how to identify improvement opportunities managing bottlenecks, reducing waste, and reducing variability. They will also learn how to choose and use appropriate metrics to drive change and measure improvement together with an understanding of organizational maturity and how Kanban accelerates the achievement of higher maturity behaviors such as quantative management, causal analysis and resolution and organizational innovation and deployment

Register Now! Both days at the San Francisco State University Downtown Campus for just $1300.

I'm going to be touring Europe over the next 3 months giving a series of Kanban classes. These 2 day classes will give you the knowledge to understand what Kanban is all about, why it's important and how it might help your organization. You may be surprised to learn that it is a lot more than just puting a few story cards on a board. Kanban is about enabling evolutionary change with minimal resistance. It's about learning how to set and change policies that constrain performance and hold back organizational effectiveness. It's about learning how to empower people without loss of control - to make self-organization an organizational discipline and effective capability. It's about learning how to make objective decisions that optimize business outcomes.

You can read more about the class here.

Participants in the classes will learn how to use the simple process of limiting work-in-progress as a driver of change. Kanban is a change management method and a different approach to striking agreements between IT and the business. Kanban is about making promises you can keep and reaping the rewards of the trust divide that delivering on your promises enables. Kanban enables you to say "Yes" without compromising your core values of sustainable pace, craftsmanship, high quality, integrity, agility, and economic benefit.

To do this you'll learn how to define the policies that constrain the collaborative game of software development. You'll learn how to use those policies to manage risk and to reset negotiations and recast them as collaborative problem solving. "Yes, we can do that... Now how would you like to change things to accommodate this decision?"

Used effectively, Kanban will change you and your organization. If your workplace has been stagnating and you are looking for new ideas to unleash innovation, collaboration and creativity take 2 days of your precious time and come along. Find out what all the fuss is about!

I'll be in...

Stockholm September 24-25 (Crisp)

London October 1-2 (Skillsmatter)

Frankfurt October 5-6 (IT-Agile)

Brussels November 23-24 (ACA IT)

Utrecht November 26-27 (ACA IT)

There has also been suggestions of me coming to Denmark, Poland and France. If you'd like to me to run a Kanban class in your country, please get in touch.

I've made my slides for Agile 2009 available in the document archive of agilemanagement.net for everyone who attended or not to use. The great news is that Ryan Martens is interested in applying these ideas at Rally Development already.

I should also mention that my 3rd technique in these slides is similar to Todd Little's model which appeared in the recent book, Stand Back and Deliver! The model uses four classifications of projects that Todd calls Sheep Dogs, Colts, Bulls and Cows. The Cows are analogous to my Cash Cows, Bulls to Major Growth Market and Colts to Innovative/New. If there is a difference it's that my model is entirely market driven / external while Todd considers a complexity a dimension in the classification. These models are so similar that I will consider merging mine with Todd's with full attribution.

Chris Matts' believes that my first technique, previously published here in 2005 is similar to but less useful than Neil Nickolaisen's model also published in the recent book, Stand Back and Deliver! Neil's model maps projects at a portfolio level into 4 categories via a 2x2 matrix or dimensional assessment of market differentiation and alignment with corporate mission. He calls the segments: Don't Care; Partner; Differentiating; Parity. While this model is certainly compatible with my model they are not the same. Neil's model works at the project and portfolio level and assumes that the corporate mission is somehow correctly aligned with a strategic position and the market demands. My model works at the individual feature level and is again directly market facing insuring that the feature mix chosen for a project or iteration are aligned with the strategic positioning of the business and the allocation of types is aligned with the propensity for risk in the business plan or prospectus. Neil's model is certainly compatible with mine. If for example, a project initiative assessed as "Parity" but the product owner was picking a lot of "Differentiator" class features for the product mix then there is clearly a miss match. So I believe that Neil's model could be added as a fourth technique to the three presented here.

However, it's worth noting that these are tools that can be used as choices and are not necessarily all designed to be used together. My 3rd technique, like Todd's and Neil's are designed to allocate resources to control commitment to projects across a portfolio. To spread risk effectively. It may not make sense to use more than one of these techniques at any one company or division. Choose the one that resonates best with your organization. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management, Risk+Management, Risk, Portfolio+Management, Program+Management

I've uploaded a PDF of my slides for Agile 2009.

Download New Approaches to Risk Management PDF

Here is the original session submission...

Presenter: David J. Anderson

Title: New Approaches to Risk Management

Background

----------

For almost a decade the agile community has claimed that agile development is a risk-driven approach. Yet there is very little published material on agile risk management. A survey of the transactions of the Agile conference over 4 years reveals no explicit presentation on risk management. An online search reveals a number of blog entries and articles on agile risk management(of which more later.)

Traditional risk management (defined in the PMBoK, Prince II, CMMI and other frameworks) takes an event driven approach to risk. It seeks to model external variations that affect schedule, budget and scope on projects. Traditional risk management focuses on what Walter Shewhart called "assignable cause" variation [Deming renamed this "special cause".] The model is simple: try to build a list of external events that might occur; assess the impact and likelihood of occurrence; assess the cost of mitigation options; decide whether to mitigate (reduce chance of occurence) or create a contingency plan (to recover in the event of occurence.)

Most of the agile risk management articles surveyed look at how to implement traditional risk management in a more agile way. They address how to fit risk management into iterative, incremental development and how to assess and manage risks in a collaborative, transparent manner. There appears to be no literature that discusses how to apply agile and lean ideas that revolutionize risk management.

Meanwhile, traditional (non-agile) project scheduling techniques treat all tasks homogeneously from a risk management perspective. Elementary scheduling techniques do not account for variance in task completions, e.g. the Gantt chart technique. More advanced techniques (PERT, Critical Chain, Last Planner) account for variation and provide some risk mitigation against chance (or common) cause variation through time buffering. However, these techniques still tend to treat all tasks homogeneously from a risk perspective.

Project risk management literature does not appear to have advanced much in the last 30 years.

New Approaches

--------------

The application of Lean pull systems (kanban) and Real Options Theory in agile methods is providing new sophisticated means to manage overall business risk in technology projects and software delivery.

This tutorial will describe in detail 3 techniques that have evolved in the kanban community that provide improved project flexibility and business agility together with increased sophistication in risk management.

(1) Using classes of service based on cost of delay/failure functions

Classifying customer-valued deliverables according to the cost of delay (or failure) function allows for different prioritization policies to be implemented on the fly by self-organizing teams significantly reducing the business risks of late delivery. This scheme classifies customer deliverables such as user stories heterogeneously according to the loss incurred due to late delivery. Assigning different colored sticky notes, or index cards according to the classification allows team members to quickly assess risk and pull the most important item through the system in a self-organizing manner

Four example classes of service will be discussed along with their related pull system policies (for prioritization and scheduling) will be presented. The examples are: expedite; fixed delivery date (unit step cost of delay function); quantitative value delivery; and qualitative value delivery. Other classification schemes are possible and would be domain specific.

(2) Iteration Backlog selection based on market risk

This scheme allows for classification of customer-valued deliverables into 4 categories that are aligned with strategic planning and marketing objectives, namely: commodity (or table stakes); differentiator; spoiler; and cost saver. Features or user stories in each category exhibit different risk of change (deletion from scope, or change in definition) due to market conditions during the lifetime of the project, prior to release. The variance in market risk can be used to quickly prioritize iteration backlogs and target backlog items for iterations within an overall project schedule. The scheme mitigates the risk of rework (or waste) caused by changes in scope associated with changing market and business conditions.

(3) Risk-based Portfolio Management

This scheme allows the balance of resources and funding across a portfolio of projects or business initiatives based on the alignment of a project or development initiative with the strategic positioning of the business and its desired risk exposure.

Projects can be classified in to 3 categories: cash cow; mainstream developing market; and emerging market. Portfolio management is conducted similar to investment portfolio management by balancing investments and risk according to the risk preference of the investor. Hence, cash cow is analogous to bonds in an investment portfolio, mainstream developing market, is analogous to large cap stocks, and emerging market to small cap stocks. Resources and funding are allocated according to desired risk profile and kanban systems established for each line of business (or business initiative). Market releases (or projects) are defined to release value optimally based on transaction and coordination costs of making such a release.

Summary

-------

These three techniques combine elements of Lean Thinking and Edwards Deming's New Economics (cost of delay/failure functions, waste (transation and coordination costs, rework or scrap)), Real Option Theory and Decision Tree analysis to provide methods that enable simple, fast, and often self-organizing approaches to maximize business value and manage risk throughout a portfolio and the project lifecycle.

Notes

-----

Most of this material has been previously presented anecdotally as part of presentations on kanban. Some of it has been documented at agilemanagement.net as blog posts. However, this tutorial will pull it all together, formalize it as a risk management approach and refine and develop some of the ideas.

The material is therefore new in this format but based on work and presentations given over the last 2 years.

The presentation will likely be trialed at various smaller venues prior to Agile 2009. In the first instance at the kanban conference in Miami in February 2009 to an audience of perhaps 50 people. Other opportunities of rehearsal performances will be available at local events such as the San Diego XP Users Group in May 2009.

I intend to submit a formal paper for the transations.

Reference Material

------------------

Survey of online articles on agile risk management

Appelo, Jurgen, http://www.noop.nl/2008/06/agile-risk-management.html

Cottmeyer, Mike, http://blog.versionone.net/blog/2008/05/agile-risk-mana.html

Cottmeyer, Mike, http://blog.versionone.net/blog/2008/05/agile-risk-ma-1.html

Cottmeyer, Mike, http://leadinganswers.typepad.com/leading_answers/2007/09/agile-risk-mana.html

Fitzgerald, Donna, http://www.cutter.com/research/2006/edge060711.html

Griffiths, Mike, http://leadinganswers.typepad.com/leading_answers/2007/09/agile-risk-mana.html

Rangaswami, JP, http://confusedofcalcutta.com/2007/07/06/how-risk-management-affects-agile-approaches/

Smith, Preston and Roman Pichler, http://www.ddj.com/architect/184415308

Thomas, Steven, http://www.itsadeliverything.com/articles/agile_risk_management.htm

After some delay while we arranged for hosting, the videos from the Lean & Kanban 2009 conference in Miami are now available.

I need to thank InfoQ for making all of this happen. As a media sponsor, InfoQ intended to use these videos together with the presentation slides on their own site. However, the videographer didn't follow their format instructions and the result was that they couldn't use them. So after some editing and cleanup they donated them to the community - in this case the Lean Softwae & Systems Consortium.

As a sponsor of next year's Lean Software & Systems Conference, Software Engineering Professionals (SEP) kindly offered to host this year's videos.

View now! Technorati tag: Agile, Lean, Kanban, Software+Engineering, Project+Management

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

For some time now (at least since May 24th) Alistair Cockburn has been expressing a dissenting view about Kanban and the value of imposing WIP limits. I'd like to quote a number of his tweets on the topic. These are quotes from May 24th to 28th. You can follow Alistair on Twitter @totheralistair.

in reply to @ponderings Agreed - might call w limits "Kanban for Kindergardners" vs w/o limits "Kanban for Grownups". Why not treat them as adults?

in reply to @bellware What I'm saying is that WIP limits enforce (read: replace thinking) what simply observing would give you, but triggers stoppages.

continuing... @bellware Indeed - and you don't need to back up the assembly line to get that. WIP limits are muda.

in reply to @bellware @davengeo WIP limits are training wheels --- I say this in part to provoke thinking, partly cuz it may be true

and again @bellware I suggest you try removing WIP limits and use your eyes and brain instead of backed-up Q to notice bottlenecks

While Alistair's dissenting voice is welcomed and I believe healthy as a challenge to the emerging Kanban community, these tweets can't go unanswered. Alistair carries a considerable stature in the industry and snappy soundbites such as these tend to get repeated without depth of understanding.

I like to give Alistair the credit for being the first person to observe that Agile Software Development is a Collaborative (or Cooperative) Game. A game in which the outcome isn't zero sum and in which the players muct cooperate rather than compete to maximize the outcome. It's interesting then that Alistair doesn't appear to have recognized that introducing WIP limits is introducing a new rule (or set of rules) to that collaborative game.

What we've come to recognize is that the introduction of WIP limits forces conversations to happen that were not happening before, and the derivative mechanisms resulting from WIP limits such as prioritization meetings and selection mechanisms, impediment escalation and a focus on flow to both shorten cycle time and improve predictability encourage collaboration and cultural change for the better, that was not present even with first generation Agile methods.

Alistair suggests that WIP limits are waste. The facts are that we started with no limits. Then we introduced the concept of managing WIP and controling it so it doesn't spiral to infinity. Several people who tried this seriously in the mid-naughties (circa 2004-2006) soon realized that managing WIP helps and if managing it helps wouldn't limiting it be both simpler and create greater freedom. [For example, Sterling Mortensen at HP.] Limiting WIP eliminates the coordination costs (management overhead) or "waste" of having to manage WIP. Limiting WIP enabled work-in-progress to become self-organizing. So WIP limits don't add waste they remove waste. They free managers to worry about more value-added activities.

Alistair also suggests that WIP limits are for children while adults can do just fine without them. Again, this is in denial of the reality and history. Traditionally, we haven't limited WIP. In fact, the concept of WIP wasn't even in the paradigm of project management or software development until this decade. So plenty of adults have been struggling with managing WIP without limits for a long time. [In the HP case study they discovered they had almost 5 years worth of WIP before they started to manage it.] Alistair suggests that we don't need WIP limits to see bottlenecks or other stoppages (impediments, blocking issues). And while this is true, we need to look at the facts and how well we as an Agile Software Development community are doing with that.

The reality is that most Agile Project Management tools struggle to show blocked work and do not treat blocking issues as first class objects. There are no features for escalation and no features for reporting quantity of work blocked, time blocked, who the issue is assigned to or what they are doing about it. The tools vendors are only just catching up with this kind of functionality. There has been little emphasis on prioritizing the removal of blocking issues or resolving stoppages. Why? Because before Kanban they weren't treated as stoppages. They were treated as work that could be put aside while something else was started. Adding WIP limits has helped the adults change their focus onto issue management and resolution to keep things flowing, rather than keeping busy. I blogged at great length on this topic last month Managing WIP isn't the Same as Limiting WIP Part 1.

What about bottlenecks? Well the introduction of cumulative flow diagrams (later called burn up charts by some of the Scrum community, and also known as finger charts) in 2002 was slow to catch on. Some tools vendors did provide limited support for CFDs but guidance on how to read them and use them was limited pretty much to anything I published until very recently. One developer at a major Agile project management tool vendor only recently tweeted that his product was finally "all pimped out with a CFD." So what about simply walking the floor and asking "where is the bottleneck?" Well generally that wasn't happening either. If teams were managing bottlenecks then lots of people in our profession would have slack time because they aren't working in the bottleneck station. As a result the 40 hour week or sustainable pace would be commonplace among Agile teams and across our industry, but it isn't! The guidance on Lean and flow and how to see bottlenecks with CFDs and what to do about them with TOC has been widely available since 2003. The reality is that it hasn't been happening. When we introduce WIP limits and adjust them correctly, bottlenecks manifest themselves and the effects are felt immediately. The organization recognizes the bottleneck for its true impact and something gets done about it. This behavior is becoming much more commonplace with Kanban.

WIP limits are for adults! They are for adults that care about sustainable pace, flow, throughput, and process improvement. They are for adults that care about increased collaboration and cooperation and a higher trust more empowered workforce and culture in the workplace. WIP limits are surprisingly empowering! It's interesting that a constraint can be something that makes you free! WIP limits are a new rule in the collaborative game that is Agile Software Development. Its a rule that empowers people, treats them with respect, increases social capital and collaboration in the workplace and focuses organizations on improving their process for long term benefit. WIP limits enable "stop the line." They enable the Lean concept of the pursuit of perfection by encouraging a focus on process improvement.

When asking whether WIP limits are for beginners or experts ask those who are actually using the technique whether they could imagine going back to merely managing WIP or worse not bothering at all? In my kindergarten example from yesterday, could you imagine the chaos that would be introduced by removing the WIP limits? Even if it wasn't chaos how much wasted time would be spent negotiating and agreeing acceptable limits of children at each workstation? How much effort would be wasted resolving disputes with arbitration?

WIP Limits are a new rule in the collaborative game of Agile Software Development. Adults use them to eliminate waste! Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management, Alistair+Cockburn

My younger daughter's pre-school uses a kanban system. I'd been staring at it for months without realizing it was a kanban system and after I did I was troubled by the fact that it wasn't a pull system. So I had to think about it a bit.

First an explanation

The board is laid out into a series of sections with slots in purple for a station (or type) and a fixed number of slots in red for children. The concept is simple. Different types of activities have different limits on the ideal number of children should participate. There are many more activities possible than available on any one day. So the teacher wants to be able to assign activities to slots on the board - and then physically lay out the activity within the room - for example the train table or the doll house. The children (typically 3 to 5 years of age) are empowered with "Free Choice" and can choose the activity they want to participate in. They are also free to move from one activity to another. The cards with their picture are kept in an index card case. When arriving at school at 9am they take their picture out of the case and decide which activity they'd like to start with. They stick their picture into an open red slot using a velcro fastener. If there is no open slot free on the activity they want, they have to choose something else. When they decide to change activities they return to the board and move their picture to the new activity and place it in an open slot. At any time, they can walk past the board to see if a slot has become free. At the end of the day, they move their pictures to the Going Home buffer off the board, and later the teacher returns the photos to the index card box.

It's not a pull system

While this is clearly a kanban system, as it both limits WIP and uses cards to signal availability, it is not a pull system. This troubled me until I realized that goal is not flow. There is no concept of flowing children from one activity to another and no need for each child to visit each station. There is no flow, so there is no need for pull.

So why limit WIP?

Limiting WIP introduces a rule (or constraint) and the system to enforce and enable it, the kanban system, introduces concepts that 3 year olds have to learn. It introduces some overhead for them to enjoy pre-school. So why do it? Well the rules of kanban enhance collaboration amongst the children. The experience of playing at any one station is enhanced because only the appropriate number of children are at any one station at a time. No station is ever over-crowded.

The kanban system also empowers the children to have "Free Choice" even though they are only 3 or 4 years old. The rules of their kanban system mean that the teacher does not need to manage the number of children at each station, free'ing the manager (err, teacher) to do other things, and the rules insure a collaborative environment and avoid disputes, negotiatiation, arbitration and reconcilliation that would be needed otherwise. The kanban system enhances the experience for the children, shows them greater respect as individuals, empowers them, while giving back the teacher more time to perform value-added activities rather than waste time resolving disputes over resources.

Kanban embraces and enables the People half of the Toyota Way

For me this example truly highlights how kanban embraces and enables the softer people aspects of the Toyota Way and Lean. Kanban respects people by empowering them and free'ing them from managerial supervision. It respects managers by giving them more time to perform value-added activities in this case child development. And kanban systems enable teamwork and collaboration by puting rules and constraints around what is acceptable behavior.

Recently Alistair Cockburn tweeted that Kanban with WIP limits was for Kindergarteners while Kanban without WIP limits was for adults! I'll blog more about that thought another time. Meanwhile, isn't it interesting just how much we can learn from kindergarteners and what they can teach us about empowerment and collaboration in the workplace? Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management