The event-driven approach in Agile modeling

Software development is a learning process. In order to understand what to develop, you need to know the domain to model by your software, and this is a difficult activity.

09 feb 2015

Software development is a learning process.


In order to understand what to develop, you need to know the domain to model by your software, and this is a difficult activity. Indeed, a lot of time is wasted in meetings in order to get more and more elements for writing the analysis.


Often, to carry out an analysis, a “traditional” approach is used, typically involving the so-called domain experts, namely those people identified by the customer because they know the process and are able to explain it in those meetings rich in questions and answers. Often, more than people, you’d better to talk about one single person, with all the risks involved: subjective view and even no thorough view for lack of time.


As for the analyst, by designing the domain, he/she risks to further simplify the expressed needs to give an answer through the tools he/she can master better. Obviously, the customer, who does not have the technical background to assess the choices he/she made correctly, is not able to point this out to the analyst. The result is often underestimated in terms of structure and investment. You can easily imagine the result…


In these cases, how can you change this trend?


Recently, we experimented an interesting technique in the field of Domain Driven Design & CQRS; it is the Event Storming, created by Alberto Brandolini after years of experiments and observations. It was displayed at the Italian Agile Day in November 2012 for the first time. Its purpose is to obtain, in a relatively short time (a few hours, a whole day maximum) a photo that will constitute a model of the domain in question.
Let’s see what are the important things to do:


  1. Involve the right persons and close them in the same room: some of them have questions; the others have or should have answers. It is important that there is not one single person, but several people (obviously if they exist) able to show the domain functioning. The ideal thing, in DDD view, is that there are people allowing to identify and define the several bounded contexts that make up the domain.
  2. Gamification: the context should be attractive and involve, keeping a “non- stress” profile, a game.
  3. Unlimited modeling space: leave the notion of paper or whiteboard. The ideal thing is to give the feeling that there is not a limit of space but it is potentially infinite (a roll of toilet paper to hang on the wall or unroll is the ideal support)
  4. Use of simple notions: let’s do away with technicalities. Everyone must be able to understand what he/she is talking about and how.
  5. A person, a felt tip: everyone must feel involved and free to express him/herself.
  6. Remove possible obstacles: it is better to avoid that people can be distracted from what they are doing (trivially, for example, by stacking chairs and avoiding that, while seating, they can get away from the context during the event).


Then, people should understand what they have to do: after giving them (and us) some post-its of a specific color, they should write what they think are key aspects of the process that the domain must include (controls, subjects, events). They can do it freely, where there is some space, without worrying about the fact that these events should have an order.


Later, you need to give them post-its of a different color that can be used to add notes and ideas to the post-its put up previously by all participants; they can be related to remarks, additions or solutions regarding the object of the considered post-it.


Most probably, there are some post-its where remarks, additions or solutions that clash one another are collected. For this reason, people should confront what hung not in a conflict view (the reason is yours or mine) but collaboratively, trying to reach a shared view, because who has a different idea on a problem is not an enemy but an ally towards the same enemy represented by the problem itself.


Once this stage is ended, you enter the phase of “rearranging the pieces of the puzzle.” They need to give priority and understand together which place to give to specific things. Going in different directions while exploring the domain helps to avoid neglecting aspects that, even though may be unnecessary, could turn to be more important than others.


Our experience?


Surely positive: those present were able to define better some concepts that were unclear between the customer and us and between the stakeholders themselves as well.
Of course, the result cannot be considered thorough, thus a further analysis is needed to define the domain properly. One thing is certain. In this way, you can really understand the customer and his/her environment tangibly and with fewer prejudices than a “classic” analysis, reducing the risk to neglect aspects that can turn to be real boomerangs.
Undoubtedly, paying more attention to the decision-making process, unforeseen events are reduced.  This help to collect information, save time and define what necessary in a better way.


Sharing and negotiating are ways to define a solution, especially when it is difficult to find the necessary clearness to start on the right foot.