My role within Xebia organization is not to run projects and I was there only to do my job better as President of Xebia France (“What is well expressed is well understood”). So believe me, these two days have to be marked with a cross in my professional diary.
And, no doubt about it, it was a special experience. If I was lyrical, I would qualify this session as a breath of fresh air in terms of common sense, a pragmatic delight or even a well of clear sightedness.
Jeff has definitely influenced my way of approaching situations for ever. If I dared to, I would almost put Jeff on an equal footing with those Anglo-Saxon authors that any manager eager to learn should read, like Jim Collins and Jack Welch.
I’m not going address, even partially, the concepts delivered in the 200 training slides of the training nor even repeat the juicy anecdotes that Jeff was kind enough to share with us on the damaging effects of traditional project management: it would be a but a pale imitation, not to say clumsy, of course. But I do promise to write up a series of notes on “Agile Tips”.

For those reading these few lines and who, like us, are particularly fond of Agile Methods, Xebia is organising a “Scrum Master” certification training course with Jeff on 24 and 25 March 2008 in Paris (in English with the linguistic assistance of a French certified Scrum Master from Xebia).
We’ll leave this news with the “Scrum sensitive” readers of this blog for two weeks before announcing the fact to the community on a large scale. If you want to enrol, send an e-mail to info@xebia.fr.

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…