Many IT projects are unintentionally disrespectful to the customer. They ask the customer to define inputs or process or calculations when all the customer should do is specify the output that will deliver them value. There is a disturbing fashion within Agile to take a UX approach where the user sketches out the input screens they need and the UX designer creates a "low" fidelity prototype that looks pretty in powerpoint or visio. Whilst this highly interactive approach is very appealing and satisfying approach for the UX person, it is disrespectful of the customer's time and it is fundamentally wrong as an approach. This approach has lead to failed projects.
But if the customer doesn't tell you the inputs, processes and calculations, who will?
The solution is Domain Modelling, or Business Analysis as it is also known, is a very unfashionable topic within the Agile community. Some authors appreciate the value of domain modelling but dare not speak its name. They refer to "Knowledge crunching" or "Gathering Up-Front Knowledge". Domain modelling is a very valuable technique but it traditionally has a number of drawbacks. First, it can take a long long time, so long in fact that it undermines the value it delivers. Second, it is prone to "analysis paralysis" where it thrashes around unsure of which direction to take and is not sure when it is finished. Third, domain modelling produces a model rather than examples which is what we need to drive an Agile development.
This workshop will show a technique that addresses these issues. A super duper fast analysis technique that has a very clear start and end point, generating a model AND examples. The approach, which does not have a name, is based on "knowledge smells".
The session will start at the point where the customer has identified the value that they want to achieve and their requirements (An output "report").
Step 1 (20 Minutes). The "knowledge smells" will be introduced by way of an interactive worked example. This will show the audience how to create a domain model (entity-relationship / object model) using a step by step identification of the "knowledge smells". The process ends when all of the "knowledge smells" have been addressed.
In addition, I will show how wire frames, use cases and state diagrams can be quickly implemented to design the interface with the domain model.
The "knowledge smells" are:
a. An item is on the output that is not in the model.
b. An item is on the model that is not on the output.
c. Two pieces of information in one place.
d. An entity is not related to any other entity.
e. One to one relationship.
f. Many to many relationship.
g. Undefined functions.
The knowledge smells will be distributed as cheat sheets to each member of the audience.
Step 2. (15 Minutes) I will then facilitate a second example where the audience tells me what to do.
Step 3 (30 Minutes) The audience will then work on an example of their own. They can work either as individuals or as a group. There will be three or four of us to go around the tables and help out. They can either provide an example from their place of work, or we will provide them with examples.
Step 4 (10 minutes). Feedback and learning from the audience
I will wrap up by briefly describing next steps. Now that we know what is needed, we can design the interfaces (API, File based and UI) that will be used to populate our domain model. This is where we engage our UX skills to create story boards (UX prototypes), which we will describe using Use Cases and State Transition Models as appropriate. (As an aside, starting with the input UI leads to a domain model that contains UI elements that are difficult to manage when the UI component is replaced by an API).
Co-presenters to be confirmed.