NCrafts 2015 – EventStorming Workshop

sticky-notesEarlier this year, in may, I attended a 2 days conference about software craftsmanship in Paris: NCrafts. I also been able to attend a one day workshop about EventStorming.

This workshop was hosted by Alberto Brandolini and Mathias Verraes. Alberto is the founder of the Italian Domain-Driven Design (DDD) community, he runs Avanscoperta, a training company in Italy where he is a consultant as well. You can also encounter him as a speaker in various conferences across Europe. He is the one that came with the word “EventStorming”.

Mathias is an independent Belgian consultant focusing on software practices, on dealing with legacy systems and especially on DDD. Like Alberto you can meet him during conferences or during workshops, there is a list of all of his incoming ones on his personal website.

So you probably guess that EventStorming is about Domain-Driven Design and how to model it. I did this workshop because I consider that as professional software developers we have to understand the domain we work on in order to create the best possible applications.


To practice EventStorming you need space on a wall, a lot of space. You also need sticky notes, a lot of them with different colors. You have to bring markers for everybody as well, the rule is at least one per person. Remove the tables and the chairs to be able to move freely in front of the wall.

Once the room is ready you need people with questions (the developers) and people with answers (domain experts, business analysts) in order to model the domain of the application.

An events driven approach

Everyone is ready, they have sticky notes and a marker, time to ask the first question: What is the most important event in the system? (from a domain point of view). In other words: what is the goal of the entire application? If the team works on a project without knowing what the main goal is, they will probably end-up with a “not so good” product.

Once you know the Event, write it on a sticky note (orange one) and put it on the wall. Most of the time the event are written using participle past phrases (InvoicePaid, UserRegistered, …). Now it’s time to model around this main event by turning back time: What is the event that occurred before? And before that?

The goal is to find the entire event chain that leads to the main event, this will give you a good idea of what is happening in the system from a business perspective. You will create something like the following picture (this is just a small example):


If you are not sure about the necessity of an event, you can ask the domain experts if they care about the event or not, they know if it is relevant or not. For instance a “ButtonClicked” event is probably not relevant from a business point of view, except if the domain you work for is about buttons being clicked. Focus only on domain events, not on technical ones.

Linking the events

Now you have your events chain, the work is far from over, you need to add the “links” between them. An application cannot just be a succession of events. What happened between an event and the one before? What kind of action is required? For example, what happened between “InvoiceSent” and “InvoicePaid”? The client has to pay the invoice!

This last sentence looks obvious but it contains two important components for the EventStorming approach. The first one is the Command: “pay the invoice”, this is the action that has to be done. Time to change the color of your sticky notes, take a blue and write the command on it (Pay invoice) and put it between the two events.

Sometimes when you think of the command needed for an event to occur you might discover that there are more events in the system than you initially thought about or some are missing. If so add them on the wall where they belong, you can add new events at any time.

In “the client has to pay the invoice” there is another valuable information: the Actor, the person/system that acts on the application and launch the command. In this case the client is the actor, put a yellow sticky with the note “Client” on the command post-it.

Now you have a more detailed version of the domain, something like on the following picture.


One last thing regarding the commands, their execution can produce several events, it is not something to avoid, it all depends on your business domain.

And actors can be external to the system, in this case you can use a different color of post-it (pink) in order to identify them quickly.

Adding more information

Producing an event is the work of a command, yet the output of a command is not necessarily always the same, it depends on the Business Rules. For example, given a scenario where a user wants to log in, the expected event is UserLoggedIn. But what should happen if the username and the password are incorrect? We definitely don’t want the user to be logged in the application, in this case the “Log in” command has the following business rule: username is known and password is correct for the given username.

The business rules can be written on another kind of sticky notes (big and yellow) when the rules are quite specific, not like in the example I gave. Otherwise you will pollute the wall with irrelevant post-its containing obvious information.

To apply the business rules, a command needs information to know what it should do. In the log-in example this information is the username and the password. It is called the Message and it holds the data for the system.

Use a post-it (green) to list the data needed by the command and put it beside the related business rule/command couple. This way you are able to see where are the commands with complex business rules and what are the data needed.

After all of this you will have something like this:


As you can see, you really need a lot of space and you quickly locate every type of notes. And on this picture the entire model was not complete even after an entire day.

Do not be frightened by the time it took, you are not forced to model the entire application in a row, do it step by step, start with a single sub-domain. You will add the others during the next EventStorming sessions using the base you have already created.


I really enjoyed this workshop, I liked the collaborative approach of the EventStorming, everyone can be involved. It gives a very good representation of the business domain, what it should do and how.

