The team began by reading through the problem. They then chose mileposts for the afternoon:
As happens frequently in real life, the allotted time expired before all the mileposts were achieved.
Ward Cunningham, playing the customer, visited the room and answered the team's questions about the problem's scope. After he left, the team discussed the problem further. It quickly became clear that the team needed an assumptions list that documented our understanding of the problem.
The team agreed that they were ready to begin designing objects. They began creating objects as CRC cards on Post-It Notes, so that the objects could be rearranged on the notepad as the design matured. The CRC cards never progressed beyond naming classes; class responsibilities were agreed on during discussion, but never written down. After the initial objects were identified, the team sketched rough UML-like static diagram showing the objects and their relationships.
A major stumbling block for the team was finding good nouns for class identifiers. The team agreed that a good class name saves a lot of trouble down the road, since it suggests (and sometimes embodies) the class's responsibilities. Several of the class names selected were "for want of something better", and would have been superseded had time and inspiration permitted.
The final class list was:
Ward came in for a second consultation. He blew away Assumption (1) by explaining that there were multiple windows on each thin client.
At this point (3:30 PM), the teams broke up and rotated visiting the other teams addressing the same problem. One interesting insight from this visit was that another client-server team said "Hey, wait a minute, the client told us that there would never be new rows added to the window!". We agreed that this was typical client behavior.
When the team re-convened, they set a new pair of goals: by 4PM, they wanted to have an interaction diagram, a sequence diagram, and a class diagram; by 5 PM, they wanted to have a validated architecture created by testing these diagrams against the use cases.
The team divided on how to attack the problem; eventually, the moderator suggested that they begin doing sequence diagrams of the use cases, and that this would drive out issues.
After completing one-and-a-half sequence diagrams, the team noticed that it was 4 PM, and decided to reexamine their strategy. The team created an Open Issues list:
They decided to pick only the most critical use cases and concentrate on those. Of the remaining use cases, the most urgent were
After the final visit from Ward, the team decided to do as many sequence diagrams as possible in the remaining time. The team created a sequence diagram of use case 1, client opens a window on the server and then exits. In rapid sequence, the team created sequence diagrams for client closes window (end of case 1) and client scrolls through window (case 2). Before we knew it, 5:00 had arrived and the session was over. There was no time to draw conclusions or discuss lessons learned.