Conversation Patterns for Software Professionals. Part 3

In the first two parts of the series Conversation Patterns for Software Professionals we focused on discovering business needs. You have learnt that behind each expected functionality there is a hidden need in the form of a problem to avoid or a benefit to gain. We also presented the methods to discover and specify these needs during sessions oriented at collecting User Stories. Next, we illustrated the pattern of exploring the needs based on the example of a team proposing alternative solutions.

Have you ever seen a file with application server diagnostic information (in short: logs)? Figure 1 presents such a file.

(Click on the image to enlarge it)

Figure 1. (Il)legible application server logs.

For many people it is simply a large amount of text that means nothing. However, people who often work with this kind of files will find lots of useful information there. They know how to look at seemingly incomprehensible data to pick out what is most important for them (e.g. entries [ERROR], [FATAL] or specific queries to the database). The same applies to conversations about new features, changes in existing functionalities, or changes in the rules of operation of the business that we develop software for. In the course of such conversations people talk a lot – and “smuggle” pieces of information. They are more or less accurate. To pick out what is essential to deliver the software, you need to be able to listen and look at the conversation in an appropriate manner.

Conversation has a structure

Since the source code can be structured (in the form of design patterns), which makes it easier to develop and maintain, why not apply the same analogy to a conversation? When we look at the conversation in a structured and orderly manner, it may help us lead it more effectively. What we mean here is not related to patterns of conducting meetings, during which every participant has their specific role. We are talking about something more fundamental – about how people exchange information (especially people form business with those from IT) in the course of a conversation. We assume that your interlocutor does not need to have any knowledge about the techniques of gathering information or conducting meetings. We only assume that he/she has the will to say what he/she knows.

Let’s assume that you are developing software for the healthcare industry, and you are interviewing one of the key users (a medical doctor) on the functionality of writing prescriptions in the new software. The conversation goes as follows:

• [You]: How are you going to use this tool?
• [User]: Well, the most important thing for me is to enter the appropriate dosage of the medication as quickly as I would do it on a paper prescription. Have you ever seen a paper prescription?
• [You]: Of course.
• [User]: You know, paper prescription is very flexible. I can write whatever I want. This new functionality should be equally flexible. By the way, our employees have a few problems with the new system...
• [You]: OK, so you want to write a prescription using ordinary text. What else?
• [User]: The prescription must be linked to the drug cabinet. The cabinet is a fairly complex issue. The key is to meet the requirements of the Legal Act XYZ. In the case of prescriptions we are also obliged to comply with several regulations...

Now imagine that the conversation is similar in its structure to the one in Figure 2:

Figure 2. The structure of the conversation.

All the pieces of information you can get are governed by a need, that is, the reason why a person from the business reports this functionality as one that has to be available. Next, imagine that you can organize those pieces of information that are crucial to you on a tree structure: at the top there is general information, at the bottom there is concrete information.

Let's arrange this sample conversation in the form of a tree structure, and let’s do it in the same order in which different pieces of information appear (Figure 3).

The first information relates to "dosage", another to "paper prescription." Both were given in the context of talking about "prescription". Next, the key user talked about the "flexibility" of a paper prescription and about "some problems" with the "new system". Then, the key user mentioned a "cabinet of drugs" and "XYZ Law" which regulates its use. At the end, he also mentioned that the prescriptions are bound by "several regulations."

Figure 3. Order of information

The course of the conversation

The thing you'll notice once you visualize the conversation is its course (Figure 4). This conversation was chaotic! We use the word "chaotic" not in the sense of a judgment, but to label the specific properties of this particular conversation and to distinguish it from a structured conversation. In the sample conversation the speakers spontaneously moved from concrete to general remarks and changed the topic. This is the way in which people talk with each other and that’s somewhat natural.

Figure 4. The course of the conversation.

Looking at it from the perspective of a goal, i.e. determining what the business is ready to pay for, this quasi-natural way of speaking with people is not always effective. If you run a conversation in a chaotic manner, it may be that:

• You collect a lot of information, but little knowledge,
• You only slightly understand what is happening in the business,
• You have chaotic notes,
• You think that you should do something, but you are not sure what exactly needs to be done.

Steering the course of the conversation

We can distinguish three basic directions of navigating through the conversation structure (Figure 5):

