BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Conversation Patterns for Software Professionals - Part 4

Conversation Patterns for Software Professionals - Part 4

The first three parts of the Conversation Patterns for Software Professionals series (1, 2, 3) were devoted to exploring business needs. There, we presented techniques which are helpful in defining and clarifying the real business needs that are hidden behind the expected functionalities and user stories.

The current part is about asking questions that hit the nail on the head.

Look at the following three fragments of conversations between the Product Owner and the Team:

• Conversation 1

Team: Are we changing anything in the next sprint?

Product Owner: I don’t think so...
....

• Conversation 2

Team: What would you like to change in the next sprint?

Product Owner: Hmm... I have not yet thought about it.
....

• Conversation 3

Team: Which stories from the backlog are still linked to the objective of the next sprint?

Product Owner: Have we talked about the objective...?
....

Each of the parts of the conversations listed is actually the same thing – the information on what the team will be working in the near future. However, depending on the response to a question from the Team, the conversation probably will roll out in various directions:

  • In conversation 1 the dialogue will be immediately terminated, no sprint scope analysis will take place; perhaps the topic will come back once the user stories are broken down into tasks or during work or the demonstration of the product.
  • In conversation 2 an additional backlog grooming is highly probable; it is possible that user stories or scenarios will be added to the scope of the next sprint.
  • In conversation 3 it is possible that the whole Team will be informed on the objective of the next sprint and will participate in backlog grooming featuring the objective.

The immediate cause of each of the following three directions of the conversations of the Team with the Product Owner was a question asked by the Team. When we listen to stories about cooperation during the project lifetime, we often find statements similar to: the PO did not say that..., the team does not inform on..., has vaguely described the requirements, does not know what he wants, and the like. In general, our interlocutors claim that they have received inadequate information on planned tasks. This universal habit of making our interlocutors responsible for inaccurate conversations has turned into our measure – the quality of the information obtained indicates the quality of the questions asked.

Isn’t it a great tool to improve cooperation? From now on, instead of saying: PO did not say that... you should say: I did not ask the PO about..., instead of saying the team did not inform on..., you should say with conviction: I never asked the tam about..., instead of saying vaguely described requirements, say simply: I asked not enough questions about... and instead ensuring that he does not know what he wants, you should consent to the fact that you simply cannot get information about needs and requirements. Only once you are armed with effective questions, can you work on improving them and, thus, improving the cooperation during the project.

Hitting the nail on the head

When we look at communication between people, we come to a conviction that every man has a “module” that can be called “The buffer of useless answers”. A buffer is a place, from which your interlocutor derives answers when you ask him an imprecise or messy questions. A buffer is a buffer – it can include anything:

  • last used responses: OK, OK,
  • fragments of conversations: good, let's use EJB,
  • unrelated memories: Do it like it was done in the old system,
  • standard endings of the conversations: I will consider it, we'll talk about it next time, ask John.

If during the conversation you want to get useful information from the interlocutor, your most important job is to ask questions that bypass the buffer of useless answers.

Choose the directions in a conscious way

Suppose you want to learn a little more about the operation of a travel agency. What kind of questions will you ask? How do you work in a travel agency? How does a travel agency operate? What happens at a travel agency? Or maybe some other questions? Each of these questions will be followed by a slightly different answer. Let's see why.

  • How do you work in a travel agency? – it is likely that the interlocutor will refer the word “work” to himself and will talk about his work in a travel agency; he will probably talk about his daily activities that will come to his mind during the conversations.
  • How does a travel agency operate? – this question will force the interlocutor to look at a travel agency as a whole; as a result he will talk about the principles underlying the operation of his office, the cooperation with external suppliers, etc.
  • What happens at a travel agency? – this question highlights everyday interactions, therefore you will learn a lot about individual tasks and problems, and probably only a little about individual employees.

