Incremative

Published 01 July 07 07:45 AM | Earl Beede

In our 10x and Agile seminars, I talk about the role and purpose of incremental and iterative (incremative) development practices. On the surface incremative development is kind of wasteful. I mean, it is like asking me to drive to the grocery store and a I stop on each block, call home and ask my wife, "I am one block closer to the grocery store. Do you still want me to get the milk?" By the time I get there, buy the milk, call 10 more times on the way home, ("Do you still want me to come home? What do you mean you are having doubts???") the milk is spoiled and the tea is cold.

There is waste even if my wife were to say to me, "I think I need something at the grocery store, but I will not know until I see it and I am not sure what store I want to go to. Get in the car and start driving." There is wear, tear, and overhead costs in starting and stopping the car. We will take more time to buy the thing-she-may-end-up-buying-but-won't-know-it-until-we-get-there then if she knew what she wanted in the first place. Heck, I may even drive the wrong way and have to retrace my path since I need to guess a bit to choose an initial direction. Why even start a trip like this? It doesn't make sense.

I only have that "waste", however, when I truly have a deterministic outcome. If I can know the final destination, the straight line always will be faster. It is when uncertainty creeps in that I need to be incremative. With uncertainty comes the need to gather information to lower the uncertainty. The "waste" of incremative development is a known cost to buy information and avoid the potentially much larger unknown cost of guessing wrong.

Being incremative is all about lowering uncertainty by getting and acting on feedback. The incremental part of being incremative determines how often I get feedback. Since I have high uncertainty about what the other bozos on the road are going to do, my increments are often very small as I constantly scan the traffic. I don't let my eyes leave the view of the road for long (unless, of course, I need to send a text message on my mobile). The iterative part of being incremative determines what I parts I do over and can change based on the feedback. As I spot a bozo in a red truck coming into my lane, I change my acceleration, vehicle direction and the amplitude of my horn. Based on what the traffic does around me and my desired route, I will change the vehicles parameters many times.

But here is the punch line. Both certainty and uncertainty can live side by side on the same trip. I can be certain of my desired destination (I want to go to the store) but have uncertainty about the traffic, road conditions, etc. on the way there. Saying my trip is completely deterministic because I know I want to buy milk is naive. Saying it is completely uncertain because of the traffic is simplistic. It is both and I need to approach it that way.

So the trick in incremative development is to find the right balance, the point where I buy just enough information to lower the risk to an acceptable level. Too much, and I have unnecessary waste; too little, and I likely to have large undefined costs.

Like when you brought home the non-fat when your spouse really wanted the whole. It's back to the store again! (Note: bad iteration!)

Filed under: , , ,

Comments

# Steve McConnell said on July 1, 2007 10:54 AM:

This reminds me of going to the video store. The waterfall version of going to the video store is, my wife and I agree on a movie at home, and then I go to the video store, find out they don't have that movie, pick out some different movie, bring it home, and find out my wife doesn't want to watch it. Or I hedge my bets and rent 2-3 movies, which doubles or triples my cost, and my wife *still* might not like what I picked out.

The incrementive version of going to the video store is more like, My wife and I have a few ideas about what we want to watch, but we don't know what movies will actually be there. So my wife stays home (and pops the popcorn or gets the kids in bed) and I go to the video store. When I get there, I call her on my cel phone, and we talk about what movies they actually have. That way I pick up exactly one movie (minimizing our cost) and I maximize satisfaction (because we have a movie we both like).

This illustrates the agile idea of delaying commitment until the last possible moment. In the waterfall approach, I "committed" to the movie before even knowing if it was possible to get that movie (sound familiar?). In the agile/incrementive approach, I accounted for the fact that I had imperfect knowledge of the future (i.e., the availability of specific titles at the video store), and things worked out better.

An interesting angle on this is that this works best on a Friday or Saturday night. If we're going in at 2:00 on a Tuesday afternoon, we are virtually guaranteed that any movie we want will be there, and so we actually can say, "Let's just get Nacho Libre 4," and we don't really need elaborate supporting plans.