How to build the confidence of clients and to make the customer succeed
Position Paper for "Workshop on Experience Exchange"
Lornsenstr. 72 - D-25451 Quickborn-Heide,
Phone: +49 4106 761077
Since 1984 I am working as a programmer, project manager, product architect and
business consultant. I have managed projects with budgets of several Million
Euro. These projects were of course not done according to the XP practices but
at one client they had developed some "strange" practices similar to XP and
even forced us to adopt some of them.
In the following I will distinguish between the client (company) funding a
software development project and the customer role in a XP-
My main interest lies in the area of interaction with the customer, i.e.
making him succeed and finding efficient ways to get clients to pay for
projects done the XP way. While I am quite convinced that XP is an
exceptionally good way of implementing software systems, I have some
reservations about arriving at a good system architecture this way.
My development experience
Regrettably I have not yet done any real XP project, but my personal
experiences concerning (near-) XP practices (even if they were not called XP at
that time) are, in decreasing order of intensity:
Additionally we did efficiently:
- working on site at the client company,
- PlanningGame (deciding with the customer(s) the priorities of the
- "pairing the customer" (a system architect and a client together
fulfilling the customer role).
Statement of position
One of the central features of XP is the clear specification of the interface
between developers and clients with the developer on the technological side and
the client on the business side. This puts a (too ?) big burden on the
customer role in the XP team.
The success of a XP project depends on the capabilities of the customer
and the confidence the client gets in the team at least as much as on anything
else. Clients usually also look for somebody helping with the business
decisions. The biggest fear of several of my clients was:
"Our software contractor will deliver a software as we want it, not as we
need it !"
The practices of PlanningGame and OnsiteCustomer make the XP process quite
transparent to the client. Thus he can get the confidence that the XP team is
doing its best. Unfortunately clients need confidence that the XP team
is doing the best compared to other processes and other possible
contractors, especially in the beginning.
The confidence of the client also depends quite a lot on the success of the
planning game and the tracking, i.e. whether the committed stories are
delivered to schedule. This implies that the velocity of the team should not be
I would like to defend the following statements:
- For making an XP project succeed, we will have to make the customer
succeed in designing the right system, i.e. succeeding as a business architect
(asking for the "right" user stories).
- The customer should not be on site full time, because he has to
gather information concerning the business decisions to be made and afterwards
"sell" them to the gold owners and end users. He may even have to train the
first group of them.
- "Pairing" the client-
with a domain expert with a solid programming/technical background, which
together fill the customer role in the XP team, seems to be a good
practice. There is no need for this domain expert to come from the same company
as the XP team.
- Reducing the volatility of the team velocity is essential for gaining
I would like to pose the following problems:
- What is the smallest practical XP project to give a potential client a
sufficient overview to get confidence in the XP process, i.e. how many
programmers should be scheduled for how many releases/iterations ?
- What is the smallest practical size of an iteration, so that the usual
estimation errors can even one another out to a reasonable extend ?
- How can development speed and total cost of XP projects be compared
between XP teams and to other development processes ?
- How can we reduce the volatility of the team velocity ?
I would like to make the following suggestion concerning the team velocity:
- The estimation of each task is reevaluated after completion.
- This time a distinction is made between essential and accidental
complexity of the task (as in Brooks: "The mythical man month").
- Where this separation is not obvious, the customer has to decide,
because it is his confidence in the future planning process that is important.
- The time needed for refactoring usually belongs to the accidental
complexity, because it depends to a large extend on the sequential order in
which the user stories are implemented, not on a task itself.
- In estimating new tasks by comparing them to the old ones, only the
essential complexity is used.
- For the accidental complexity a certain percentage of the time of each
iteration is reserved.
- I contend that this percentage can be kept quite stable, because the
amount of time used for refactoring can be used as a buffer to a sufficient
©Jürgen Ahting 2001