« Agile Project Management: Estimating Project Size Part 2| Main | Conference Fun »

Continuous Project Planning?

| | Comments (1)

We've all heard of continuous integration -- where the code is checked in and builds constantly. There is no time in which you don't have a compiling, running system.

C.I. sounds strange to folks who have never used it, but once you try it you're hooked.

Today I heard something that sounds even stranger: Continuous Project Planning.

I'm at the Agile2009 conference. This is the first conference I've ever attended. I'm a speaker on Thursday, so I thought I would come and see how the other guys are doing things. It's too late to change much, but at least it'll show me how much I suck before my big day.

The session I was in this afternoon could have been titled "see the smart guy and girl draw diagrams on the electronic whiteboard and chat" but I think it had some more formal name. What we did was listen to these guys tell us about various relationships they've observed in agile software teams and talk about the implications.

Pair Programming Performance Graph, showing an optimum point for pairing off to be around 2 hours
Optimum pair time for pair programmers around 2 hours?
That's what this guy said

First up the guy drew the chart above and said this was the results of his controlled study done a year or two ago. It showed that the best amount of time to spend pairing before finding a new partner was between 90 minutes and 2 hours. Wow!

Some implications of this: at the beginning when you start pair programming, there's a steep curve as you get acclimated to the code and start working. Somewhere around 90 minutes to two hours, you reach a peak. After that your performance drops off to half of what it was at your peak.

As it turns out, this curve is what you get when you multiply two other curves: an asymptotic curve and an exponential decay curve. Are there reasons for this? He thinks so. Let's take a look.

Graph showing performance impact of overhead
As your cycle times get longer -- you spend a longer and longer time pairing --
overhead per value increment approaches a fixed number

Overhead hurts the most when you first start something, whether it's pair programming or washing clothes. There's just so much stuff you have to do in order to get started. But once you're doing whatever it is, the overhead approaches a fixed amount: in other words, you may spend the first 15 minutes of pair programming doing a lot of heavy mental lifting, but after a while you're just solving each problem as it comes to you.

So where's the inflection point in pair programming? He said it was around 50% of max overhead. That means that when you've gotten about halfway through the tough part of getting started pair programming, you're at maximum effectiveness -- twice as effective as later, when things settle out. This is completely counter-intuitive.

So to maximize pair effectiveness, you're pairing up, going until you get about halfway comfortable with what you're doing, then switching partners. I was very surprised by this! And like everything else, I'll have to see it work to believe it.

What about the other curve?

A curve that shows value per time frame as it related to timeframe size
As I do something that has value in smaller and smaller increments
(assuming it has the same amount of value)
The rate of my value creation approaches infinity

Let's say I do something that has a thousand dollars of business value, and I take a month to do it. It obviously stands to reason that the smaller and smaller time I take to give you that value, the greater my rate of value return per time unit is. if I could give you that value in a minute, my return on value per time increment would be incredible.

In a regular project, we have timeboxes that are 2 or 3 weeks long. At the end of that time, we "deliver" chunks of stuff for people to use. As long as we deliver the same amount of value, the quicker we work, the greater our effectiveness rate.

The cool part is that even with a drop off in value per timebox, we've found that value doesn't drop as fast as effectiveness increases. So, for instance, if I gave you a 1000 bucks of value in ten days and we shorten the time frame to just one day, I might give you 150 bucks of value in that one day. As the timebox decreases, the value doesn't necessarily decrease at the same rate. You get more doing things in smaller chunks.

If it sounds like we're getting into pointy-headed boss territory, we are. But it's a fun trip. The general principles of how cycle time and overhead apply to iterative projects have been proven true time and time again. The outstanding questions are how seriously we can take the mathematical models that mimic some of the results we're seeing.

Our presenter was a true believer (math major, what can I say?). And I really enjoyed the talk. He challenged us to start measuring things that we do in cycles to determine where the inflection points were. Anything we do over and over again -- programming sessions, code reviews, releases, meetings, project planning -- would fall under this rubric.

We've already doing this with continuous integration. Instead of coding for a long time and then painfully checking in and integrating code, modern teams do little pieces and integrate as they go; being as "continuous" as possible. But how about things like project planning?

Project Planning? Is it possible to continuously plan your project? As each little tiny increment of value is added to the project, could you have a new plan automatically be created or updated? Or perhaps you don't plan much at all -- just do one thing at a time -- this would also be continuous and seemed to be what our esteemed pair was advocating.

But as the speaker pointed out himself, planning is about a lot more than simply knowing when value is going to be delivered. It's a social thing: the team gets common understanding of where they are and buys off on how they're going forward. But he still seemed to feel there was some value in approaching the idea.

I would be very careful in trying to take every cyclical, iterative process and make it continuous. First, it has the feel of cargo cult agile: doing it because it looks like it belongs in an agile project. If it looks agile, it must be agile. But more importantly, it confuses measuring things with actually understanding them. Agile is about communication and people. While it might be true that in general things follow a certain pattern, it's a huge mistake to focus on the pattern in lieu of the drivers of that pattern: people and conversations. We math and analytical guys are notorious for this. Show me a formula and we can "step over" those messy human interactions. And planning is definitely a "messy human interaction"

I wouldn't look for Continuous Project Planning anytime soon. But heck, what do I know? If somebody writes a book I'll probably be coaching the damn stuff next year. (grin)

1 Comment

Thanks for the post - interesting. I'm with you on the Continuous Project Planning.

Leave a comment

About this Entry

This page contains a single entry by DanielBMarkham published on August 26, 2009 2:32 AM.

Agile Project Management: Estimating Project Size Part 2 was the previous entry in this blog.

Conference Fun is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Social Widgets





Share Bookmark this on Delicious

Recent Comments

  • krt: Thanks for the post - interesting. I'm with you on read more

Information you might find handy
(other sites I have worked on)





Recently I created a list of books that hackers recommend to each other -- what are the books super hackers use to help guide them form their own startups and make millions? hn-books might be a site you'd like to check out.
On the low-end of the spectrum, I realized that a lot of people have problems logging into Facebook, of all things. So I created a micro-site to help folks learn how to log-in correctly, and to share various funny pictures and such that folks might like to share with their friends. It's called (appropriately enough) facebook login help