KentBeck was kind enough to share some of his day (30-dec-1999) with me at his new office in Merlin. His (huge) dog Zoomer didn't even bite me. Here is the crux of the interview. -ChrisTilt
Chris: It seems there is a role missing, that of the Program Manager. In a project that spans many of the functional disciplines within a company, the ProgramManager often coordinates and is "responsible" for the project to executive management. How is this done in XP?
Kent: Yes, this role exists, but we have to be careful not to think this person has control of the project. Decisions are pushed down to the team. The program manager coordinates the commitment schedule with external dependencies. This role applies mainly to non-fixed price projects.
Chris: We had some trouble understanding the "customer" role when applying XP to our business model. We have hundreds of customers and thus look more like a shrink-wrap business. We plan to put a product designer in the role of customer to represent the many needs and to make sure the stories form a coherent architecture. Does this sound right?
Kent: Yes. This is another example of the difference between shrink-wrap and fixed-price projects. However, many companies hire an expert from their target market to play the role of customer. It's a question of which risk you want to take. A product designer that has to learn the problem domain, or an expert in the domain that has to learn design?
Specialists/Experts
Chris: With regard to code ownership, we have some deep technical areas that we tend to produce specialists from. XP says this is bad, but having specialists is a powerful information resouce. For example, when I am not in the office, no one can answer questions about product S.
Kent: Sooo, experts are bad, right?
Chris: Yeh, ok. Should we capture the knowledge on intranet web pages?
Kent: Put the knowledge into the code. By using good variable names and comments, you can express a lot of information in the code. Put it into tests. The system's behaviour is expressed by the tests, so you can write tests just for documentation. If the system is based on something that has a quirk and you learn it, put a test in that communicates the quirk; the test case will make sure the quirk is still there.
Chris: This sounds like a set of assertions about the system. Is that right?
Kent: Yes.
Architecture (The guru approach)
Chris: As with most interesting problems, the underlying model is hard. If we are to distribute all aspects of the project, how do we arrive at a strong model of the problem?
Kent: Not all phases of the project are distributed. The distribution of effort in XP is about getting the most out of ourselves by concurrent execution on the most important parts of a system first. Determination of which business problems to attack in the market is a different kind of activity in which a smaller group of people (maybe one or two) focus. This is usually done by the customer (marketing on a shrink-wrap product). Likewise, the underlying model of a product might be developed by a few people. This should result in a metaphor that guides the whole project.