Time-boxes, Rhythm, and Incremental Value

Note: This article is updated at 3 Keys to Agile Project Success: Timeboxing, Rhythm, and Results.

Today I had some interesting conversations with Loren Kohnfelder. Every now and then Loren and I play catch up. Loren is former Microsoft. If you don't know Loren, he designed the CLR security model and IE security zones. He created a model for more fine-grained control over security decisions and he's a constant advocate for simplifying security.

You might think two guys that do security stuff would talk about security. We didn't. We ended up talking about project management, blogging, social software, and where I think next generation guidance is headed. I'll share the project management piece.

I told Loren I changed my approach to projects. I use time boxes. Simply put, I set key dates and work backwards. I chunk up the work to deliver incremental value within the time boxes. This is a sharp contrast from the past where I'd design the end in mind and then do calculated guesstimates on when I'd be done, how much it would cost and the effort it would take.

I use rhythm for the time boxes. I use a set of questions to drive the rhythm … When do I need to see results? What would keep the team motivated with tangible results? When do customers need to see something? I realize that when some windows close, they are closed forever. The reality is, as a project stretches over time, risk goes up. People move, priorities change, you name it. When you deal with venture capitalists, a bird in hand today, gets you funding for two more in the bush.

Loren asked me how do I know the chunks add up to a bigger value. I told him I start with the end in mind and I use a combination of scenarios and axiomatic design. Simply put, I create a matrix of scenarios and features, and I check dependencies across features among the scenarios. What's my minimum set of scenarios my customers want to have something useful? Can I incrementally add a scenario? Can I take away scenarios at later points and get back time or money without breaking my design? Sounds simple, but you'd be surprised how revealing that last test is. With a coupled design, if you cut the wrong scenario you have a cascading impact on your design that costs you time and money.

We both agreed time boxed projects have a lot of benefits, where some are not obvious. Results breed motivation. By using a time box and rhythms, you change the game from estimating and promising very imprecise variables to a game of how much value can you deliver in a timebox. Unfortunately sometimes contracts or cultures work against this, but I find if I walk folks through it, and share the success stories, they buy in.

Comments

• Anonymous
  March 16, 2006
  Interesting... I looked at Loren's page that you link to and see that IE's security zone concept is patented.  I often wondered why alternate browsers didn't adopt a zone-like model--that could explain it.

• Anonymous
  March 17, 2006
  A few folks have asked me about Axiomatic design that I mentioned in my post on Time-boxes, Rhythm,...

• Anonymous
  October 26, 2006
  A few folks have asked me about Axiomatic design that I mentioned in my post on Time-boxes, Rhythm, and

• Anonymous
  October 22, 2007
  Time boxing is a way to chunk up time and get results. If you continously miss windows of opportunity

• Anonymous
  December 19, 2007
  If you have to compete for resources or budget or sell an idea, one of the keys is a business case. One