CRC cards-incredibly successful so far

During the last week of December I submitted a post discussing my intention to use CRC modeling techniques on what I would call a "massive" project. I needed a way to collaboratively build an overall domain model for an incredibly complex solution that was currently expressed in a thousand plus pages of linear, non-scenario-based business requirements. I said that I would report on my progress in a later post, and I'm happy to state that CRC modeling has been a fantastic success. While the overall constraints and structure of this project cannot in any way be called "Agile", applying this agile modeling approach across our internal team is providing a fantastic amount of value.

As I stated in my previous post, I initially followed a more traditional modeling approach, which involved a technical team:
1) Reviewing the requirements and creating models
2) Placing white board models into an official UML tool (Rational Software Architect)
3) Holding various workshops with business experts on our team to make sure that the models properly reflected the requirements

Again, as stated in my previous post, this approach had very limited success. The main problems being
1) Business resources were simply not a core part of creating the model. Reviews were simply not that successful/productive

2) UML repositories are really hard to share and maintain on a large team. Especially when rapid change is required.

Note: A lot of agile signatories (Scott Ambler especially) have strong cautions concerning using complex UML case tools; I never understood this before I tried using one with a team of 7 plus resources working on a shared model. It is difficult to overstate the aggravation involved in keeping this model in sync. An excellent resource on case modeling tools can be found on Scott Ambler's site here.

3) The case tool itself was causing the team (myself especially) to model with much more detail than required for this stage of the process. There's a lot of good advice out there on modeling that states that modeling should be at a high level until they can be validated through real implementation. UML diagrams by their very nature can sometimes seem too detailed for this initial analysis.

Within week one of the project restarting after Christmas break, (sometime around the second week of January) I had organized three parallel teams of two technical/modeler types and one business/functional resource. I myself played a floater role of mentor/facilitator/advisor across the three teams. Of course, I only had a week more experience than any of the other teams, but I'm used to doing what I call "just-in-time training". (meaning I train myself just in time to train somebody else)

The technical/modeling resources all had a pretty good understanding of OO and UML, while the business/functional resources had spent the last year and a half collecting 7000 plus business requirements, and thus had a pretty good understanding of what the solution needed to do in order to be successful.

We set up a process that involved spending three hours in the morning conducting modeling sessions using the separate teams mentioned above, then the modelers excluding the functional resources would spend the next half day consolidating the models, removing duplication, creating common structures and making sure that the separate work was combined into a cohesive whole.

Personally, I was personally concerned that CRC cards would not effectively scale, that it would be too hard to organize the cards//we organize them as necessary, that the model would be hard to maintain, and that we would be unable to get the right amount of detail. I was also concerned that the business/functional resources (who have no object oriented training whatsoever) would simply not be able to properly participate.

I have to say that my concerns had been completely unwarranted, every team appears to have had very good success in restating requirements into a CRC format that is now digestible in a matter of minutes, as opposed to hours. Even more important, functional/business resources have all played a vital role in deciphering/explaining business requirements and contributing to the quality/accuracy of our CRC models. I was personally satisfied we are on the right track when I saw specific CRC cards being built by these functional resources. Even more important, the proposed system appears to be a lot simpler than perceived by simply looking at the original requirements. Certainly there still is a lot of complexity, and this will by no means be an easy system to build, but it has become apparent that there is a lot of shared pieces that apply to 70 plus percent of the requirements.
Our client has also been very firm in wanting a Rational Software Architect version of the model. What that means is that we've spent the last week or so entering our CRC cards into this tool. The work involved in ensuring the integrity of the model within the tool, and the level of effort required to make simple changes more than validates the incredible flexibility provided by using simple index cards and particleboards. Changing the contents of a CRC-based model is incredibly easy, incredibly quick, and painless. I'll probably never attempt any serious modeling exercise without CRC cards again. And actually probably little embarrassed that I've never used a CRC before. So two thumbs up IMHO for CRC cards.