Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Conversation Patterns for Software Professionals. Part 2

Conversation Patterns for Software Professionals. Part 2

In the first part of Conversation Patterns for Software Professionals series you have learnt what a business need is and how to recognize it in the course of collecting User Stories. There, I have also presented User Stories templates:

  • IN ORDER TO AVOID <problem to be solved>, AS <role> I WANT <feature>.
  • IN ORDER TO ACHIEVE <expected benefit>, AS <role> I WANT <feature>.

which enable to notice the needs behind the expected functionalities.
One of the most important insights in the first part was that in the course of User Stories collection it is easier to talk about what business people want or what the expected functionalities are, but it is much more difficult to specify the goal, that is the business need behind these expectations.

When you run a User Stories session and begin to talk about functionalities, you certainly notice that your interlocutor often uses words that are "need-like". Which of the needs is THE RIGHT ONE?

Questions to look for needs

Questions are the first tool to search for appropriate business needs. If you ask a skillful questions, it will allow you to get relevant information. I am absolutely convinced that if a business person are talking to does not give you the information you are looking for, it means you have asked a wrong questions at the wrong time.

Please, read the previous sentence once again. It reveals one of the key assumptions behind the Conversation Patterns for Software Professionals. I assume that you are fully responsible for carrying out a conversation, you're a professional who will provide the software and you are the one to know what information you need. Without this assumption, it is easy to burden the business people with the responsibility for an unsuccessful conversation – and to deem them as unable to communicate effectively. Searching for causes of these problems in the business people does not lead to any meaningful solution – but understanding that it is your own deficiency does! This is why this assumption is so important.

Since there are two shades of business needs: a problem to avoid and a benefit to gain, there are also two groups of questions that will help you discover these needs.

The basic question to explore the needs in the form of problems that your interlocutor is trying to avoid, is the "Why" question. Trying to answer the question "Why?", we usually focus on problems from the past. A similar result is achieved by some more specific questions exploring the area of problems to be solved:

  • Why is it important?
  • What is hard in it?
  • What will you prevent?
  • What can you lose?
  • What are you trying to avoid?
  • What might happen if you do not get this functionality?
  • How much money can you lose?

Questions of this kind are mostly aimed at clarifying what motivates your interlocutor to want that the functionality or, in other words: what value they attribute to this functionality. Or, simply, what business value this functionality has.

The basic question to seek benefits to gain is the "What for?" question. When we answer this question, we usually focus on future benefits, just as in the case of some more specific questions of this kind:

  • What will it give you?
  • What is the purpose of...?
  • What / How much do you have to gain?
  • What will happen if we implement it?
  • What will be possible then?
  • What can be achieved?
  • What are the new opportunities associated with it?
  • What is really new in it?

You may be wondering now, how you will know where to look for needs. Is it the direction of problems to avoid, or perhaps the direction of benefits to gain? The answer is quite simple: listen to what your interlocutor says. You can start the conversation with some neutral questions:

  • What made you want this functionality?
  • What is important in this functionality?

and then carefully listen to the answers and look for expressions indicating the specific type of a business need (see: the first part of the series). After that you can start asking questions related to the direction in which the interlocutor has more to say.

Look for specific needs

- What made you want this functionality?
- Oh, the feeling that it will be cool!

Well, maybe it indeed " will be cool", but it has nothing to do with business needs. At this point, a set of precision questions will be helpful:

  • How will you know that ...?
  • How will you measure that ...?
  • How? In what way?
  • What specifically will make you...?
  • Who? Where? When? With whom? How much?
  • Give an example...

In the context of precision questions it will be very helpful to encourage the interlocutor to formulate statements according to the rules of the so-called semantical concretism. Concretism is one of areas of philosophy developed by Tadeusz Kotarbiński, according to which only those sentences that contain names referring to things existing in reality are correct. Thus, the sentence "It will be cool" is not correct in the sense of semantical concretism, yet the sentence "Person X will send us the order form" is.

Look for needs associated with this particular business

"Increase in monthly revenue", "reduction of hidden costs" are more or less specific needs, but at the same time they fit into almost any existing business. Look for needs that are associated with the business that you are creating the software for. For example, as an online bookstore user, I have the following needs:

  • Not to create a new account (a problem),
  • Not to enter all the data with every purchase (a problem),
  • To get the book a day after the purchase (a benefit),
  • Not to pay for the delivery of every single book (a problem).

Some of the items from this short list will translate into a functionality, but not all, as some of them go beyond the IT system.

Look for needs that motivate

