Friday, January 23, 2004

Class Ownership #1 - Team Think!

Feature Driven Development believes in class ownership - the notion that a named developer (or perhaps a primary and secondary choice) is selected to “own” a class. Only that developer will write code in that class. This creates a constraint and a potential bottleneck. Other agile methods do not believe in class ownership. My recent journey back to coding has reminded me why class ownership is important and I feel that a series of short blog entries is required. First up - Class Ownership Forces Teamwork!

Quite simply, class ownership necessitates the idea of a Feature Team. A virtual team which forms to design and build a small batch of Features which touch the same classes. Class ownership forces the owners to work together to design sequence diagrams and to agree the interfaces/method calls between the classes. This team thinking activity improves the quality of the design. It also improves the social and communication skills of the participants and helps them to build a camaraderie and mutual respect.

The alternative in many agile methods is one individual per Feature/Story/Task. This encourages the individual to design on their own. This leads to a poorer quality design (on the average) and valuable opportunities for team working are missed.

I was once (about 2 years ago) asked to assess a team I had recently met. They were doing some XP practices but otherwise it was chaos. My inquisitor was a psychologist. My response to his innocuous question, “What do you think of the team?” took him by surprise. My reply, “They are a group of individuals. There is no team.”

I don’t know whether the - one individual owns and is responsible for a feature and codes it from start to finish - was the only reason for this group work rather than team think, but I remain convinced it was a contributing factor.