..and dare I say, Strategic?
On the Domain-Driven Design group (http://tech.groups.yahoo.com/group/domaindrivendesign/), Bil Simser lays out a common question:
“It’s all great to talk about repositories and aggregates and context boundaries, oh my, but the real challenge is making that connection from theory to practice. Then taking it even further (because presentation style and book samples can only go so far) how to you apply it to real-world apps?”
A fair question, and one that in recent weeks has been much on my mind (apologies to the late Graham Chapman).
The key to transitioning from book knowledge to practice, is perseverance. Perseverance and cover, if you work in a big IT/development organization. It’s absolutely required to have executive sponsorship in order to move the organization in any particular way. It’s especially important to allow you to move towards any methodology that hints of ‘Agile’ as DDD does.
My approach (to move developers) has been to recommend “The Pragmatic Programmer: From Journeyman to Master” (ISBN: 020161622X). This one book changed my programming life. It led to my joining ThoughtWorks and it led to my current position trying to bring agile sensibilities to a large, developmentally conservative department in Southern California. There are several other technique books that are well written and great for developers.
As for the management (development and business), it really requires patient conversation and the gentle application of the five ‘whys’. There are also some great books available in this snack bracket. Craig Larman’s “Agile and Iterative Development: A Manager’s Guide“ (ISBN-10: 0131111558) is a good one, but there are others.
Eventually, if it’s possible, the management will hear what you are saying and sponsor a trial. You need to select your team carefully. As I’ve written before, occasionally there will be saboteurs assigned (wittingly or unwittingly). You really need to be disciplined, and perform the project ‘by-the-numbers’.
One key strategy I’ve found is to get to the users directly. You can start having conversations with them along the lines of “What bothers you about your job, day to day?” or “What one feature would make your work life easier?” These conversations break the ice, and if you’re doing it carefully, they will start talking to their management about things they like/hate about the applications they use.
I don’t use subterfuge though. I say what I’m after and why. I’ve found that the most important thing that management should consider is business value delivered, and because of that, I’m interested in the business reasons for the users’ actions. Very often, they are performing functions that have nothing to do with delivering value to the business. They are forced to do some arcane tasks to support an inflexible legacy application, or surprisingly, because no one asked what they were really trying to do, and why. Developers (usually under the gun to do something quickly) simply made assumptions about the technical way to accomplish what the user asked for, probably filtered through one or more intermediaries.
Ever heard of the childrens’ game “Telephone”? It’s not a surprise that users don’t get what they want most of the time; but I digress.
Once you have access to the users, get as much of their time as you can. Ask all the questions that can help you start to build that “Ubiquitous Language”. Iterate over the language and the concepts with a tight feedback loop, and you’re on your way.
If you’re having trouble getting to this stage, perhaps you need an agile coach to help educate the apprpriate people. I know a few really good ones. Drop a line if you need a referral.