Thursday, December 29, 2005

Time Boxed Versus Feature Boxed Releases This is an interesting discussion you can find at: http://www.theserverside.com/news/thread.tss?thread_id=38287. It's an issue that comes up all the time inside a project and is ultimately the primary driver for project success or failure. The key point of why time-boxes are more effective is: To make a project successful you must change how every decision in a project is made. That's what time-boxes do. Time-boxed releases using a short time horizon force every decision made in a project. A time-box is like a black whole sucking in everything that gets close. For every decision branch a shorter implementation strategy selection is forced which results in features getting implemented in less time. When implementing anything you always have a choice of how to implement it. You can choose a way that gets the job in done with high quality, but takes a shorter period of time. Or you can choose a way, that you may prefer, but will take a longer period of time. This pattern applies fractally to the highest architectural decision to the lowest down and dirty programming implementation detail. Software is the result of thousands of decisions that trade time for other qualities like elegance, quality, power, generality, familiarity, and excitement. With a short time-box you are forced to make every decision with the time-box in mind. If you make 100 decisions everyday and everyone one of them results in a shorter implementaiton time, you can see how over a succession of decisions you will implement more stories. Now multiply this same process by everyone in your project. The chances are better your project will meet its goals. A feature-box has the opposite effect. Work expands to fill time available. And with feature-boxes the amount of work expands proportional to peoples imaginations because there is no force constraining the process. A feature-box is not a box at all, it's like open space in all directions and everyone has warp drive. Does a feature-box have to work this way? No, but that's the way I would bet. When faced with a decision in a feature-box scenario, what is your motivation? Your motivation isn't to the schedule, so you make choices that end up taking more time. These are not bad decisions. They just take more time. In the end, when you add up all these time increases, your schedule is burnt to a crisp. A long time-box is really no different than a feature-box. You have so much time there's no pressure on you during the sprint so you end up making decisions that result in longer implementations. It's the pressure on every decision that is the distinguishi ng feature between the time and the feature box. Doesn't this approach mean you get less? Less quality? Less future proofing? Less functionality? Just less? Yes and no. No in that every decision you make still has to meet the requirements of the story and be tested with unit and system tests. So you shouldn't have less features or lower quality. Yes in that software is an iterative infinite game in which the decisions you make now impact the future. Locally optimizing now will not globally optimize. This is particularly noticeable with phase change types of features. If a feature just incrementally extends and existing feature then there is little risk. But when a feature really means your product is changing into something different then you can easily warp right into the heart of a burning sun. Some examples of product phase changes are dealing with discontinuous levels of scale, adding fault tolerance, adding complex new algortihms, and integrating with other systems you have little control over. With these kinds of features you need to think ahead. But even with phase change features the time-box is your friend. You can go crazy implementing a risky feature. We've all done it. With a time-box you are more likely keep your scope limitted by just trying to get something to work. If you can use time-boxing as a black hole, driving every decision towards maximal effeciency, then you are more likely to deliver a working project on time. comment[] 8:18:41 AM

© Copyright 2006 todd hoff. Last update: 7/11/2006; 12:38:25 PM.