6 practical tips for distributed working in systems engineering
There is probably no need to discuss the fact that complex products can only be developed in a team, which often results in distributed work. There is also no need to discuss the fact that a "Word document on a Dropbox" is not adequate either.
Almost every modern system development tool now supports the option of working in a team. However, this alone is not enough, otherwise outdated requirements are quickly tested, to name just one example. If different tools are then used, it quickly becomes confusing.
This article presents the biggest problems with distributed working and possible solutions.
1. ensure acceptance of the process-tool combination!
When developing systems in a team, you must Processes and Tools fit together neatly, and the team must also accept them (Acceptance). These three aspects are essential. If the processes are not right, it can quickly lead to inconsistent data statuses. If the tools are not right, work becomes extremely inefficient. And, of course, people have to use both, especially if distributed working is practiced.
It is often said that the processes should be in place first, and only then should tools be configured for them. I do not readily agree with this: every sensible tool can be configured - to a certain extent. It doesn't matter whether it's requirements management, modeling, testing or any other area of systems engineering. Nevertheless, almost all tools are designed for "best practices" that can be implemented particularly well with the tool. Once the processes are roughly defined, they should be specified in the context of the selected tool. This ensures that the work is intuitive, which increases acceptance.
2. fine granular versioning
When working in a team, conflicts can arise if work is carried out simultaneously. The alternative is to lock elements that are being edited. Fine-grained versioning is particularly important in a team for several reasons: firstly, individual elements can be locked, which reduces the likelihood of a team member having to wait for a release. On the other hand, this also allows better handling of changes (see point 5).
3. keep data as close together as possible
Ideally, all data relevant to development should be in a single database ("single source of truth"). In practice, however, this is rarely feasible, and if it is, the result is rarely optimal, which in turn can lead to acceptance problems. Nevertheless, it is desirable to distribute the data across as few databases as possible.
Monolithic solutions for system development rarely deliver what they promise. It is therefore better to look for the most suitable tools and synchronize data in real time.
If a single database is not feasible, then the small amount of data should be synchronized in real time be synchronized. There are commercial integration hubs such as OpsHub or Tasktop that can also deal with synchronization conflicts. An integration hub also defines the architecture of a tool landscape.
But synchronization is not always possible either. This also applies to collaboration with external parties (customers, suppliers). Here it is important to work with clearly defined update processes (see point 5). If possible, standards should be used here, such as the ReqIF format for the loss-free exchange of requirements.
4. branching and merging for time-shifted work
The concept of "branching and merging" originates from software development. It means that data is copied, edited and then returned to the source. Of course, this can lead to conflicts and other problems. Branching and merging should therefore be avoided wherever possible (see point 3).
However, there are many situations where this makes sense: for example, in testing, where the testers can work while the requirements are being further developed. Or in a system where hardware and software teams work with sprint cycles of different lengths.
As a rule of thumb, branching and merging should be avoided. However, if it is necessary, the processes must support this accordingly.
5. clear handling of changes
Data models always look so nice on paper because they are static. But development is a dynamic process. And for teamwork to work, this also needs to be clarified. It is important not to restrict the users too much, but at the same time to steer everything in the right direction.
Care should be taken here to ensure consistency, especially in reviews, but this does not necessarily have to be demanded in day-to-day work. (For example, nothing is worse than too many mandatory fields. This does not lead to complete information, but to useless filler text).
6. communication!
Communication is of course very important. If possible, we should always work together in the context of concrete information. This is also made possible by modern tools such as Jama, Jira or platforms such as gitHub. Information in emails gets lost and is difficult to assign to a specific element, let alone a specific version.
It is not enough to provide the tools; a culture of communication must also be cultivated. Direct contact is essential here. While context-based communication makes it possible to record thought processes and decisions in context, direct contact provides the social context. Both approaches complement each other. However, distributed working implies that direct contact is not always possible, sometimes even never.
Reviews accelerate development and reduce risks if they are carried out early and frequently.
Another aspect of communication is reviews. Reviews can drastically increase quality and minimize development risks if they are carried out frequently and at an early stage. However, this is only possible if an appropriate infrastructure is available, see point 3. Ideally, the tools provide this function, for example Gerrit for code reviews or Jama for requirements reviews.
Conclusion
Of course, this list is not exhaustive and does not go into detail. But if these six points are taken into account, then the chances of teamwork working will increase dramatically.