Search for those needs that make your business interlocutor want to stand up and shout, "Yes! That's what I want!". These needs are the ones that should be written down in the User Story. To decide which need is the closest to what the business really wanted to convey, you may use the following questions:

  • What will be the consequences if you avoid it?
  • What will be the consequences if you achieve it?
  • If you were now forced to come to terms with one problem, which one would you choose?
  • If you were now able to achieve only one of the benefits, which one would you choose?
  • If you were now forced to resign from one benefit, which one would you choose?

These are the questions that, on the one hand, help us find the consequences of meeting the business needs and ,on the other hand, help us set priorities to determine the most important need.

Discovering the needs in action

Now, let’s combine all of the information about discovering the needs. We will take a conversation between business and developers as an example. Such conversations take place quite often and, generally speaking, follow the same pattern:

  • [Business]: Listen up, I would like to add a button to generate a partial report to this screen…
  • [Team]: Which data should be displayed? What to show, if there is no data? Is this requirement consistent with the overall vision of the process? Have you thought about the consequences of partial data aggregation? This may require more refactoring ...
  • [Business]: ummm, I have to ask ...

It seems that there is nothing extraordinary in questions asked by the team – they are just some decent precision questions. Buy, as usual, the situational context is the key. In cases such as the one above, the team uses a large amount of detailed and sometimes technical questions in order to say "No!".

When you talk with someone from the team, the questions from this list are perfectly OK, because your interlocutor is sufficiently competent to answer them. When you use the same questions talking to someone who is not ready to answer them, because he or she does not have proper knowledge in this field, their reactions might be seen as intentionally aggressive. Thus, if you want to say "No!", just say "No". This is definitely closer to assertiveness than torturing your interlocutor with lots of incomprehensible questions. Apart from that, it often happens that such conversations end with two parties convincing each other that a given mutual functionality makes or does not make sense.

Does it mean that in contact with business people in general you should avoid this type of questions? Of course not! At one point or another you will finally have to ask them. The important thing is to, first, discover the need and, next, ask some more specific or more technical questions.

How the dialogue that I presented here could proceed?

  • [Business]: Listen up, I would like to add a button to generate a partial report to this screen…
  • Now stop. Even if you are absolutely convinced that this requirement is unreasonable or makes no sense at all, stop. Do not argue, do not convince. Discover the need.
  • [Team]: What do you expect to gain with this partial report?
  • [Business]: I do not want to wait for the sales charts by the end of the month.
  • As you can see, the team inquired about a potential benefit to achieve, but the business pointed out a problem to avoid. Yes, it may happen and in such cases you need to follow your interlocutor.
  • [Team]: So the key is the time you wait for sales charts?
  • [Business]: Yes!

At this point, a business need has been named as a problem to avoid: "I want to avoid waiting for the sales charts by the end of the month".

Having the need, you can proceed to define its acceptance criteria. In other words, you have to determine how your interlocutor will know that the problem has been solved or that the benefit has been achieved. Why is it so important to formulate acceptance criteria? We will hit that in a moment.

  • [Team]: To stay up-to-date, which particular charts would you like to see and how often?
  • [Business]: In fact, twice a week I need charts of key clients.

If the team wanted to sum up what they have just learned from the client, it would be something like this: "I want to avoid waiting for the sales charts by the end of the month and I will avoid it if I will be able to see the sales charts of key clients twice a week." Having this knowledge, the team can continue the conversation.

  • [Team]: Oh! So we can do this... or this... or that ... Which of these solutions is in your opinion the best?
  • [Business]: That looks interesting…

The team tried to name the need and determine its acceptance criteria in order to be able to suggest alternative solutions. That is the magic behind the needs. The most common tactics for dealing with new functionalities that do not "fit" into the architecture are: providing arguments, persuading and forcing your own ideas. When you focus on needs in the first place, it allows you to find an alternative solution that, on the one hand, will satisfy the business and, on the other hand, will be acceptable for the team.

In the third article of the Conversation Patterns for Software Professionals series we will focus on how to use words consciously and how to manage the conversation flow.

About the Author

Michał Bartyzel – I have been dealing with the topic of the efficiency of the development teams for ten years so far. I am working on improving both the architecture of the applications and its refactoring, as well as on improving the cooperation between the so-called business and the development teams. So far, I have conducted more than five hundred training and consulting days with the best development teams in Poland. I have come to a conclusion that linguistic skills are the key to Software Craftsamanship. This applies to, both, the ​​cooperation with business and the developer’s job, which I show in the trainings that I design and dedicate to refactoring, working with code and architecture. Many techniques that I have developed so far are presented here. I also share some new techniques that I am currently working on during numerous conferences, on my blog and in the Programista magazine.

Rate this Article