Everybody likes options!

Who doesn’t?

In our day-to-day life, whenever you have to take a decision, you almost always have lots of options. If your goal is to go somewhere, if it’s near from where you are and if it’s sunny outside, you can go for a walk or by bicycle. If it’s rainy, you can pick up your car or take public transportation. If it’s far away, then you’ll have to book a train or a plane. Now your goal becomes booking a ticket and you still have tons of options! You don’t have too much money? Go with low cost companies! You still want to reduce the price? Well, do not put any luggage in the plane’s hold and take only your backpack. Then you can choose the flying class: economy, first, business, … you can choose whether to use your miles or any other loyalty card, choose between different flight schedule, even choose where you want to sit! And it’s almost the same for the train! Everything is up to you!

The same goes when your goal is simply to eat! You’re lazy? Go at the restaurant! What restaurant? You have tons of options: fast food, Asian food, Italian food, … unless you live somewhere where there’s no restaurant at all, then the only options you have stand in your fridge! But when you’re at the restaurant, have a look at the menu: you see all the options?


Whenever you have a goal, something to accomplish, you always think about all the possible ways to reach it. And if for any reason the option you did choose doesn’t work, well, you simply pick up the next one on the list.

We love to have all those options; we love to be able to pick up the one that fits to our need.

So why the hell, don’t we have such options when it comes to software development?

I don’t speak about the way you will implement something, I don’t speak about the technical decisions here. You might have some technical options in mind depending on what needs to be done (unless there’s an enterprise architect in the way…) I Speak about how to reach a business goal.

Worst-case scenario: you only have specifications that tell you what to do. In this nice MS Word document where everything is written in advance, you don’t need to search for options: you won’t find a single one. Just do it like it’s described, the choice have already been made. Even if you’d like to do something else, you cannot, simply because you don’t know the business goal to reach and what are the measurements to check to know if you succeed. Just shut up and code! :-)

At best, you have a user story:

As a Customer, I want a brand new Refer A Friend page so that I can invite my friends to join and receive a 10% discount

Actually, the real customer need behind this user story might tell you another story instead:

We really need to increase the number of our customers because if we don’t then we might be in big trouble pretty soon.

The thing is that the user story doesn’t tell you that.

Creating a “Refer A Friend” page is just an option amongst others to gain more customers. It’s no more than an assumption that this option will do the job. It has been chosen upfront by some business people. But what if they’d have asked you? Would you have chosen to create a “Refer A Friend” page or something different? At least I guess you would have brought some other options on the table.

It seems obvious but you cannot have options without knowing the goal to reach.

So to answer my own question: we don’t have options when it comes to software development just because we often don’t know the real goal behind a user story or some piece of specifications. We don’t know what really is the customer need we’re trying to fulfill when developing a new feature.

Usually, what is written is specifications or described in user stories is not a goal; it’s just a way to reach a goal, it’s just a single option an assumption that it will work.

Think about how things would go if military ground troops would act like developers. They’d receive their orders as specifications from the military command saying exactly what to do. A nice and clear step-by-step procedure, written a couple of months before the d-day in order to guide them once on the field. Just like a poor developer they would only have one way to succeed in hand, just a single option. But in the meantime things have changed. Once on the ground the troops got quickly caught in a trap. It’s not their fault, though: it was not written in the specs!


Military do the contrary instead: they mainly receive the goal to reach from the commanders. They might have some options to start with, but it’s also up to them to bring some new ones as the mission evolves. The commanders trust the troops! They know that they were trained to react and adapt the right way as things change.

To solve this problem in software development, well, there’s no secret: you’ll need to bridge the communication gap between business stakeholders and dev teams. Communication and trust are key to success.

If business wants to keep up with specifications, why not suggest going a bit further with Gojko Adzic‘s Specifications by example.  This will help you to to cooperatively define the specifications based on real examples.

If you’re tied to user stories, then they should definitely sound like business goal instead of solution ideas (which is often the case). One simple way would be to find out two options that bring the same benefit. But an easier way would be to look into impact mapping where stories are not considered as commitments but options!


© Özlem Yüce from “How to train your HIPPO”

