Christmas must be nearly upon us as it will soon be XP Day 4.
The programme for XP Day 4 looks fantastic. It was brilliant last year and this year looks even better than last year. Hopefully see some of you there.
If you have read through my older Blogs, you will know that my approach to analysis is heavily influenced by David A. Kolb's circle of learning model. The idea behind the model is that we start with a concrete experience. From this concrete experience, we abstract a model. We test this and past concrete experiences against the model. We reflect on whether the test is successful or whether the model needs further refinement. The decision to upgrade the model is not a binary decision. We often live with models that work well enough but not perfectly (Consider classical physics versus quantum physics. We still use classical physics even though we know a lot of it only works most of the time rather than all of the time).
So how does this apply to business analysis? Pretty much directly.
Start with a concrete observation. Employees are hired by a department. Model it. Employee and Department Objects linked by a "hired by" one to many relationship. Test the concrete against the model and reflect. Yep it works. Then consider another concrete observation. Some employees work for more than one department. Urm. Compare to the model. Model does not support this. Change model, now a many to many relationship (always a bad smell). Another concrete observation. Departments are charged different amounts for a particular employee. Check the model. Nope, doesn't support that. Change the model. Add a new object "Charged To".. etc. etc.
In traditional analysis, only the model would be used. In Agile (Test/Behaviour Driven Development), the concrete observations are more valuable than the model. Many models may support the behaviour required of the system. These concrete observations should be recorded as acceptance criteria for the stories.
The moral of the story. Modelling isn't necessarily bad, just don't throw away the valuable stuff and keep the not so valuable stuff. Traditional modelling is a bit like peeling potatoes and then keeping the peelings and throwing away the potato. (Then again all the goodness is in the skin so perhaps thats not such a great analogy.)
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.
Andy and my article on Business Value has been published on the Cutter Website. See here.
(IT) Projects should deliver a business value of X for a cost of Y. There is uncertainty or risk associated with a project. A project can cost more than Y. It can deliver less value than X. In some extreme cases, the project can damage the existing business model, actually destroying business value. (IT) Projects can learn from Financial Market in its management of risk, especially the use of Real Options.
Risk is uncertainty. When you know something with certainty, good or bad, you manage the situation, there is no risk associated with it. Financial markets manage risk using derivatives, especially options. Real Options are a way of applying financial option theory to project risk management. An option is “The right but not the obligation to do something.” Options occur naturally within a project. It is the role of the project manager to manage these options for the optimal benefit of the project.
Financial Option Theory tells us that it is never optimal to exercise an option prior to its maturity.
Traditional Waterfall Methodologies destroy options by making decisions earlier than they need to be made. They insist that the requirements are specified up front, that is the option to change the requirements is destroyed or subject to change control. Waterfall methodologies insist that the system is designed up front, making it difficult to change. This means that Waterfall Methodologies find it difficult to cope with uncertainty or change.
Agile methodologies keep options open. They allow the user of the software to change their mind on the requirements at any point up to the last iteration. Agile methodologies encourage continual design throughout the life of the project. Design is performed “just in time”. Keeping options open means that Agile methodologies are better suited to manage uncertainty and change.