Lately, I've been trying to explain the reasons why dummy-data classes are a smell in software. Dummay Data classes are classes that do not have behavior, only data.

I thought of a different way to illustrate the problem, as the common arguments have not seemed sufficient lately.

Consider scrabble. When someone presents a word that is challenged, one of the first comments made is "Use 'fazooloo' in a sentence." A response such as "I was playing scrabble and I was asked to use 'fazooloo' in a sentence" is generally not appropriate. Besides being sarcastic, the sentence doesn't convey anything about the meaning of the word. The questioned term was the object of the sentence and performed no action of its own. You could substitute any term and the sentence does not lose any meaning, but doesn't improve either.

A dummy data class is like a term that can only be used as an object in a sentence. If no sentence exists in which the dummy data class performs the action, it has no purpose but to be manipulated by others. This has various implications, such as encapsulation violations, but I think the sentence analogy simplifies the reaons to avoid dummy data classes.

Martin Fowler has a bliki post about Anemic Domain Models. One characteristic that makes a domain model anemic is the lack of behavior in the objects. Furthermore, I think the domain objects must have domain behavior.

This distinction can have subtle design implications. I worked on a system where we had an elabrorate domain model (or so we thought), but the classes where really dummy data classes. When I pointed this out, others on the project claimed that since the objects knew how to persist and load themselves from the database, that this was their behavior. But from the domain perspective, the objects did nothing. Furthermore, if you then look at the implemented design, there were other smells such as violdation of the Single Responsibility Principle, as the objects where part domain, part technical infrastructure. The design of the system would be greatly improved by starting with the elimination of dummy data classes and following your nose from there.

So, when designing your classes and their collaborations, make sure each class passes the Scrabble Test.

Brian Marick recently posted a blog entry noting the importance of marketing agile development to executive management. As stakeholders, management stands to gain the most from agile development.

The timing of Brian's post is somewhat coincidental, as this topic has been on the forefront of my mind. I think the next phase of generating agile adoption is to bring the campaign to management. It bothers me that I see mostly developers and technical professionals at conferences and very, very few members of management, particularly senior management.

I've been discussing this topic with people much smarter than I, in particular my wife. She has an MBA and works in marketing. Based on my discussions with her, the following are some ideas for raising the visibility and adoption of agile development methods to senior management.

Audience

Executive and senior management, particularly CIO's and CTO's, should be the demographic of this marketing effort. This poses some challenges, as such managers are generally removed from the actual development efforts and don't have much first-hand knowledge of the problems with traditional, heavy-weight methods. Making matters worse, middle management frequently withholds details about complications and, at times, reports a more successful depiction of projects than reality. Middle managers (those in the trenches) are the real "customers" of an agile process, but they are invisible; they have low public visibility and are a needle-in-a-haystack for a marketing plan.

Part of the challenge will be educating senior managers, while "saving face" for the middle managers, as we ultimately need their support.

Brand

Brand, brand, brand. It is the key to marketing. A brand defines the expectations of the vendor / product for the customer. It is the reason you choose product A over product B. For example, Nike caters to the "hard-core" athlete, be it recreational or professional. Volkswagen is about the "serious driver". Such strong psychological and emotional elements are quite common in consumer brands, but they can have a place in business brands as well.

This is the first action item for the Agile Alliance: define the brand of agile development. More precisely, what is agile development? The answer must be succinct and precise. It may vary for different audiences, but the core message must be the same.

This is a major challenge for the agile community. There is much debate over the question of "what defines agile?" and "which methods qualify as agile?". The goals and ideas of the Agile Manifesto, Agile Alliance and agile community have developed and are continually being revised.

But in order to have a brand, we must appear to speak with one voice, with one consistent overriding point of view. A brand defines the product. Consider the situation in which a business is choosing among multiple vendors. An organization will not trust a vendor whose message waivers and doesn't appear to have its act together.

Furthermore, the agile brand needs to be about more than ROI or business value. How would this be different than the claims of any other methodology, particularly the high ceremony, traditional processes? The ways in which agile development is different are important, but so are the commonalities of agile development and any other sound business theory or practice. (We can't have claimed to re-invent the wheel; business types will assume they know business better than we do.)

This doesn't mean there must be one agile methodology. The Agile Alliance can be the "parent company" that has multiple product offerings, each appropriate to a different context. But the overall message must be clear and consistent. We must determine the 30-second elevator conversation that answers the question "Who is the Agile Alliance and what is Agile Development?"

Getting Started

Many people don't know the Agile Alliance even exists. Its important that people associate agile development with the Agile Alliance.

I think the trade shows, conferences and journals that cater to CIO's/CTO's are a good start. I don't know what efforts have already been directed toward this, particularly sponsored by the Agile Alliance.

I know there was an executive track at ADC this summer. I don't know how successful it was. I think tutorials, seminars and workshops targeted to executives are a good idea. I think the agile community should invite any contacts they have in executive management.

I also think we should "recruit" the help of those in the business world. For example, Rob Austin is a Harvard Business School professor who has a strong interest in agile development and his research is about software development. I believe many in the agile community have a good relationship with him (among others). These individuals can be valuable resources.

Information Resources

Assuming we get the attention of executive management, we need to be prepared to provide information that is relevant to them and directly addresses their concerns.

There needs to be a catalog of agile practices and some guidelines regarding their approach. The roadmap section of the Agile Alliance website needs to be flushed out. (I happen to have a particular interest in the is topic, as does Steve Berczuk.)

Executives will want metrics that quantify ROI of agile development over other methods, adoption rates, success rates, etc. Information from the Standish Group's Chaos report would probably be useful.

Challenges

The Agile Alliance is a non-profit group that doesn't control or directly sell agile methods. Therefore, the requirements are similar to those for the consortium that markets milk.

I would expect an executive to request referrals from the Agile Alliance and she would expect the referred consultant (or firm) to deliver an "official" agile development process. Once you build the brand, it is important to maintain that relationship and protect the trust and expectations of the market.

This raises some concerns. How should the Agile Alliance provide endorsements? (I think some form of a referral service will be necessary). Questions about certification are a natural progression, which opens a huge debate. For example, a few months ago many in the agile community (including myself) went on the record to oppose SWEBOK. Will we eventually need to form our own version of SWEBOK?

This is somewhat a moot point. There are many strong forces already trying to standardize the industry. It might be negligent of the Agile Alliance to not cast its hat in the ring. This also becomes more important as agile development goes mainstream; most existing practitioners of agile development understand the principles of agile and faithfully practice it. I fear many mainstream adopters will claim to be agile and not understand it.

The challenge for the Agile Alliance is to remain "agile" and not bureaucratic, while maintaining some degree of conformity and unity. Brand integrity is necessary for successful marketing.

These are just some ideas. I think some attempts have already been made to market agile development to executive management. I think devising a marketing strategy raises many issues that the agile community must face and make decisions about. This will challenge us, as formal organization general complicates a good idea.