I have just spent two weeks locked away with two domain experts (users) and a team of ‘L’ plate modelers (myself included), modelling an application that we are about to start building. We got in Jeff De Luca of Feature Driven Development fame to teach and guide us in a process called colour modelling. We started with a two day training course in colour modelling and then we were into it. For two whole weeks building up our understanding of the system and capturing it in models using colours that represent the various archetypes.
The team went through all the highs and lows that characterise the development of a team, so coming out of this we ended up with a strong team of people. The team also now owned the resulting model of the application that had been built up, there is now a history there, blood had almost spilt over names of things and it had all been redrawn a couple of times, changing what was there wouldn’t be done without a fight.
The exercise of building the model revolved around the users walking us through small areas of the process that we then produced a model for. Requirements and use-case documents that had been written were there for reference but the user was the primary source of truth.
One thing I hate about any requirements document is that there is always interpretation involved when designing the system that will meet these requirements. It kills me when the users come back and point to a line in the requirements and explain how this means you should have actually built something completely different to what you had assumed. When we were modelling because of the way we are capturing the requirements in the model, things are very explicit, so there is only one interpretation. On more than one occasion the users would make a comment that contradicted something we had previously modeled and we knew at that point that they had changed the requirements and could seek clarification from them there and then.
Getting so much of the users time (2 weeks) seemed like a tall order before we started this but we ended up with almost 100% of their time during this two weeks which was great. Having the users there was vital as previous understanding that were captured in the requirements document got tested as part of each walk-through. The users as much as the modelers were challenged because there was nowhere to hide and in the early stages there was some rethinking that had to go on but they quickly realised what was required of them, so came prepared.
Out of this two weeks we have a model, yes but we have so much more than that. Agile promotes “Business people and developers must work together…” which for one reason or another is easier said than done but this process of modelling gave us that understanding between the technology team and the business. The team that built the model has an intimate understanding of the domain from a business perspective and from an implementation perspective. Best of all we have a core group who are a performing team!
The next question is how do we repeat this process for other projects, Jeff brought so much to the team, it just won’t be as simple as following the process.