Customers Final Role

If you were the customer (GoalDonor) on an XP project that was unfunded WAY into the release cycle, by action of the GoldOwner, not by your recommendation, what explanation would you give for why you neither steered the project to success nor recommended its cancellation?

On an XP project, the customer provides the requirements via the UserStory. He chooses the order in which the stories are to be done. The developers estimate the stories, so the customer can assess which ones to do and which ones to defer. The team practices ContinuousIntegration, so the customer, using his own AcceptanceTests, knows at the end of every iteration how well things are going. By observing what gets done compared to what is requested, the customer knows the project velocity. The customer participates in the ReleasePlan, so that he has the opportunity to get assessments of how much work can be done, and by when.

If it is possible to fit sufficient business value into the calendar to make a successful release, the customer will know it, and he'll know it most every day. (If he's not sure, he just has to check velocity and do a ReleasePlan.)

If it is not possible to provide enough value in time, the customer will know that. He has the information needed to see that the project needs termination, and he has the responsibility to deal with that information.

No matter WhoIsTheCustomer, he has this responsibility. If he's the GoldOwner as well as the GoalDonor, he must cancel the project. If he's not the GoldOwner, he needs to inform the GoldOwner and recommend cancellation.

The customer steers an XP project. This is his responsibility. If the project isn't going to succeed, the customer knows it and must deal with it. This is the CustomersFinalRole.

If the project isn't going to succeed, the customer knows it

Sadly, life isn't always this simple. The customer doesn't always know how the project will turn out in the future, even with XP. It often depends on external factors not in anyone's control. But he or she alone has the power to decide that nobody is going to know the future of the project, by terminating it. I have seldom met a situation where the developers thought that the ideal moment had been chosen. That's why I find Keith's testimony of initial shock in TerminationCanBeSuccess so helpful. Somehow it's always like that.

As for the rest of the process described above, it's the real thing. Or at the very least it sets out the right aspirations for the real thing of the future. At last. -- RichardDrake

CategoryCustomer