	CRC-Card Experience Connects Developers and Customers to Essence of the Problem Ward Cunningham Cunningham & Cunningham, Inc. I got a call from an IT program manager last week. She had just returned from London where she had demonstrated her phase-two prototype to internal customers, a group of bookkeepers and accountants. Things had gone well. The customer was satisfied, excited and constructive. She explained that the customer could see past the little flaws in the hastily-built interface. This hadn’t been her experience on previous projects or that of her colleagues. Her customer cared about the objects inside the prototype and understood why they mattered. Here is what we had done to make that happen. I met the team of sixteen people, customers and developers, on the first day of a four-day design workshop early in the project. They had already gone through introductory training in Smalltalk that included an introduction to CRC-Cards. Had anything sunk in? They weren’t sure.
Team finds easy objects to be hard business.	On Monday we wrote cards for lots of business data. This was easy. Most everyone was familiar with the current system and the several volumes of requirements that had been written for the next one. If a noun appeared in there anywhere we probably had it on a card. By the end of the day everyone was tired and a little worried. There wasn’t any sense of progress. I wasn’t expecting any. Tuesday began the same way. We kept going over the same material without decision or conclusion. People stopped looking at me, the facilitator, and started looking at each other. I looked where they looked, at the real decision makers. Then came the protest. Why weren’t we writing “responsibilities” and “collaborators” on the cards like they had done in training? I had to be honest. We had the wrong cards. Here’s my logic. Since our fifty cards just barely scratch the surface of the problem (their assessment) we were going to need hundreds more just like them to get to the first prototype. If we were going to write that many cards we might as well write another book and put it on the shelf with the rest of the requirements.
We go up a level in abstraction.	Tuesday afternoon I announced that we were going to have to start over. I took a stack of blank cards and moved to the far side of the conference room table. Our carefully arranged work to date lay out of reach and almost out of sight. I wrote out three rather generic cards. I challenged the group to work the now familiar scenarios using these alone. We stumbled. Some wondered, were we making progress or going backwards? Our decision makers cautiously nodded just often enough to keep everyone on board. By Wednesday our small design had grown to six cards and had been dubbed the “framework” approach. I liked the name. We worked through scenarios from half a dozen flip chart pages that we had pasted around the room during a lull in “progress” the previous morning. I watched for nods and excitement. I was getting some.
We're on to something. It's acceptable.	On Thursday, our last day with the customers, we set out to tackle the tough problems quoted on the two remaining flip chart pages. They turned out to be easy: more of the same as yesterday. By mid morning the decision-maker among decision-makers (the most important customer) said to the program manager, “If you could make the first prototype do these six objects, that would be worth seeing.” We were done. We broke at lunch so our guests could do some American style Christmas shopping before heading back across the Atlantic. We were beat but we had done it. We all knew what we had to build. No one wanted to admit that we had reduced volumes of requirements to six index cards. Because, well, we hadn’t. What we had done was to bring sixteen professionals together and get them communicating on the same level about the same things. Then, looking into ourselves, using all of our professional experience, we searched for and found the essence of the desired system, the part that had been overlooked in the previous generation.
We cement success by casting it in code.	The schedule called for prototype releases every couple of months. There would be plenty of time to review requirements, documented and otherwise, throughout development. The whole team had connected once and would do so again often. The last thing I had to do was make sure those six cards were not forgotten. I didn’t want the first-time Smalltalk developers to lose sight of what we had accomplished while they struggled with language details. Six objects, how long could that take? One of the developers and I wrote them up that night in heavily stubbed Smalltalk code. We walked through it Friday morning. I caught my own afternoon flight knowing that the team had a skeleton, one they knew to be the right skeleton, and were well prepared to flesh it out with the continued help of their customers.

CRC-Card Experience Connects Developers and Customers to Essence of the Problem