But the best thing to do might be to follow Jeff Patton‘s advice:

We don’t need an accurate document, we need a shared understanding

Discovering things collaboratively using Jeff’s User Story Mapping or Alberto Brandolini‘s Event Storming might be the best way to find options. Working together with business people will obviously let you know the real customer goal to reach.

Now take your shovel and dig up some options!

Does your code speak business?

There are many books and manifestos or even books about those manifestos :-) the aim of which is to teach you how to be more efficient. They provide you with diverse recipes and tools to be more efficient as a person, as a developer but also as organizations.

All those writings also have another important thing in common; they all say that in order to be more efficient you constantly need to focus on delivering value or even steadily adding value.

I did a presentation during a Paris Software Craftsmanship Meetup, where I tried to define what exactly value is and the kind of things you could put in place (and things to avoid!) to bring it down to your code or even within your tests.

Here you go!

Bridge the gap between dev team and business people! – Idea #3

This article is the third out of an unlimited series (let’s say at least 5!) where I’m gonna try to give you some ideas and easy things to put in place in order to bring your team closer to business people so that you can work collaboratively and efficiently with them.

Written so far:

Event Storming

In the previous post you read how Impact Mapping gives you the goal to reach and what are your options to do so, now it’s time to get more into how the system works.

An Event Storming session will involve almost the same people as for an Impact Mapping’s one but the aim is quite different!

Event Storming is about to find out all the events that occur in the system -> the business processes.

As Alberto Brandolini says:

Ideally, one would like to have participants coming from two fields: people with questions and people with answers. They provide the perfect mix of curiosity and wisdom.

Domain experts, the business people, know the system by heart and their job here will be to answer to a lot of questions! Those questions will be asked by a mix of different people (including developers, team leaders, testers, …), bring the curious ones!

After an ES session, everyone should be able to share the same vision on how the system behaves and the icing on the cake: everyone should share the same language to describe this (see the Ubiquitous Language).

First of all, you’ll need to find a big wall that you’ll cover with plotter paper or electrostatic sheets in order to be able to put sticky notes and maybe draw some lines and write text. Get some markers and different colors sticky notes. Decide to focus on a particular part of the domain (unless this could last more than a day!) and start by asking this simple question to your domain experts: “What’s the most important event that should occur in the system?”. If you’re working for a company that sells things on the Internet, and that you’re focusing on the ordering process, the answer should sound like “Cart checked out” or something similar. Now that you have that specific event, act as a time machine and try to find out together with the domain experts, what happened before this one. Write every single event on sticky note and put them in the right order.

Follow Alberto’s advice: Here’s the dogmatic color coding for #eventstorming follow it or perish!  :-) (source)


This first part of an ES session really focuses on outcomes. Here’s a simplified version of what you should have:


Now that you know everything that happens before a cart is completely checked out you can focus on the causality: the corresponding commands that lead to those events. Put another color – blue if you don’t want to perish ;-) – sticky note on every events and write the command name (you can also draw the actor that fires the command – User/Job/Time/…). Here’s another simplified version of what you should have:


Look what we have here? The method names of the not yet written application code! How could you be more close to business people if even your code speaks business? ;-) That’s the point where your code really brings business value!

And where the magic happens is when the QA tester can even start to write BDD styled tests during the ES session:

Given a Customer Logged In
When he Selects an Item
Then the Item should be selected in the Cart

I must admit this is a too simplistic example but you get the point, right?

At the end of an ES session every people involved knows exactly how the system works and behaves, what are the events that should occur and their corresponding command (and actor). You should be able to point out potential conflicts or missing concepts but new opportunities as well! Last but not least, everyone shares the same language and did speak together!

Mission accomplished!

Bonus: If you’re into DDD, Event Storming can even bring more than that as you’ll be able to find out the Bounded Context and Aggregate Roots of your system.

The Ubiquitous Language

Project Manager: -"Hey, I found a bug on that page"
Developer: -"mmm, where exactly?"
PM: -"There, the market is not displayed correctly"
Dev: -"The what? Oh, you mean the football match name?"
PM: -"Yes..."
Dev: -"I see, I'm gonna warn the tester"
Tester: [BUG2435 Status: Reported] The event name is not displayed correctly on homepage

