Agile Business Coach

Models and Stories

I am developing a lightweight methodology with the other Business Analysts ( Harvi Dhinsa, Atush Joshi, Robin shorrock and Luke Barret) at ThoughtWorks.... Where do those pesky stories come from in the first place.

On Friday I had a really interesting discussion with Robin about Eric Evan's Domain Driven Design and of driving out the domain model using Test Driven Development ( or even better Behaviour Driven Development.... Dan has got some really cool stuff up his sleeve that he should be releasing in about a month or so.).

Robin made the observation that the Developers drive out the Domain Model from the stories that are written by the Customer or Proxy Customer (Business Coach / Business Analyst). The customer writes the stories using an implicit domain model within their mind. This implicit domain model is the one that the developers drive out.

So here is the current process. The customer has their own internal domain model (I call them business models because 1, I'm awkward and 2, I like to rename things). They then write a load of stories based on this model. The process of writing these stories involves a filter (NLP talk) which gets in the way of communication. The developer reads these stories through another filter (More NLP. I've been sat next to Dan for too long.) which obscures the message but then they drive out the domain model through rich conversations with the customer. My main point is that there are lots of filters involved between the implicit domain model in the customer's head and the one in the code.

Now for a suggested process (It is an aunt sally so please be brutal). The business coach helps the customer to make their internal domain model explicit. This is documented on a white board (possibly using story cards to represent objects). The model should be hand drawn to give the developers a sense for the fact that this is a version 0 draft version of the model. The developers can then use this domain model as a starting point. The fuzzy nature of the presentation means that they know it is not perfect. As they drive out the domain model using TDD and through conversations with the customer, they can update the model on the white board. From my experience, a couple of hours effort with the right people in the room is all that is needed to elicit the draft domain model. If you are taking days or weeks to develop your model, you are taking far too long and you ain't doing it right.

Please start throwing the rocks.

Posted by chrismatts at October 16, 2004 7:40 PM