Spening Too Much Time on the Backlog

Spending Too Much Time on the Backlog
brought to you by Livescribe

Books mentioned at UTC CTO P2P Forum

I mentioned two books at the recent UTC CTO P2P Forum--both from the company 37signals:

The first is Rework which just came out and is already a bestseller. This is more focused on running a business.

The second is Getting Real which is their first book and talks primarily about how they build software. You'll find Agile principles all throughout both books. Enjoy!

Two vs Three Column Planning

Two_vs_Three_Column_Planning
brought to you by Livescribe

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.

#UTCAgile Presentation

First, thank you to everyone at the UTC who invited me to speak alongside with Chris Marsh at the recent CTO P2P Forum on March 12th.

Second, my thanks to Chris Marsh for being such a pro about collaborating and presenting.

I think we posted eight or nine topics we could speak on when we started. I have not seen the final list, but by the time everyone posted their own topic areas I'd guess we'd have about 20 or so. And I think we only covered two or possibly three areas in the time we had. If you'd like to do another session to cover additional topics please contact the UTC and let them know. In the mean time, I thought I'd post the slides I used to cover the first topic:

You'll recall this topic related to what to do when multiple stakeholders (e.g., divisions within an organization) need to use the same IT resources.

I sincerely hope Chris and I are invited back. But if not, I intend to cover some or all of the topics you posted that we didn't cover here. More to come...