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!