“The decision-making process is a mess. For example, it is unclear to the developers who have the final decision on design and the development. Is it the product owner, the manager, is it the team in consensus or is it someone from the business? The consequence is an ineffective process where the developers believe decisions are made, and suddenly they are stopped in their development because it was not decided that that was the way to do it after all.”
As a consequence, software development did not deliver what the business side had expected at the end of a sprint, causing business development to begin to lose trust in software development. Further, because the business developers were often not aligned or not available, software development seldom got fast feedback when they discovered that a feature or design needed to be changed, causing software development, in turn, to lose trust in the business side. The result of all these challenges was that the process from identifying a feature to delivering the feature took much longer than necessary.
The difference with synchronization debt is that, in the former case, the processes might be optimal but not well synchronized, while, for this category, there is one process that is just not suitable for the needs of (a part of) the stakeholders.
Main findings on Process Unsuitability:
PD consists of the existence of a process, from which software development is dependent on, which creates overhead, confusion and delays.

4.2.6 Infrastructure Debt

Infrastructure debts (IDs) have been considered to be PDs by the interviewees. Here we explain in more detail what specific issues can be considered ID.
Tools in the toolchain may work seamlessly with each other, or they may not. When tools that are part of the same process or are part of different processes but are interacting within the same workflow for the stakeholders, and they are not well integrated, they might create overhead, errors or excessive task switching for their users, which qualifies as PD.
Additionally, tools might be outdated and might become unfit to support modern processes. An example from company B is related to a software versioning tool that was purchased several years back and has always worked well. However, when the company moved to continuous integration and continuous delivery, the tool did not support fast operation with the distributed codebase. Consequently, the process was slow, and developers would not deliver often to avoid additional overhead. The company decided to remove this PD and to purchase a new tool.
In addition, there might not exist tools that fit well with the processes, or the right tools might require high costs. This might lead to tools that are not used for the purpose required by the process and might therefore be sub-optimal.
Finally, from the longitudinal study, Company E mentioned that people were forced to sit at specific desks two times a week as they belonged to two teams, which made people extremely frustrated because they wanted to sit at the same desk the whole week. Either they preferred to sit close to the people they were usually seated next to, or they relied on external monitors. In this case, it is clear that not only is it the virtual environment and tools used to develop software that constitutes PD, but infrastructure debt can also include the physical environment surrounding the practitioners.

4.3 Process Debt occurrence and its accumulation patterns (RQ2.1)

Three overall PD accumulation patterns were identified: Sub-optimal process design, Process divergence, and Tool deficiencies, as outlined below. PD is primarily initiated by two main actors, process designers and process executors, but we found that the infrastructure may also trigger the accumulation of PD. We call these three PD Initiators.
4.3.1 Sub-optimal process design
This category includes those processes where a decision was made that caused the process to be sub-optimal in some aspects and with respect to a number of stakeholders.
Although we call it “process design” our analysis distinguishes two cases: those where the process has formally been designed, and those where the process has emerged over time without a clear upfront design. Although the strategies to manage these two cases might differ, from a conceptual point of view, there is no difference if the process was designed upfront or the design just emerged. In both cases, the process design would be flawed.
In the interviews, several instances of this kind of PD were identified. One example from company D was the need for a large number of fields in a report to be filled in by the developers every time a new release was delivered. This was decided by another organization, which used such information to compute analytics and statistics. When we investigated with the process designers and the developers, it was not clear why these fields were so important. They were decided a long time ago when releases were infrequent, and the developers did not have to fill in such parameters so often, and therefore it was not seen as a problem. However, as new processes (e.g., continuous delivery) were introduced to the software team, filling such parameters became a significant negative impact on the team. The emerging new processes had created an instance of PD by conflicting with the existing ones, and this was generating a substantial overhead.
Another example of sub-optimal process design was in Company E, where they decided that the Norwegian teams used Kanban while the outsourcing teams followed Scrum. The reason was that both sites could use the process they were familiar with and that they believed it was the most productive process. However, since they followed different processes, collaboration across sites became troublesome as activities were not synchronized and misunderstandings emerged. Also, several coordination meetings caused much overhead and waste.
4.3.2 Process divergence
This category refers to those processes that are initially effectively well-designed by the process designers but are not followed by process executors. Again, by well-designed here, we do not mean processes that do not have any sub-optimality, but for which a better tradeoff is not identified.
An example from company C was the formal process used in the company concerning the execution of unit tests. The process was designed upfront by the process owners, which were responsible for many of the processes in use at the company. The unit-test process included a step for which a certain coverage should have been achieved (a % of modules should have been tested) before delivery. However, in practice, most of the projects did not reach the recommended thresholds. According to the interviewees, this had an impact on the quality and reliability of the released software. In this case, although the unit-test process was well-defined, it was ignored by the development teams, causing an interest (in terms of quality and reliability) to be paid.
4.3.3 Infrastructure deficiencies
This category of PD contains those issues that are related to inefficiencies in the infrastructure supporting the processes. There are two sub-categories: tools that are used to carry out processes (e.g., project management, bug tracking tools) and tools that are used to design the processes (e.g., to create guiding documents). PD exists if a (better) alternative infrastructure solution is known but is not in place.
As identified in section 4.2.6, infrastructure debt is part of PD. The infrastructure is there to support the process and does not have another independent function. This is why, usually, in organizations we find PMT (Processes, Methods, and Tools) units that need to coordinate processes and tools together. Given how intertwined the two categories are, it would not make much sense to separate infrastructure debt from PD. In practice, any infrastructure debt will also create a problem for the process. We refer to infrastructure deficiencies as infrastructure debt (ID, as part of PD) to denote that the tools are a source of the debt.
To mention an example from company D, a software process related to bug fixing originated from the fault handling being initiated by a unit developing hardware. The issues, created in a tool used by the hardware team, then needed to be processed also at a software level, and the software development team received a report from the hardware organization. The developers then needed to convert and duplicate the entry and add it to a software management tool (Jira). The lack of integration across the two tools created an unnecessary overhead for the developers every time they received a bug to fix. In particular, the interviewees mentioned that a solution would be possible to integrate the two tools. However, such development had been down prioritized by the management as it was not deemed important enough to implement.
Processes regarding the use of Jira also caused infrastructure debt occurrence in Company E. Since the offshore teams were measured by the number of solved Jira issues, it caused the developers to attach multiple Jira issues to one pull request to improve the performance measurements. The result was that the Norwegian developers had to review very large pull requests, which was frustrating for them as large pull requests became very complicated and took a long time to resolve. Reviewing small pull requests were perceived as much more efficient.

4.4 Causes of Process Debt (RQ2.2)

Our results show how a large number of causes can be responsible for the introduction and the presence of PD. The causes are also illustrated in Figure 4.