This OpenSpace? discussion considered the challenge raised by Mary Poppendieck in her keynote: How do we expand agile methods to address the whole product, beyond the code itself.

In particular:
- How do we interact with the customer?
- How do we represent the "vision" design - the design as experienced by the user?
- How do we scale the process?

Notes from the discussion follow.

The Customer

• Best case: We get the key stakeholder (who is paying for the system) involved
• They help us get a real end-user onsite
• Without an onsite user, it is much harder. Too many intermediaries between the development team and the user makes it harder.
• Problem: The Business Analyst from the customer's IT department is not a good user surrogate
• Good practice: We get the QA people from the customer organization to write acceptance tests
• Good practice: Our customer has to do real user work X% of the week or they lose their certification. So they have to stay grounded in what real users do.
• Since our user goes out to the workplace regularly, he works with others to see how they were reacting to the iterations we delivered.
• Problem: We're delivering to a market. We can't find one representative customer.
• Work with focus groups, marketing, sales, and human factors.
• Using multiple channels for communicating customer needs means they cross-check each other.
• Our customer is an external organization with its own IT department. Sometimes the IT department doesn't want to work with us in an XP way
• They want to give us a BDUF. It takes too long and slows us down
• They won't let us access the real users.
• They don't give us quick turnaround on questions.
• Idea: Create an internal Customer Team that represents the external customer. Have them present an XP face to the development team and a traditional face to the outside world.

The Vision Design

• Still lack of clarity over exactly what this covers
• Vision can be broken down in layers
• High-level vision sets direction
• Project determines what it needs to do to solve the problem
• VIsion comes from the business, bounded by existing constraints (has to work with existing platform, legacy databases, etc.)
• In any case, the vision comes from outside the technical team
• Someone needs to hold the coherence of this vision
• This can be an individual or a small team
• The whole team really needs to understand and buy in to the vision
• The vision of what the system is to do is not the same thing as the technical vision of the architecture etc.
• The customer side holds the vision of the business and the system's role in it
• The development side holds the vision of the technical architecture
• User stories are like threads through the customer vision
• Each story explains a little piece of the vision
• The stories are not integrated with each other
• It is a problem to create and maintain coherence across these user stories
• The role of the technical architect is to hold the coherence for the team
• Better if the team can hold the coherence themselves
• Technical architect needs to code - needs to stay close to the implementation or they become irrelevant
• Think about the significance of moving from "the customer" role to thinking of "the whole team"

---