Agile and Critical Chain Similarities

In my previous post I shared slides from my recent remarks at the Utah Technology Council CTO P2P Forum. I used a three column planning model with "Backlog" on the left, "Work in Process" or "WIP" in the center, and "Done" on the right.

One of the principles I outlined was to keep the WIP column "clean" so when project work comes in, all (or at least sufficient) resources are deployed to get it completed ASAP. I mentioned that too often we load up the WIP column with as many projects as humanly possible thinking that's a virtue. Author, speaker, and consultant Alistair Cockburn who taught me this model believed (as do I) that getting things to the "Done" column is what really matters--not how many plates we can keep spinning. How many staff meetings have you sat through where the PM essentially itemized the baby steps he's taken with all 23 projects he's juggling but he has nothing to demo, nothing Done!

I was watching a video, recently, of a speech author, speaker and consultant Lawrence Leach gave at the 2009 Continuous Process Improvement Conference. He pointed out how counterintuitive two tenants of Critical Chain Project Management are:

1. Waiting to start some projects actually helps them get done faster; and
2. Reducing the WIP increases overall project throughput

Obviously, Agile and TOC have some very similar philosophical roots. One of the first principles of Lean Project Mgt (LPM) and even Covey's Four Disciplines of Execution is to provide those you manage with the luxury of clear focus. Tell them that for a given period of time they can just put their attention on this module, this problem, this functionality and at the end of that period of time we'll be demonstrating it live in production to a client.

This principle works for a number of reasons which I might attempt to enumerate in a future blog post, but suffice it to say, when you provide clear focus on who needs to get what done by when, and you give your folks a transparent scoreboard where everyone can see how everyone is doing, things get done. When you tell your team to work on these 12 "priorities" all at once, you paralyze them and create what David Allen calls a rapid refocusing nightmare for them.

I'd like to clarify (as they do in the Four Disciplines seminar) that this principle applies to each team or resource in an organization. If an enterprise has a dozen teams, it will have a dozen or more projects in its collective WIP. But if you were to ask a given team what they are working on, their three columns are very clear--with only one or two items in WIP.

I'll post another time about what happens when an organization tries to matrix individuals to multiple teams and implement this model (hint: not pretty). I'll also post in the future about how giving each team a secondary item and sometimes even a third relates to the "buffer" concept in TOC production theory.