Agile incremental construction: some tips

Ecris le 31 août 2005
Dans la catégorie Uncategorized |

Since some time now, I help my customers to design and build their Information System by an incremental approach. I noticed that obviously the term “incremental” does not mean the same thing for every body. For the most common case, the team try to slice its system into layers and build each layer one after the other: for instance the data layer comes first, then the process and finally the GUI. This slicing is driven by technical constraints as you can see in the future application where the database will stand, and when the associated tools will be used to build this particular part.

The drawback of this approach is well known by the agile community: if you fail to finish one of the layers in the planned time and budget, you can be sure you will exceed the project budget. Unfortunately, if your budget was fixed, you project will be a total failure for one problem on one layer.That?s why the agile approach suggests slicing your project into iterations, but also that all iterations must be functionally and technically coherent to be production candidate. That mean each iteration should have a little bit of data, a little bit of process and a little bit of GUI.The question is: how can I slice my big project into coherent slices (or iterations)?

In most case, after some study, or not, the project is launched for a given budget, estimated with more or less precision (generally, the precision is very low at this stage). Let say your budget is 1000. You want to slice your project into 5 iterations of 200. The approach I follow generally is to apply the following simple algorithm:

Suppose your project budget was only one iteration (200 is this example)
Determine what you should do for 200: this is your first iteration
For each following iteration, determine what you should do to improve the application by adding features, or refactoring, for a value of 200.
Stop the algorithm when your budget is reached.

The idea is that if you burn all your budget (1000) on the first iterations, at least, their functional scope has been designed to have the highest value for the customers. XP calls this practice “the planning game”. Of course, downsizing a 1000 project to a 200 one is not easy and request to have a strong knowledge of the domain to know what is REALLY the core of the business. Domain Driven Design can help you during this process.

Anyway, slicing a project in such a way is a difficult task, but that’s the cost of monitoring your risk efficiently: nothing comes for free!

Social Bookmarking