Jimmy just wrote a post on one of the "problems" with DDD to quote him:

"Even though DDD in itself isn't at all new, it's new to those that haven't tried it before, of course. And if you work in a big team with no prior experience of DDD, then it's very risky using it for a new and time constrained project. There are ways of reducing the risk, but it's still there and it's real."

It's a really interesting point of view and one I as a coach and instructor has runned into a lot of times and I think it ties into my earlier post about features being to complex for some developers.

Any new methodology, practice or technology is bound to be difficult in the beginning and as one will very quickly realize is that just because it works for the other teams product or the cool speaker on stage it might not work for me. These failures is more often then not a result of a cargo cult thinking where a team picks up a set of skills from someone else and just tries to copy the success.

It will almost always fail and that is what brings in the risk in the project. When you want to introduce something new in a live project you need experience, at least some experience mixed in with the "new guys".

There is several ways to get that experience into the project, you could hire someone like Cornerstone's coaches, Jimmy or other factor10 consultants to hold your hand through your first baby steps or you can make sure that your team has time to practice new skills (or combine both).

To practice I like to use Code Katas which let's me practice my skills over and over again on the exact same scenario. Allowing me to refine certain aspects of the piece of technology or methodology I'm pursuing.

Doing these practices will give you a more thorough understanding of what the "other guys" are doing and that understanding will eliminate some of the risk, reduce the overhead in real projects to introduce new things and eliminate the cargo cult thinking since now you can take informed decisions from your own past experience.

Oh, and the added benefit of doing these practices together in your team is that all will share a common viewpoint on how code should be written and competence transfer during one of these coding dojos is extremely high.

So, as any other thing in life; take time to practice a lot, practice alone and practice in group before you try the "real deal" and the risks will be minimized.