Since the exercise is done with domain experts they use domain terms and therefore you are able to extract the ubiquitous language from the EventStorming session.

The format also favors story telling which are very helpful to gain knowledge of the business domain (“Most of the time it works that way but on rare occasion it works differently like this time when…”).

To summarize: An Event is the result of a Command, triggered by an Actor, following a set of Business Rules using the data of a Message.

A big thanks to Alberto and Mathias for making this workshop an awesome experience, do not hesitate to check their works on the topic, there is plenty of information they can teach you about EventStorming.

See you next time!

And here are some more pictures.

This slideshow requires JavaScript.

Extreme Programming: Open Workspace

open-workspaceAs professional developers it is important that we can communicate with each other easily. Since the face-to-face conversation mode has the highest bandwidth it is essential to have a workspace making these conversations easy.

The whole team should share the same office space to work as closely as possible from each other. There should be no wall between the team members.

Face-to-face conversations

Imagine you need to ask a quick question to one of your co-worker about the task you are working on. If this person is just next to you, you can simply ask and get the answer you are looking for almost instantly.

On the other hand if this person is in an office across the building you might think twice before going to see this person to get the information you need. Maybe you have an instant-messaging software to reach this colleague quickly, but it is not as effective as face-to-face conversation.

In an environment where face-to-face conversations are facilitated, the entire team communication is improved. A developer can ask another developer about a technical topic. A developer can check his/her assumptions with the business analyst (domain expert) and correct them if needed. A tester can show an invalid behavior to the developer to help him reproduce the issue to fix it. The project manager can ask a developer to give a situation report for a specific user story.

Of course all of these communication examples can be done with instant-messaging or email but it will take at least minutes (most likely hours, days?) to share the same amount of information where it takes seconds with face-to-face conversations.

Collaborative work

With an open workspace for the team it is likely that you will also have plenty of space on the walls. These walls are perfect to display information for the team, you can put a scrum board or a kanban board on one of them, this way the entire team is able to see what have been done and what has to be done.

Whiteboards are also very helpful for the team, they allow the developers to draw diagrams to share and discuss them with the rest of the team. And since this activity is made in the open-space more people can come in to give their inputs to improve it: collaborative work is done easier.

And of course since Extreme Programming (XP) favors pair-programming it is way easier to achieve it with an open workspace where each developer can sit next to another one. I’ve never worked in a cubicle environment but I don’t think it fits pair-programming sessions. And no, I don’t consider cubicle environment as an open workspace.

Having a “war room” kind of workspace for a development team can increase the communication by facilitating face-to-face conversations which is the most effective way to share information. There is also a lot a space to display boards, graphics and various information for the whole team, everything is visible and becomes more “concrete”.

See you next time!

Extreme Programming: Sustainable Pace

Team-runningAs professional developers we work iteration after iteration on our project. Some projects are longer than others and it is likely that when one ends a new one begins. Therefore it is important for the programmers to preserve their energy level week after week.

When a developer is tired, his focus is dropping and it is likely that he will do more mistakes than usual and the quality of the development will decrease.

A marathon made of sprints

Finding the pace for a development team is hard because it should move as fast as possible but without getting tired in the long run, in a way it is like a marathon.

Yet at a lower level it can be seen as a sequence of small sprints with resting periods between each of them. With this technic the developers are able to work hard with a good level of focus on their task without losing their energy on the long run. This only work if the resting period are respected.

The pomodoro technique is based on this approach, where you work on a dedicated task for about 25 minutes, then take a 3-5 minutes break before starting a new “sprint” of 25 minutes, and after 4 pomodori take a longer break (from 15 to 30 minutes).

That’s a lot of breaks! Yes it is, yet these breaks are mandatory if you want the programmers to replenish their energy level. Because during the 25 minutes pomodoro they stayed highly focused on their task and it is a demanding exercise regarding mental stamina.

Managing overtime

With the practice of Extreme Programming (XP) it is advisable not to work over 40 hours a week, beyond this point it is likely that the pace will slowly decrease over time.

But sometimes working on a project requires some overtime in order to reach a given milestone, it is acceptable only if it is unusual. And if during a week the team is working extra time for the project, they cannot repeat this abnormal experience the week after.

In order to save the energy level of the team members and, by extension, their pace, the resting periods have to be respected. Otherwise it is likely that the developers will lose their focus over time and the product they work on will suffer.