Which of the questions is the most appropriate? It depends on what you want to find out. If you are interested in the business process behind a travel agency:

  • Do not ask What does it look like...? – because “the looks” are not important to you.
  • Do not ask How does it work...? – because it does not suggest the interlocutor to focus on the process.
  • Do not ask What happens...? – because this question gives the interlocutor the opportunity to talk about anything.
  • Do not ask about the business process – because this is a term coined by analysts; it might sound smart, but for the majority of customers it does not mean anything.
  • Ask: What activities are conducted at a travel agency one after the other? – because this question dictates the nature of the process.
  • Ask: What happens with the customer from the moment he comes to the office to the moment he receives a plane ticket? – because this question refers to a very specific process, with clearly marked beginning and end.

Many ambiguities in the requirements gathered result from improper questions asked during the conversation. The questions are too general, they do not relate to the merits or they inadvertently induce the speaker to talk about something different than the truly important matters.

Is or should be?

In the course of conducting interviews with clients, I have noticed that when I ask about the business process in which they take part, almost everyone tells how it should function, instead of telling how it functions now. For this reason, from time to time I ask the following questions: Is it actually working the way you describe it? How does it function in your daily practice? Usually, after such a question the interlocutor begins to talk about problems.

Remember about the distinction between how it is and how it should be. Since the software that you create is to support business processes, these processes should be real. It may also turn out that the business processes are not optimal and must be modified, but you can notice it only when you find out how they really work.

Can, could, should or must be done?

Pay attention to the words may, could, should, must used by the client. Each of these words reflects a different shade of priority. Thus, must has the highest priority, then there is should, then could, and finally may. But here comes a little nuance. For politeness reasons (at least in Polish), you often say should in the sense (and instead) of must. This is why you have to make sure how critical the requirements are and which of them should be done. You can do it by asking questions such as: So it must be done? Does the system make sense without this functionality?

Past, future and present tense

By asking questions relating to a particular moment in time, you can control, both, the attention and the activity of your interlocutor:

  • In the past tense – the interlocutor recalls his daily activities. The past tense is a good way to obtain information about the real picture of the situation. By asking questions such as: How did it work? Did this approach bring results? What were your impressions after using...? you concentrate the attention of your interlocutor on past experiences in which he actually took part. This way you will learn the truth about the current state of affairs, instead of learning how things should be.
  • In the present tense – the interlocutor imagines that he is taking part in an event. You should use the present tense to discuss use cases, scenarios, and user screens. Ask questions like: What does this screen look like? What appears when you click the OK button? Use the present tense even in phrases where it is not completely natural or grammatically correct, e.g. : When you click the Options menu, what window do you see now? Asking what window you see now, you put your interlocutor in the system user perspective – he imagines himself in the course of action, he sees it and he sees it now. This perspective allows him to precisely define his own expectations. The situation would be different if the second part of the question was: what window will you see? This is a question relating to the future and it puts the interlocutor in the perspective of an observer of several alternative scenarios. In such a context, he would probably focus on how something could look, and consider several options to choose from.
  • In the future tense – focus the benefits and goals. Ask questions: What will you gain? What will you achieve?

In the past tense

In the present tense

In the future tense

· When you want to identify the problems of your interlocutor.

· When you want to gather information on the real situation of the interlocutor.

· When you define use cases and scenarios.

· When you design user screens with the interlocutor.

· When you want to learn how the application should function.

 

· When you want to identify the business goals of the client.

· When you want to identify the benefits to be ensured by the software.

Table 1. What tense should you use to form questions

You can combine tenses in one utterance to direct the attention of your interlocutor and to allow yourself to thoroughly understand the requirements, e.g .: So far you would choose employees from a multi-level menu and it was a nuisance. Now you click on the icon and immediately see the form for adding an employee. Will it really improve your work?

Ask, don’t suggest

Table 2 presents an excerpt from a conversation about the requirements of a system supporting the operation of a travel agency. This conversation illustrates several mistakes that I’ve described.

Developer

Client

Comment

-

I would like to have a system to support the operation of a travel agency.

 

Is it supposed to be a system serving one agency or several agencies that cooperate with each other?

-

The developer suggested a solution, which he initially thought of. This question should be asked much later, i.e. when the analyst already understands what the customer's business is about. At this point, it really broadens the scope of the system, and lengthens the analytical work, but it does not guarantee that customer will actually accept the price and the solution.

