Iterative development

I experienced twice a successful setting up of iterative development in a software project (Eclipse Java projects).

The rule was: the software development team meets the customer every monday (physically or not) in order to set up the week roadmap which defines the actions to perform and functionnalities to realise within the week. Every friday, the project leader validates the developments and publishes a release. The client tests this release the week after and makes remarks that will be discussed during the next monday meeting.

This aspect of the Extreme Programming provides us :

• less management level documents and formal discussion documents as the customer is more implied in the life of the project (big french companies love formal documents for communicating)
  
• less overrun risk as the customer validates the project progression step after step (in term of days spent, final result to obtain)
  
• best results as the customer can react at anytime and decide to change functionnalities while the project is getting along.

This last point sounds like an evidence on big and/or technological projects if we consider that neither a customer nor us can make an optimal requirements evaluation, specifications or design writing, without doing some spadework on the project.

But the second point means the client may accept the contractual requirements may change during the project.

Making contracts on an inclusive basis is in our customers culture (french companies). They believe this is the only way to be sure a subcontractor will do all the job and in a "costs controlled" way. This point of view is not based on reality. In fact, the specifications details (the contract is based on) are often insufficiant. Worse, major functionnalities may be omitted in the contract (and will have to be purshased in addition while some useless functionnalities have been realised).

The iterative development provides a real improvement but is based on trust. A customer will enter this iterative development approach only if he trusts on you and/or he trusts on his ability to manage you in a technical way (meaning he's technically proficient enough to be self-confident).