Figure 3. Different types of PD with sub-types

4.2.1 Activity-specific debt

Processes are created for different goals and may involve different activities. It is possible that one specific activity is sub-optimal and not the whole process as a whole.
We found several kinds of activities that can be flawed: for example, a sub-optimal prioritization process could be called prioritization debt, a sub-optimal certification process could be called certification debt, and so on. There may be many activities that could generate debts. In addition, many activities are context-dependent, meaning that they appear in some companies and not in others, or they appear with different names. These all fall in the PD category.
An example of an activity-specific debt was found in company D, where the main PD related to the entire bug-fixing process was specifically located in the use of an extensive checklist to be manually filled in by the developers every time a new bug was discovered and fixed (an instance of documentation debt). Such debt could be named by the specific sub-optimal documentation activity as “bug-fixing documentation debt”.
This sort of debt is not mutually exclusive with respect to the other presented categories. The purpose of this category is to give the opportunity to better define a specific PD. For example, the Unsuitable Process identified in company E during the longitudinal case-study was about business decision-making. In this case, we would call this instance of PD an Unsuitable (Business) Decision Making Process.
In those cases where it’s not only one activity being suboptimal, for example the overall waterfall-like process for company A, one would just refer to the whole process, such as the “Unsuitable Mechatronic Development Process”.

4.2.2 Mismatching roles and responsibilities (Roles debt)

Activities are carried out by executors, which usually have different roles according to the responsibilities mapped in the process. Roles are not physical people but are “hats” that are dressed by anyone in the organization to carry out a specific activity. Further, often roles within the process are also associated directly with a role that is represented in the overall company organization. This can create a mismatch between the responsibilities described in the process and the responsibilities in the organizational structure, which might prevent employees from accepting and carrying out some tasks for which they are responsible in the process. For example, in Company E, they created a role that they called “product owner” and assigned people to that role without saying what the role entailed. Many of the people assigned to that role were confused as some were familiar with the product owner role in Scrum. However, the responsibilities of the product owner in Company E was more related to being a team leader. Another issue is when responsibilities are not well mapped. An example from the agile program in Company E showed how developers were not changing the status of their tasks themselves and did not assign them to the next designated role, so the PO had to do it for them, causing extra effort for the PO. The cause mentioned here was that the process was not well communicated in advance to the actors.

4.2.3 (Process) Documentation debt

The process is usually described by documentation. Although, in some cases, for example, when only a few stakeholders are involved, the process can be kept informal, meanwhile, in large projects where more teams and stakeholders are involved, the process needs to be well documented. The lack of process documentation (or its inaccessibility) was recognized as one of the major sources of PD both by process designers and by process executors from across all studied cases, including the longitudinal case study.
Providing a suitable level of granularity for the process design is challenging. For example, the documentation might lack information about steps or stakeholders, which leads to unclarity and confusion, or, on the contrary, it might be too detailed. The latter case might seem somewhat counterintuitive: the interviewees mentioned that having too many details could actually create as much overhead as having too few. For example, too many details might give wrong instructions on special cases that should be handled by the process executors (especially in the presence of frequent special cases). Another negative effect of such over-detailed documentation is that executors might skip part of it because they find irrelevant information for their specific needs. If the information is not well structured, an experienced practitioner might already be familiar with most of the steps, and might find it difficult to locate the only important piece of information that is needed (e.g., an update to the process).
Besides the presence of information or the lack of it, it is also important that the documentation provides clear information. If the language and the graphical representation are not the ones that are used by the consumer of the documentation, this can have an impact on how the process is executed. To make a concrete example, company B explained that a process related to the versioning of the code was designed for hardware stakeholders by stakeholders in the software domain. Some language was not clear, as some terms could actually have different meanings in software and hardware domains.

4.2.4 Synchronization debt

