Onsite Customer Onsite Customer
If more than one person might enjoy your program, they must appoint (using common mercantile business mechanics) a single individual to collate their interests into a coherent stream of UserStories. Only an OnsiteCustomer may create or prioritize a UserStory.
I've been thinking about this after looking at JAD, PD, and QualityFunctionDeployment. The OnsiteCustomer is a UserRepresentative? (or is that CustomerRepresentative??). How does this compare to CustomerShadowing (shouldn't this be UserShadowing??) which itself seems a lot like PD's DesignerAsApprentice? or Blitz QFD's GoToGemba? Can you get an adequate understanding of the process by asking questions or should it be a core practice that you also go and observe the environment the user is working in? -- JasonYip
Distinguish getting an understanding from resolving disputes. XP needs the second, CustomerShadowing deals with the first, but not the second. -- AlistairCockburn
A similar situation arises when a CustomerProxy is used due to LackOfOnSiteCustomer. The CustomerProxy can gain an understanding of the requirements via occasional conversations with the Customer. However, when push comes to shove disputes often arise. -- KeithPitty
What is the expected result of the R&D? If it is academic research, the result of the research is probably a paper with the intended customer being the peer review board of the publishing entity. In this case, get an advisor with knowledge of the peer review process to serve as the customer. If it is corporate research, it is probably targeted at a specific market segment, and the company probably has identified at least one likely customer. If at all possible, sign a non-disclosure agreement with one of the target companies and find out what the users really want.
Onsite customer related quotes published on XpMailingList by WilliamWake:
Sandip and Frank work at MegaWampumIndustries?, and read books like RapidDevelopment and SoftwareProjectSurvivalGuide. Frank, however, has recently picked up ExtremeProgrammingExplained.
Sandip must upgrade a program used by another division of MWI, located across town. Per his understanding of those software life-cycle books, he schedules his allotted time into three big phases - RequirementsGathering, IterativeDevelopment, and Deployment. During RG, he travels across town, interviews users, watches their workflow, and attentively collects wish lists. To end the R.G. phase he displays his vision of the new UI as a stage-prop demo, and everyone likes it. The ease of use and short click path thru the new demo allay fears that the new UI differs completely from the old one, which matched the internal data model closely and was therefore klutzy.
At the same time, Frank accepts the task to upgrade a program used by a department downstairs from his IT lair. He also ostensibly schedules his time into RequirementsGathering, IterativeDevelopment, and DeploymentPhases?, but as his management has not yet been pitched XP ideals he can't make demands based on them yet. After similar wish listing he selects and appoints one of the users, Marco, to be his regular contact on the project. He builds the screen-prop demo with Marco sitting next to him in his cube, directing. The UI is, likewise, steeply different from the old version.
During their I.D. phases, both Sandip and Frank stabilize their old versions with UnitTests, then Refactor them Mercilessly into the new versions (despite most of those software life-cycle reference books recommend neither such thing beyond in passim). Each feature drops in rock-solid, and their velocity is very high. They spend most of their time heads-down in their cubes deep in flow.
But Frank's third development task, after building the demo and laying out the UnitTest rig, is to "deploy" a reference installation in a cube in the SQA Department. The SQA Department, after learning that it does nearly nothing, ignore it. But Frank deploys a new bench version to it every other day, so whenever Marco stops by he can see it without interrupting Frank's flow. Eventually Marco makes a point of playing with each new feature in the reference version as it appears.
Sandip, on schedule, releases his upgrade to SQA. They tick off each of its requirements, and help deploy it to the customers' workstations across town.
Frank puts his program thru SQA and deploys it to Marco's desk. He tells Marco, "For the first week we can't go crazy and start using all the new features I added. We can only prove the program still matches exactly what the old one did." But Marco simply itches to play with the new toy, and as Frank leaves Marco is on the phone coordinating the new data features with his colleagues downstream.
After a week wondering how his program's working out, Sandip calls the department using it. Then he drives over. He discovers everyone still uses the old version, and they often activate the new version just to press one button. Nobody has read the carefully written Users Manual. He returns, arranges a "Training Session" with the managers, and never hears the workers' groans as they read the e-mail demanding a big chunk out of their day.
Sandip's project has FallenVictim? to a problem common to new versions that differ widely from the old versions - inertia leads to low customer acceptance, even if the new version is superior in every way. Frank ran essentially the same risk with his upgrade effort. But by using Marco as a PseudoOnsiteCustomer?, he whipped him into a frenzy beyond what any TrainingSession? could ever have accomplished. Marco burst thru the starting gate not only knowing the new face of the old features backwards and forwards, but knowing the exact list of new features and how they worked together. This experience, similar to being a real OnsiteCustomer, BrainWashed? him into UnquestionableCustomerAcceptance?.
-- PhlIp
TheTwentyFirstCenturyCorporation says "The best-of-breed companies will go even further. They'll invite customers in as collaborators, binding them ever tighter to the corporation." (p. 92)
Often there are many customers for a project. We often have multiple customers who want very different things at the same time. You can create a virtual customer but this isn't very realistic. Usually there are groups representing different factions (marketing, manufacturing, etc) that taken together represent the virtual customer. -- Stout
Absolutely, but it isn't the job of development to sort out their relative priority. TheCustomerSpeaksWithOneVoice. At http://www.evant.com there are six ProductManagers. By the time they come to the IterationPlanningMeeting, they have already worked out who is going to get what amount of the team's time. During planning they work out how their pieces go together, e.g. "If you're not going to do that, then this here of mine doesn't make sense until later." See also http://industriallogic.com/xp/exposures.html.
One of the premises of successful XP is the direct expert user/developer interaction.
The ideal would be to have an expert user who knew all the company's functions and politics intimately, and correspondingly a developer who knew the development environment intimately (how many of us really do?) This ideal is unachievable. (And not ideal anyway) The expert user is usually a different person in different areas. And yes there is often controversy within areas of expertise.
In operational areas, the "expert" user can often be a choice of one of many performing the same function. In operational areas, the aim of the application development is to automate the procedures of the user, and to facilitate the production of the required derived information for tactical and strategic use. Developing using XP in operational areas is often a pleasure because the people at the coal face are usually above the politics. Progress is rapid.
In tactical areas, the expert user must have good work experience of that area. The developer should control choice of the expert user in these areas. The tactical areas give the requirements and real-world methods of achieving them. Tactical expert users can be difficult to deal with, because they are often caught up in, or generators of the politics. Progress can be delayed.
In strategic areas, there is no expert user available. The strategic area defines the purpose of the application being developed. Edicts like "Our aim is to achieve less than .5% stock variance." or "We want less than 20 minute lead-time between us and our customers." or "When we build this car, we want to be able to keep track of it's components throughout its life cycle". Progress is measured by arbitrary deadlines squeezed out of lower-level project managers, who squeeze arbitrary deadlines out of lower-level programmers.
Expert-to-expert is essential. The sequence is also important. The strategic view gives context to the application. The operational implementation defines its functional requirements. Since the operational layer is the source of the tactical layer's information base, it is better to defer implementing any tactical functionality until its operational layer has been testing successfully.
Issues related to the OnsiteCustomer will be discussed at the WorkshopOnCustomerInvolvement, associated with XpTwoThousandAndOne.
Chapter 3 of ExtremeProgrammingInstalled (pp. 17-21) is completely devoted to the OnsiteCustomer.
I can see this becoming an issue in our office when I first attempt it. The last time I approached the manager of our Administration section (the primary user of the system being discussed) I asked for 2 or 3 administrators to get together with to begin outlining the user requirements (this was before learning of XP). I ended up with 8, including someone appointed by the manager to oversee their requirements.
Therefore, I foresee resistance to the idea of only one representative. One way I can see to approach this would be to let them have their committee write up the stories, but their "leader" be the one that actually sits down for the PlanningGame.
Does this fit in with the spirit of XP?
In the extreme cases (this never happens right? :) where an on-site customer is an impossibility, it is key to figure out how to keep the customer up to date via a collaborative system. There are many out there, and even one specific to XP at http://www.peerthought.com.
On Site customer, this is the truth that we should face. On a project, we worked for a GSM operator; the database design, database access, and anything related to the customers info are confidential.
It is like, "bake a cake, don't touch the eggs, never come near the oven, we don't have sugar, and we need this cake to be SWEET AND HOT".
This was impossible, at that time I wasn't in charge, and for sure the plan went out of the window, we couldn't do any kind of development, so when I was in charge, I enforced the idea which I was trying to convince my management with. "WE SHOULD BE WITH THE CUSTOMER; MOVE THE DEVELOPERS TO THE CUSTOMER."
It has been a year now, and the team has reached up to 15 developers, and they are all at the customer premises. It was the only solution.
Now I am on another project, it is impossible to have the customer all the time. Here is what I did: I met with the Quality Assurance on my team. And here is what I said: "Guys, we don't need a QA on this project; we need a customer. I don't care about the white box texting any more; you should be our customer, you will breath the way our customer breath, you will talk, eat, walk the same way our customer does."
So from that day on, I have my QA people - which we now call them Customers - meet the customer on a daily basis; they have all the kinds of questions that you may dream of, they never answer a question unless they are 100% sure about it, and when they are not, they call the customer or they keep the answer for a day, which is ok. My QA people are now ready to work instead of the customer if someone at the customer side didn't show up. We realled [?] cloned the customers, and everyone is happy, especially our customer.
Oh no, there is nothing called Use Case here, none of the developers have a visio on their machines.
Thank you XP, thank you Kent, and thank you for all the people who made this happen, and I really cannot describe how much I am happy. I was promoted twice in less than two years thanks to XP.
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006