Kent Beck
2005-02-08 21:06:30 UTC
Make people whose lives and business are affected by your system part of the
team. Visionary customers can be part of quarterly and weekly planning. They
can have a budget, a percentage of the available development capacity, to do
with as they please. If this is the kind of customer who encounters problems
six months before the rest of the market, making the system they want can
put you ahead of your competition. If your product is valuable to them, they
may be willing to pay for their participation.
The point of customer involvement is to reduce wasted effort by putting
the people with the needs in contact with the people who can fill those
needs. Whole Team seems to me to imply customer involvement, but I haven't
seen many teams go as far as they could toward involving real customers. You
will get different results with real customers. They are who you are trying
to please.
No customer at all, or a "proxy" for a real customer, leads to waste as
you develop features that aren't used, specify tests that don't reflect the
real acceptance criteria, and lose the chance to build real relationships
between the people with the most diverse perspectives of the project.
The objection I hear to customer involvement is that someone will get
exactly the system he wants, but the system won't be suitable for anyone
else. It's easier to generalize a successful system than to specialize a
system that doesn't solve anyone's problem. Ensuring that the system stays
generally useful is the job of the marketing members of the team. Generally,
the closer customer needs and development capabilities are, the more
valuable development becomes.
"The sausage factory" is another objection to customer involvement. "If
the customers knew how messed up software development was, they'd never
trust us." Are you sure they trust you now? Software reflects the
organization that builds it. The customers are already using the software so
they already know a lot about how you develop. If they don't yet, they will
soon. When you act trustworthy and have nothing to hide, you are more
productive. (Think of all the time you no longer have to spend hiding or
covering up.) When you are ready with accurate estimates and low defect
rates, including customers in the development process fosters trust and
encourages continued improvement.
team. Visionary customers can be part of quarterly and weekly planning. They
can have a budget, a percentage of the available development capacity, to do
with as they please. If this is the kind of customer who encounters problems
six months before the rest of the market, making the system they want can
put you ahead of your competition. If your product is valuable to them, they
may be willing to pay for their participation.
The point of customer involvement is to reduce wasted effort by putting
the people with the needs in contact with the people who can fill those
needs. Whole Team seems to me to imply customer involvement, but I haven't
seen many teams go as far as they could toward involving real customers. You
will get different results with real customers. They are who you are trying
to please.
No customer at all, or a "proxy" for a real customer, leads to waste as
you develop features that aren't used, specify tests that don't reflect the
real acceptance criteria, and lose the chance to build real relationships
between the people with the most diverse perspectives of the project.
The objection I hear to customer involvement is that someone will get
exactly the system he wants, but the system won't be suitable for anyone
else. It's easier to generalize a successful system than to specialize a
system that doesn't solve anyone's problem. Ensuring that the system stays
generally useful is the job of the marketing members of the team. Generally,
the closer customer needs and development capabilities are, the more
valuable development becomes.
"The sausage factory" is another objection to customer involvement. "If
the customers knew how messed up software development was, they'd never
trust us." Are you sure they trust you now? Software reflects the
organization that builds it. The customers are already using the software so
they already know a lot about how you develop. If they don't yet, they will
soon. When you act trustworthy and have nothing to hide, you are more
productive. (Think of all the time you no longer have to spend hiding or
covering up.) When you are ready with accurate estimates and low defect
rates, including customers in the development process fosters trust and
encourages continued improvement.