Developing software is a mentally exhausting activity, it requires a lot of focus in order to get things done the right way. Refilling the batteries is essential to avoid any burn-outs among the team. You can use the pomodoro technique to switch between “energized work” periods and resting periods, this will allow you to take care of your tasks with a good pace without losing all your energy.

See you next time!

Extreme Programming: Collective Ownership


As professional developers it is likely we have to work in a team with other developers. Even if it might happen that each team member has its speciality, it is important to share the knowledge using collective ownership.

Using this practice, every member of the team is encouraged to contribute to all parts of the project, each developer is responsible for the entire product and not only a part of it.

Collective code ownership

Each programmer can modify every line of the code base in order to fix a bug or to refactor in order to make the code cleaner.

Changes do not have to be done by a senior developer, a team leader or an architect, there is no bottleneck when an update is needed. Yet, this not mean that the younger developers should not ask for advises before making the change.

If everybody can change the code, how to prevent introduction of new bugs or regression? This is a commendable concern and it should concern you, short answer: tests!

Extreme Programming (XP) promotes the creation of acceptance tests, and also Test Driven Development (TDD), then it is likely that you have an entire test suit to help you avoiding mistake when changing code.

Pair programming sessions are also very helpful to discover how the system behave in its different modules, the knowledge of the application code base is shared.

Toward a self-organized team

When the code base is shared so is the responsibility for the well-being of the project. Every developer has the ability to improve the modules composing the application, to fix the bugs, to improve the overall quality of the project. The whole team is responsible for the success of the project.

In a team with only specialists, developers only responsible for their scope, you might have an organization like the one below.


Each team member has its speciality and keep it for himself and does not interfere in the speciality of his teammates, only the lead developer might have a vision of every aspect of the projet.

Now imagine that one of the specialist leaves. Do you ask the lead to take his place since he is the only one who know what this member was working on? You can hire a new specialist to take his place but this person will to be ready for the job right away.

By practicing collective ownership, you can end up with an organization like the following.


The knowledge is shared among all team members and everyone is able to work on each speciality. If one of the developer leaves the project, the rest of the team is able to take care of its work while training the newcomer.

“But as a specialist, I am essential to the team and I will not be fired. In a collective ownership team I am expendable”. Well if you live in the fear of being fired and then you try to protect your scope as much as possible, you might ending up protecting you too much and falling into a blame culture environment. And I think that nobody is irreplaceable, sure your team will struggle to replace your skills but they will with time.

On the other hand, in a team where knowledge is shared, the developers works closely to each other and they build trust. In my opinion it is more likely that this team will become more and more efficient over time. And it will be silly to break this harmony by firing someone.

These two team organizations remember me of the “Notes to a software team leader” book. One looks more of a command & control type of environment and the other one more of a self-organized team environment.

Collective ownership helps a team to share knowledge, both technical and functional, between the developers. Every member is able to impact each module of the project for bug fixing, refactoring and improving the product. The team becomes a whole and is no longer a collection of individuals.

In order to practice collective code ownership it is important to also share other practices such as TDD, acceptance testing and especially pair-programming.

See you next time!

Extreme Programming: Pair Programming

pair-programmingAs professional programmers, our goal is to produce high quality software for our customers. Pair programming is a helpful technic that allow to reach this goal.

Developers do pair programming when they sit in front of the same computer to complete tasks for a new user story. To me it is a different job than pair debugging, where you work on existing code in order to fix it, in pair programming you create new functionalities for your application.

At first it can be seen as a waste of time since two team members work on the same machine and it might look that the capacity for these programmers is divided by two.

I do not share this opinion, to me pair programming is a very good way to improve efficiency when working on a new feature.

Staying focused

When you are two it is likely than there will be always one of the two developers that knows what should be done next. It is helpful when one in the pair starts to feel a bit tired, the other one can continue and you rotate regularly. This will prevent any loss of total focus during the development phase, but the pair should still do some breaks from time to time.

When one of the programmer is coding the other one looks at the written code and can detect mistakes early on, it is an effective live debugging technic.

Share knowledge

When a pair of programmers works on the same user story together they will share the knowledge of the implementation. They will both know how it has been developed, this way your team is no longer dependant on a single developer for knowledge of a specific feature.

Beside technical knowledge you can also gain a better understanding of the business knowledge related to the user story you are working on. For instance instead of having a developer working on the front office workflow (from a business perspective) and the other one on the back office one, both developers can pair-program on the two subjects to understand how the system should behave on the front side and on the back side.

The code is also written by several persons and therefore there is no code ownership, this will avoid situation like “do not touch my code!” or “I won’t touch code”. The code is owned by at least the two programmers forming the pair, a step toward egoless programming.

