Statistics for remote requirements collection

Question

When developing software one of the main steps is the collection of requirements, the acquisition of knowledge of the domain and the construction of a ubiquitous language. Both agile methodologies and Domain-Driven Design put a lot of focus on this, because it is really important the participation of business experts in development.

It turns out that there are situations where it is not possible to be personally with the business experts to make meetings and discuss the software. I have received proposals for development from customers from other states, due to recommendations from local customers, but I was worried about this issue of contact with business experts.

Of course, with the technology that we have today it should be possible to make an efficient way to make this contact at a distance, but what I want to know are the techniques that really work. It seems to me that just emailing with a quiz might not be enough.

In this case, how can we remotely do this part of requirements collection, domain knowledge acquisition, and ubiquitous language construction? What Means To Do This Really Work?

Answer 1

TL;DR

Use the same methods you would normally use, but put more effort into keeping communication effective.

Challenges of distance communication

All material and all people I’ve worked with, even when favorable, recognize that there are challenges in remote work.

difficulties in the field of language, delays due to very different time zones, important issues that are avoided because you need to write a lot, video conference meetings that are prolonged because of the delay in communication, concepts that are not well explained because you can’t just pick up a paper and draw. These are a few items that are big problems for remote teams.

In short, all the people I know report that video conferencing is not the same thing as talking to someone in person.

Redoubled effort

To circumvent the difficulties that distance brings, it is necessary to have a greater effort.

The distance should cause a overhead communication and this should reflect on your deadline and budget.

The greatest effort can be invested in:

• More discussions on video-conference or telephone; usually the opposite is done, less time is spent than would be done in person, but considering that remote communication is less effective, it is necessary to spend more time communicating.
• Pass on each information discussed in writing and send to the client after meetings for confirmation of understanding.
• Invest in a good management system of your backlog and engage stakeholders to follow and add comments.
• Perform a greater number of software demonstrations and collect feeedback more frequently than in a normal project and thus mitigate communication failures as soon as possible.

Two important remarks about all of the above:

1. Meet the user

The additional effort will be inversely proportional to the user’s knowledge of IT and their own needs.

Before you start raising the customer’s needs, talk to him to see how much the people involved are aware of what they are needing and if you have any experience in participating in systems development in order to determine the work you will have to extract the information.

Always take care of the vocabulary used, because depending on the level of the user this will determine whether the communication will be more at the technical level or in terms of business.

It is not uncommon for users to be embarrassed to ask about some term they do not know and thus giving misleading answers about what they need.

When working remotely:

• Hold meetings with all users to level out knowledge.
• Hold individual meetings with each interested party and give them the opportunity to ask questions "secretly", without embarrassing themselves before colleagues.
• When talking about a technical subject, always summarize for the user what that is, never assume that he already knows. For example: "The JVM, that program you install to run Java applications, blah blah blah".

2. Cut the chatter

I’ve talked so far about spending more time on communication and meetings. This is something that seems contradictory and counterproductive, after all who likes to spend more time in meetings?

However, everyone must bear in mind that this is the price for using a less effective means of communication. But of course that also means being aware that everyone’s time is valuable and meetings should be extended as long as useful information is obtained, never more than that.

It’s like downloading with less bandwidth: it will take longer to transmit all the necessary data and should avoid navigating on things you don’t need in the meantime.

A tip would be to have few meetings scheduled regularly and several informal and on-demand meetings or "calls". Scheduled meetings are good at first, but soon lose meaning because people don’t have much to add and become repetitions, so in this case it’s best to have users closer to irregular conversations when doubts arise.

Considerations

Finally, all the tips above are experiences that serve for all cases, but which should be more strongly reinforced in a project whose communication is the greatest risk.

In fact, thinking in this sense, it is worth remembering that within a project where the risk identified, it is always good to review the mitigation techniques related to this type of risk.