• "up", summarizing – the aim is to find the need hidden behind the interlocutor’s expectations;
• "down", concretizing – the aim is to formulate acceptance criteria for the expectations of the interlocutor;
• "to the side", building analogy – the aim is to identify a particularly difficult subject in a different context and to move the conclusions back to the original context.

Figure 5. Directions of navigating through the conversation structure.

Methods for steering the conversation "up" were presented in the previous parts of the series. Now we will focus on concretizing, i.e. going down in the structure of the conversation. The first thing that we have to explain is the aim of concretizing. Well, concretizing is about... getting concrete information. In software development, concrete information relates to: acceptance criteria, acceptance testing, functional testing, use case scenarios, User Stories scenarios, interface sketches, examples of output data.

The boundary between general information and concrete information is quite conventional. It frequently happens that we perceive concrete things as those that can be measured, i.e. something that can be reduced to a number. From this perspective, the criterion of "an intuitive user interface" is not concrete, while the information that "the screen contains no more than five control units" is. Another criterion of concreteness is the number of designates. Most of the concepts that appear in the course of the conversation have their designates, that is, objects existing in reality, which are referred to by a specific name. The less designates there are, the greater the concreteness of a given concept. Thus, a phrase like "the main problem is the weak test" is not concrete, while a phrase like "our main concern is that we achieve a hundred percent code coverage testing getters and setters" is much more concrete.

Of course, you can concretize any information down the level of a pixel or even an atom, but at some point it will become art for art's sake. For this reason, the importance of concretizing lies the context of the conversation – the context that is assumed a priori by those who take part in it. For some people the idea of "the standard login screen" is quite clear, because they have specific contextual knowledge that allows them to correctly understand such a formulation.

One of your most important tasks is to verify whether the context that you assume for the duration of the conversation is in line with the reality – or not. For example, an obvious and a rarely challenged assumption is that the person I talk to knows what the conversation will be about and he/she is prepared for it. It often turns out to be a false assumption. A good idea is to start accepting as few assumptions as possible, and then to gradually increase them in order to facilitate the conversation.

Having outlined the difference between the general and the concrete, it is time to think about the details. We tend to perceive collecting requirements as collecting detailed information. Detailed information is not the same as concrete information. "Concrete" means "well-defined, accurate, precise" and "detailed" means "containing many details." Concrete information will often be detailed, but detailed information does not have to be concrete.

A nice example of it is the documentation generated by reverse engineering tools based on the source code. (Large) documentation generated this way contains a large number of details – so it is detailed. At the same time, it is rarely concrete. The aim of the interviews with people from the business is to gather concrete information, not detailed. Of course, you will get a lot of details – most often as a side effect of the search for concrete information – but you should focus primarily on the concrete ones. Remember about it.

How to ask about concrete information?

As in the case of searching needs, the key is asking the right questions in the right way. Questions that concretize the concepts and lead your interlocutor down the structure of the conversation are:

• How? How exactly? What exactly?
• What does it consist of...?
• How do you measure it?
• How much? When? Where? With whom?
• How do you know that ...?
• Give an example of ...
• In what order ...?

By asking these questions, you will encourage your interlocutor to break the general information down to more concrete information. By doing this, you can go down the structure of the conversation in two ways (Figure 6): into its breadth and into its depth.

Figure 6. Going down the conversation structure

Going into the depth equals to focusing on a single topic and exploring it thoroughly. The most common effect of this approach is that you will learn a lot about one topic, and little or nothing about the rest of potentially important issues. People conducting conversation this way often say that they "floated" into a given topic.

Going into the breadth of the structure of the conversation usually gives better results, because this way you get familiarized with the entire issue – and not only in a small part of it. Of course, due to time constraints you will have to intertwine concretizing questions with questions about priorities like "Which of the topics are we going to cover now?".

Let's see how you can conduct a sample conversation with a user about writing in a new software if you use concretizing questions and navigate into the breadth of the conversation’s structure. (Table 1).

To practice, try to draw the structure and the course of the conversation in Table 1.

You may be wondering now how to ask a question to motivate the interlocutor to give exactly this kind of information that you expect, or how to skillfully interrupt your interlocutor if he/she detracts from the topic, or how to make sure that you properly understand a given business concept. In the next episode of the Conversation Patterns for Software Professionals series we will focus on different types of questions that hit the nail on the head.

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.