Share skills

Pair programming sessions are also good to learn new practices, tips and tricks. When working in pair you can simply discover a new shortcut for your favorite IDE you were not aware of.

And most of all pair programming can help you discover new skills and practice them. For example you can improve your Test Driven Development (TDD) technic when working with a pair that is more experienced than you are. During a pair-programming session, we (my teammate and I) developed an entire topic using TDD, one wrote a failing test and the other one had to make it pass and then write a failing test and so on. This was a very rewarding experience, we were both new to this yet we practiced together and improved our knowledge.

Pair-programming is a social activity, it takes time to learn and can be frustrated from time to time. Yet it is very helpful to share knowledge amongst your team, you can always learn something new from one of your peer.

This practice can seem like a waste of time but since the pair is always focused on the topic, it can go faster with a higher level of quality. You can find a study about costs and benefits of pair-programming here.

See you next time!

Extreme Programming: User Stories

user-storyAs professional developers, our role is to write high quality code within our applications. Yet this is worthless if it does not provide any value to our customers.

There are not much companies that will hire you to let you work on whatever you want. These businesses have customers that need new features and improvements in the software they buy and use.

It most cases you will work in an industry you know nothing, or almost nothing about. But don’t worry, you will work with people who know it, the business analysts. They know how to provide value for their customers and they need talents to implement it: YOU! You form a whole team.

In order to ease the specification and especially the prioritization of development in an “agile” environment, you can rely on user stories.

User Story

A user story describes a single requirement for the system. It is expressed by the business team and it generally written as a sentence matching the following format:

As a <role>, I want <goal/desire> so that <benefit>

The details are not defined within the sentence because they are likely to change with time even if the main goal will not. Details are discussed during conversations between the business analysts and the development team.

The use of user stories allow the developers to be able to provide a low risk estimate and by extension a budget for the feature. It is focused on the user needs, specific technology details should be excluded (data base schema, algorithm, …).

The role

In the sentence describing a user story a role is defined. By doing so you are able to detect the user of the system. It is likely the person who will know all the details you need to complete the task.

If the user story needs a new User Interface (U.I.) and this person is the final user of it, you should ask him how he wants to use it. Because I think that a UI providing the goal of the user story but with a really bad User Experience (U.X.) is not as valuable as it should be.

The goal

In a user story the goal is the new feature that needs to be created. It defines what the final customer/user wants and needs. This is the part of the system that needs to be well crafted, from a code perspective and from a user experience perspective (see previous section).

The benefit

The last part of the user story describes the benefit. This way you can understand the value it provides to the customers/clients. It can also describes the final result and if you know it, you can test it!

If the benefit of a user story is hard to write down maybe it means that it is not as valuable as you think it is. And therefore there might be others user stories to prioritize first.

In an agile environment such as Extreme Programming (X.P.) the use of user stories allow the business analysts to express their needs for the customers without writing an entire documentation containing every details. They are focused on the user, the goal and the benefit. This way the development team should be able to properly estimate it and they gather the details using a good communication in the whole team.

See you next time!

Image credits:

Extreme Programming: Whole Team

whole-teamExtreme Programming (XP) is one of the agile software development methodologies. Therefore it focuses on short development cycles and to do so it has defined several practices to follow when working with it. In this blog post I will introduce the first one: Whole Team.

As a professional developer I firmly believe in collaboration among a software development team. I believe that is by working together that we are able to create more valuable products.

The developers, the testers, the project manager and the business analysts (sometimes called “product owners”) have a common goal: product value for their customers. This is why they have to work closely with each others and they should be able to speak with each others easily, a good communication is mandatory.

Every role is important in the organization and everyone as a part to play in the project. The business analysts know what has to be done, they represent the customers needs. The developers know how it has to be done, the testers ensure that the quality standards are met and the project manager makes sure that everything runs smoothly.

I know that all of this makes sense, yet sometimes I feel like the common vision is lost in a software development team. Maybe you have experienced the well-known “programmers vs the business” work environment, or maybe the “developers vs testers”.

I know that I have experienced similar situations and I was part responsible for it. Because I only had consideration for my world, where coding is king and everything else is secondary. Now I keep in mind the “big picture”: creating value for the clients. It still requires writing well-crafted code, it is my role in the team. I have to make my teammates understand my point of view and I also have to understand their.

When working in an agile environment, in Extreme Programming for instance, you have to keep in mind that you are part of a whole team. Everyone as a role toward the creation of value.

See you next time!

Image credits: