Software development: Should we continue to ignore the evidence?

Editor: Luc is the CEO of Xebia France. This is an english translation of one of Luc’s posts on the French Xebia blog.
We have noted it once again, one time too many no doubt. One of our clients (as the people responsible for such a situation work in the same company as the person where our contact operates) has got himself into a lose/lose situation with his integrator in a project developed at a fixed price. What are the facts? We could, without even letting him speak, list all the difficulties he encounters one by one with our eyes closed, reeling them off like a rosary.
A Call for Tender was issued aimed at the principal integrators in the place, because, depending on the Purchasing Department, this is the only way to conduct an IT project (which we told you about in an earlier posting (in french): “Eloge de la qualit锝). According to the same specialists, recognised for their IT skills, it’s a way of controlling costs and lead times, of sharing the risk with the company selected and of creating leverage (because it goes without saying that some wonderful penalty clauses for late delivery were stipulated in the contract). Integrator X was chosen. In a large part because he made a tempting offer and was able to accept all of the principles of this “contract of confidence” without uttering a word. So the scene was set: a calm atmosphere, mutual trust, the involvement of the best profiles from company X, users’ wishes taken into account…
As you might expect, the last phrase is ironic.

The project leader was under pressure, his company had allocated three and a half trainees to him, and a quarter of an Architect for, after bitter negotiations, the deal made turned out to be less profitable than expected. And, inside Company X, a badly negotiated project results in the allocation of inexperienced developers (“You pay peanuts, you get monkeys”, as we all know). The client’s buyers were rubbing their hands together, they had steered their ship well. The project leader was forced to work everyone harder than reason dictates to make unreasonable deadlines. The word “penalty” was whispered discreetly and then rang out openly in project meetings, brandished like the ultimate threat. The legal departments of both parties pulled out the contract and went through it with a fine-tooth comb. And everyone spent more time in fact looking for ways to catch out the other party than actually trying to solve the problems together, in good faith. So what about the users? They were worried. The application they had ordered was critical for them to be able to do their job. Project management explained that they had not done their job properly, that their specifications were too vague, that their incessant requests for modifications were unacceptable. They would even be singled out as second in line to shoulder the responsibility for such chaos, after the integrator, of course.
This project quickly became a bottomless pit. The client had gone too far to do an about-face. Pandora’s box was opened: The “addenda”, the word was finally out, to the great satisfaction of all concerned because, at the end of the day, it was the only way to come out of it with heads held high on both sides. But beware, the use of such backstabbing in a contract between two parties should be done very sparingly, of course, as it should simply allow the integrator to reduce his deficit on the project “a little” in areas where he really cannot be taken to task. This subterfuge allows him, just, to maintain a vegetative financial state on the project (fewer losses or zero profitability at best).
The paradigm of software development at a fixed price is based on principles (if not on values) which are falsified, dishonest, Utopian, outdated.
Successful companies, like Google, Amazon and Microsoft, to mention only the most well known, have known this for a long time. Agile methods are a serious alternative. The principles of these methods are as follows:

Team competence and motivation

The personnel assigned to projects has the level of seniority required to develop modular, evolutive, efficient, documented, integrable and operable applications. These personnel make a commitment to the costing and construction of the application.
Iterative developmentӬThe development of projects is iterative. The tunnel effect is eradicated. The modules delivered are immediately operational.

A favourable acceptance of change

The writing of complete detailed specifications months before delivery is proven to be somewhat Utopian. In this context, the acceptance of the change to priorities and functionalities is an integral part of the Xebia agile development process.

Close collaboration with users

The strong involvement of management and users throughout the project is organised around ongoing feedback orchestrated by systematic demonstrations which make it possible, at each iteration, to validate the work done and define the priorities for the next stage.

Ongoing attention to technical excellence

From the start of the project, Java/J2EE hyperspecialisation makes it possible to put the current best practices in the industry in place at all levels of the project: architecture designed by experienced architects, ongoing integration policy, performance tests, error management, operability of the applications, sustainable technological choices…