The stakeholders involved in a process are also likely to participate in multiple processes that are intertwined. For example, there might be a process such as SCRUM to support agility, there might be a separate process that prescribes code reviews to ensure software quality and there might be a third process to certify the delivered software according to some standard. The complexity can vary and might depend on the scale and domain of the organization. Such processes need to be synchronized via synchronization points. Suboptimal design of synchronization points may lead to steps being skipped, confusion, overhead and disrupted workflow.
An example that was mentioned by Company A was the presence of an overall certification process that coexisted together with Agile software development. The lack of a good synchronization across the two processes created frustration and inefficiencies with respect to both processes: teams might not be able to be agile, while the process occurred to have excluded some important certification documentation.
Another issue revealed by Company E, was that the offsite teams followed Scrum, while the onsite teams used Kanban. The different methods chosen affected how pull-requests were handled between the teams. In the Scrum teams, they sent pull requests to the teams onsite after the sprint. Meaning every second week a large number of pull requests were sent for review. It was seen as beneficial to use Scrum as it would shield the developers from having to review pull requests daily but instead do it more intensely over one week.
However, it was described as overwhelming for the onsite developers receiving the pull-requests, as illustrated by a developer: “When I get QA from the teams following Scrum, then it is maybe 64 [pull requests], so then it’s like “wow!” where should I begin? That is cumbersome, and not very motivating. Reviewing pull requests is never particularly fun regardless of who sent it, and now it has been quite a lot, then it gets really boring.” Further, it was commented that the off-site pull requests were more extensive (because they had been coding for two weeks) than the on-site pull-requests, which made the work even more demotivating as extensive pull request take more time and energy to approve, as it becomes more complicated.
In summary, the two processes were not well synchronized, creating PD. As a consequence, one of the teams was highly demotivated.
In general, stakeholders, besides being executors for a number of processes, also have a workflow (see section II.B). An example is a software developer that needs to perform a bug fix (a task that needs different steps) while at the same time the code needs to be reviewed, certified, tested etc. Different activities in the workflow of a development task might belong to different and parallel processes. One key finding from our interviews with the executors of the processes is that developers need to accommodate different external processes into their workflow. The interconnection of such processes might create a sub-optimal workflow for the developers, where some activities are in conflict with each other. This is clear from company E, as explained above, and another example is given by company D: a developer mentioned that he had to get information from another unit, which was following a different process for defect handling. The received information had to be converted into a user story according to SCRUM. When the code was delivered for such a story, additional documentation was needed by yet another organization, which had the purpose of generating analytics. In addition, the developers’ workflow contained other steps related to yet different processes, making their bug-fixing workflow continuously interrupted, making it tedious, error-prone and inefficient.
In conclusion, the main findings related to Synchronization Debt (PD) are that the lack of synchronization between processes has an impact on developers’ productivity and that the lack of synchronization between processes and individual stakeholders’ (especially developers’) workflow can disrupt their workflow.

4.2.5 Process unsuitability

Some processes might not be suitable to support the business needs of an organization. Company A had in place a formal overall waterfall-like process for the development of their mechatronic product, while the software development teams were agile. The waterfall process was inherited from other disciplines, such as mechanical and electrical engineering. However, such a process was not suitable for software teams, which needed to develop software iteratively. In practice, informally, the software teams were working agile but they also needed to provide documentation to comply with the overall waterfall-like process. This caused confusion and inefficiencies, for example, when stakeholders needed information on a specific step of the process, but the documentation was not reflecting the activities that were carried out, which generated false information.
One more example is given by the longitudinal case-study: in company E, the business development unit followed a decision-making process that was not suitable for software development. Such a process was based on complex decision-making that involved continuous synchronizations and updates. This made the specifications change continuously. On the other hand, the software development team relied on Scrum, an iterative method in which the team began with a planning meeting and subsequently met daily for two to three weeks, presenting what they delivered at a demo meeting after that time. When software development started solving tasks that were put into a sprint (iteration), they soon discovered that the tasks were different (e.g., in terms of complexity, size, or the number of dependencies on other sub-systems) than what was originally planned for by the business development side.