Here’s the kind of familiar example you might hear every week. This short dialog illustrates one of the most common problems we experience in software development: people do not share the same vocabulary. In this brief example the different characters have used 3 different ways to name things. It’s easy to imagine that business people have their own way to name that too, and members within the same development team could have different naming as well!
This might not look like something really important here, but think about a more complex system that deals with concepts ways more complicated than a single football match. What would happen if people do not share the same vocabulary?

I had a colleague that had a 2 columns sticky note he uses as reminder where he wrote on the left side the word his team is used to use and on the right side the corresponding business term. Well, this might help but wouldn’t be easier to share one common way to name things?
The worse thing I saw was that brilliant developer. He was that guy in the corner. The less he was dealing with business people and the less he was bothered by someone else, the more he was happy. This guy was so away from the reality that he was inventing his own terms! This kind of behavior is extreme of course, but it illustrates quite well the problem. If people don’t share the same vocabulary, the code will be very hard to read and understand thus maintenance costs will increase… just for a matter of vocabulary.

I recently participated in an Event Storming workshop animated by Jef Claes & Tom Janssens at NCrafts conference. First aim of Event Storming is to talk with a domain expert and try to find out all the events that occurs in the system (Event Storming has many other benefits, but that’s a bit off-topic, have a look at Alberto Brandolini‘s  blog here to learn more). We wrote the first events just after a short description of the subject by the expert. Those events were looking like “Shop Keeper Registered” or “Shop Keeper Account Updated”. After having talked a little bit more with the domain expert, it appears that the “Shop Keeper” term was not correct. The expert was using the “Partner” term instead. What if this was real life and that developers were keeping on using “Shop Keeper” instead of “Partner”? Let’s imagine the developer that needs to fix a bug on the Partner Registration process: he will search for any “partner” occurrence in the code and this will produce no result! He will need to struggle a bit to find the right place to fix the bug and then, he might add “Shop Keeper” = “Partner” on his 2 columns reminder sticky note ;-)

How could your code bring value if it doesn’t speak business?

Uncle Bob said that names in code “are the most powerful tool that programmers have to communicate with each other” and that “developers should use names to Reveal Their Intent and Avoid Disinformation“. Makes pretty much sense!

People often neglect the need to share the same vocabulary, they simply do not care.
Won’t you think that it would be easier for every person involved in a project to share a common way to name things?
What if the same vocabulary would be use from the business requirements to the software code or even the test code? Wouldn’t it ease the communication and the understanding of every one involved?

People always complain about communication between business guys and developers. Start by speaking the same language!

The Ubiquitous Language is the term used by Eric Evans in his Domain Driven Design book. The idea is to build a common language shared by everyone involved. As Martin Fowler said: “the language needs to be rigorous, since software doesn’t cope well with ambiguity” :-)

There are several ways to build the Ubiquitous Language, model storming and event storming workshop are one of them. But the successful ingredients of Getting-The-Ubiquitous-Language recipe are always almost the same:

  • find out the domains experts
  • put them in a room
  • ask a couple of colleague to join (another developer, a tester, …)
  • ask as much as you can about one specific part of the domain
  • put everything on sticky notes
  • it should not take more than 30mim
  • repeat until you think you’re done!

You don’t have to know about DDD in order to start Event Storming workshops.

One of the nice side effects of Event Storming session is that the more you’ll go deeper in details, the more you’ll see different part of the system naturally appear. You will get a pretty good idea of what components you’ll have to build (DDD speaking you’ll find out Bounded Context and Aggregate Root).
You will also be able to define your GivenWhenThens. As sticky notes are chained as events that must occur to get from one state to the other, it’s kinda easy to write your BDD styled tests! And that’s where having a tester in the loop is becoming interesting! Sounds like we have our 3 amigos meeting here ;-)

Hope all this gave you some ideas about things to try on your side in order to let you and your code speak business!

There are obviously other pretty good techniques to bring business and dev people close to each other but enough for now, I’ll have surely the opportunity to talk about this later in another post!