Requirements workshops in distributed software projects
The pandemic has changed our working landscape forever; working in hybrid teams is the rule and co-location the exception. In a survey of professionals and managers in the software industry, we asked about challenges in distributed software projects. While the development process works almost unchanged through established tools and methods, additional challenges arise in requirements engineering.
In this blog post, I explain and evaluate the fields of action for successful software projects in a distributed environment. Subsequently, I establish the reference to requirements engineering and show you how to identify an appropriate degree of distribution for the core activity of requirements elicitation in distributed software projects.
Three fields of action for successful distributed software projects
To make distributed software projects successful, you need to act in the three fields of action: processes, technology and culture.
Processes
Clearly defined processes help you to overcome the limitations of distribution. It does not matter whether individual roles are distributed, you work in distributed teams or completely distributed. Transparency about the progress of tasks helps you ensure that everyone can keep track of progress at all times. This minimises unproductive waiting and idle times and reduces throughput times. If you already work agilely, you have a clear advantage. Small-scale and clearly delineated tasks with clear responsibilities for each phase in the software process are the engine for the smooth running of your projects.
In my opinion, processes are less critical for the success of distributed software projects than the technology and culture used.
Technology
Standardised tools and a uniform infrastructure form the basis for smooth processes. The third chat programme and the fifth video conferencing system are more than a nuisance and lead to unproductivity and defocus. A digital team sphere must be created, i.e. the team must have a “room” in which they can move around and in which all information is available in one place. The team sphere must also be designed for face-to-face exchanges and social interaction that otherwise takes place in the coffee kitchen. Optimise your onboarding for new team members and emphasise training. In addition, you should continuously question whether the technologies used are the best fit for the purpose. For example, using a digital whiteboard of your collaboration infrastructure that offers only rudimentary features instead of using a specialised provider may be easier, but will lead to poorer results and low adoption.
Technology is the enabler for distribution. Your challenges lie in selecting optimal tools, standardising and training your staff. So culture remains as the main challenge for successful distributed software projects.
Culture
Recognising and understanding people’s needs is much more difficult in distributed teams. Perceiving the facial expressions, gestures and mood of team members is limited to meetings. I don’t see the body language with which the colleague comes into the office, I don’t see how the colleague sits at the desk and I don’t perceive how good morning is said. So it is much more difficult to grasp and understand the person in order to be able to respond to him or her. To collect these impressions, a lot of additional time for communication and interaction is necessary. This time must be created or available so that the social glue in the team does not become brittle and eventually break.
With the help of mutually agreed rules in the team, it is possible to create a “one-team culture” and thus to deal with the complex issues in the field of culture.
Challenges in distributed requirements engineering
Requirements engineering consists of the four core activities: elicitation, documentation, review and agreement, and management of requirements. Requirements elicitation is the process of gathering the requirements needed for the project at hand from different stakeholders to gain a common understanding about the system to be implemented. It is thus the most important core activity, as it is the foundation for all subsequent activities and the rest of the software process.
In practice, probably the most common form of requirements elicitation is the workshop. This is particularly suitable for establishing a common understanding in interdisciplinary stakeholder groups. Establishing common understanding is essential because different backgrounds, experiences and goals of the stakeholders lead to individual mental models that impair common understanding: Misunderstandings are inevitable. However, the effort required for preparing, conducting and following up on workshops is not small, so that workshops are often held for complex issues and last several hours or days. If workshops are conducted in a distributed manner, the risk of misunderstandings increases.
Establishing common understanding is even more difficult in distribution than in presence, because the attention span of stakeholders decreases and the potential for distraction increases.
How to meet the challenges of distributed requirements engineering with workshops
Some of the basics of running distributed workshops will be familiar to you and are now the standard: everyone has the camera on, you take regular breaks and activate your participants.
A big advantage of distributed workshops is that you can more easily split (multi-) day workshops into several sessions on different days. Also, you can selectively invite certain stakeholders to workshop topics instead of having them participate one day at a time.
Additionally, I have gained experience over the last few years that may be less obvious.
Focus and structured approach
To counteract a decreasing attention span, it is helpful to follow a good structure and to work on topics in a focused way. The vehicle for this is adequate preparation and consistent facilitation of the workshop.
We like to organise workshops with a Kanban board. Each topic goes on a card and is placed in the To-do column at the beginning. A work-in-progress limit of one ensures focus. The sequential processing of the topics with the help of the Kanban board creates the necessary transparency about the progress.
Depending on the size of the group, you should consider using several facilitators. One person focuses on the group and its cooperation. The other person controls the direction and the level of abstraction in the discussion through impulses and critical questions.
Choosing an appropriate level of distribution
Not all distribution is the same. In workshops it makes a difference whether individual roles are remote, you work in distributed teams or all participants are remote. You should decide which form of distribution is appropriate based on the complexity of the problem and the lived remote culture in the company. Of course, the technical possibilities also have an influence, but they should be seen as enablers and agnostic towards the forms of distribution.
The lower the complexity of an issue, the better requirements workshops can be conducted remotely. If the participants are used to collaborating remotely and have mastered the necessary tools, a complete distribution can also be suitable for solving the problem. The more complex the issue, the more you will benefit from co-location. If your remote culture is so strong and your workshop participants are very disciplined that you achieve the same results as in the presence, you can also solve complex questions remotely. In my experience, however, this only works up to a point, because controversial discussions work better with direct interaction and face-to-face communication. And a pen on a whiteboard is also more intuitive and faster than using a corresponding tool. Sometimes it is the technology that fails.
Conclusion
Remote has come to stay and fortunately will not disappear from our daily lives. The software process continues to run smoothly in other parts, but requirements engineering remains the critical phase in distributed software projects. Distribution increases the challenges and necessitates a critical examination of the context in the dimensions of processes, technology and culture in order to best support the appropriate level of distribution for solving specific issues.
Notes (partly in German):
If you would like to learn more about the topic of Successful software projects with distributed teams, you are welcome to download the free, German-language eBook for efficient, productive and customer-centric software projects in the age of hybrid collaboration.
If you like the post or want to discuss it, feel free to share it with your network.
Dr. Simon Grapenthin
Dr Simon Grapenthin is an author, keynote speaker and management consultant. He did his doctorate on the success of IT projects at a chair for software engineering at the University of Duisburg-Essen. From his doctorate, he founded Interaction Room GmbH in 2014, a service company specialising in distributed software engineering. He himself advises, coaches and accompanies specialists and managers in change processes and focuses on the professional transfer of scientific findings into practice as part of his consulting services, lectures and publications.