At this stage it would be more appropriate to ask: Do you run one or more travel agencies? This question does not suggest any answers, but at the same time it gives an important clue about the later stages of collecting requirements.

-

Well, all in all I plan to grow, so it would be good if the system handled several agencies.

The client has become interested in the suggested solution.

What does the work of a travel agency look like? What is important?

-

This question is not very specific. It is better to ask: What customer service activities are performed one after the other?

-

The customer can come to the office, or buy a trip through the Internet. All trips must be taken from the systems of large tour operators, because we are only a mediator in this process. We do not organize trips on our own.

The client signaled two processes of running the service: in the office and through the Internet. These processes should be explored as soon as possible.

So we're talking about modules: the module of a normal web service and the module of integration with large tour operators?

-

The developer has transformed the processes into “modules”. This way they lost their dynamic nature and it will be more difficult to determine the sequence of actions performed consecutively by the travel agency.

-

Yes, but I would also like to be able to quickly find the offers of different travel agencies. They could be displayed as a list or a tree structure.

The client makes a big jump to details. At this point, the appearance of the screen is not the most important thing that needs to be addressed. However, the client has signaled an important quality criterion: the ability to quickly and easily find trips from all large travel agencies.

Table 2. Suggesting distorts the process of collecting information.

If you want to know the real needs of your interlocutor, you have to concentrate on asking questions without suggesting the answers.

Closed-ended and open-ended questions

Let’s start from two definitions.

Closed-ended questions are those that have only preconceived answers:

  • Would you like to talk about the new module now? – two possible answers: yes or no.
  • Do you prefer to have this meeting now or tomorrow at four o'clock? – two possible answers: now or tomorrow at four.
  • Which technology is in your opinion more suitable for this project:.NET, JEE or PHP? – three possible answers: .NET or Java or PHP.

Open-ended questions are those that have less constrained answers:

  • How in your opinion should we approach the technological side of this project?
  • What do you think about your work with this system?
  • How would you improve your software development process?

If the distinguishing feature between closed-ended and open-ended questions is the possibility of giving an unconstrained answer (or not), these two types of questions stand on two extreme poles.

Somewhere in between there are questions which we could call “narrowed questions”, i.e. questions that allow a more or less unconstrained answer, but which also impose a strictly defined, narrow scope of response, e.g .:

  • What problems does the authorization module have?
  • What should be improved in the process of customer service?
  • What has to happen in order to serve the customer starting from the moment he enters the bank and finishing with the moment he leaves with the bank transfer receipt in his hand?

Note that the main distinction between these three types of questions is the space that you leave out to your interlocutor to take the answers from. The closed-ended questions have the smallest space, the open-ended questions have the largest.

Closed-ended, narrowed and open-ended questions are additional tools that you can use to lead the session of collecting requirements and to move around the structure of the conversation in a way that you deem most appropriate. In Table 3 you will some tips on how to use these questions.

Type

Use when

Example

Closed-ended

You want to summarize and eventually concretize expectations.
• You want to choose between several alternatives.
• You define the conditions for the acceptance of a solution.

I understand that on this screen the user must have the possibility of doing X, Y, Z. Am I right?
• Which technology to use: JEE, or PHP?
• If X, Y, Z, are performed, will you consider the task done?

Narrowed

You want to go down (to the smaller pieces of information) in the structure of the conversation.
• You want the customer’s answer to have a clearly defined structure.

• What are the most important things in module X?
• What has to happen in order to serve the customer, starting from the moment he enters the bank, and finishing with the moment he leaves with a bank transfer receipt in his hand?

Open-ended

You start the conversation.
• You want to extract large pieces of information.
• You want to hear the customer’s feedback on a particular topic.
• You want your customer to "speak out".
• You want to make the atmosphere less tense.

How can I help?
• What do you expect from this project?
• What prompted you to change the system?
• What interesting has happened since the last meeting?

Table 3. When should you use closed-ended, narrowed and open-ended questions?
 

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

Adoption
Style

BT