Figure 4. A map of the causes and consequences of PD. Dark grey boxes have sub-categories. “Different culture” is related to both teams and external stakeholders and therefore the inclusion brackets overlap.
  1. Competences: An obvious issue leading to PD is the lack of competences to design, manage and execute Processes . Processes can emerge and not be designed upfront, but in any case it is important that processes are assessed, supported by infrastructure and maintained. As mentioned by an employee in company D, it is important to have a responsible person for managing processes and to have managers who understand the value of processes. Another factor is the experience that practitioners already have with a given process, as well as with the Domain and the Product : if they are familiar with it, they might even optimize it without following all the instructions, while for employees that are not used to work according to a given process description it might be confusing and may potentially trigger the introduction of PD. In company E, we found that the different departments had their own understanding of agile processes, which caused challenges when they collaborated across departments. Therefore, one crucial action they decided to take was to work on building process competence at the company level and share process knowledge across departments.
  2. Value neglection : an important issue about processes is that it is not often clear to all the stakeholders what value it brings to them or to the organization. The lack of a clear explanation and education of the stakeholders on what value the process brings to the organization often causes the process executors to neglect the process, leading to PD. On the other hand, a process needs to be designed with a clear purpose and value in mind, and not just as a mandatory management equipment introduced by the organization.
  3. Lack of follow-up assessment: once the process has been designed and implemented, it should be assessed and improved according to the needs of the stakeholders. However, the lack of such follow-up does not allow to identify and track possible PD. In addition, the lack of follow-up and improvement does not ensure that any divergence from the process is captured and handled, which may lead to the growth of PD.
  4. Special contexts and situations: different companies, units, teams, special domains, special events, etc. all contribute to making existing processes sub-optimal, which generates PD and costly consequences if such special contexts and situations are not accounted for in the process.
  5. Cultural causes: there are several cultural issues that have been mentioned by the practitioners. This category has been further elaborated in the following sub-categories:
  6. A major issue is the lack of software culture in other organizations , for example, related to mechanical and electrical engineering. This means that processes that are well-designed for other contexts are not optimal for software development.
  7. In addition, different teams and different individuals have different experiences, maturity, motivation andleadership styles (they might like or not to be guided by a process). This leads processes to be optimal for one team or one individual but not for another. Various issues have been mentioned in the interviews that are related to these cultural aspects: experienced people might neglect the process thinking that they do not need it (while occasionally missing newly added critical steps), while less experienced individuals and teams might not understand the purpose of the process and just rigidly follow it without judging special situations. The same process can be followed by individuals and teams who desire a proper guide to be followed, while others might instead desire to be only self-guided and independent (even at the expense of other organizations).
  8. The developers might feel powerless to change processes: although developers can be designers of their own processes in some cases, many times (especially for large organizations), they are actors or executors of processes that are designed by other stakeholders, sometimes in other organizations, for specific purposes (certification, safety, etc.). In these cases, developers are not often asked if the process is suited for them and their workflow, and they usually find it difficult to reach out and effectively ask to change the process, so PD is accumulated without being tackled effectively.
One of the interviewees from company A explicitly estimated that cultural issues could even account for a third of the total number of PDs within their company.
  1. Lack of prioritization: similarly to TD, PD issues are quite often not managed because they are not prioritized as important to be fixed. This can be due to too many foci for the teams, or to strategies focused on short-term goals etc. The interviewees mentioned that PD issues often get attention only after several employees have raised the issue and one interviewee also stated that the PD issue needs time to be discussed iteratively during several occasions before it might get attention and thereafter be prioritized. In addition, many of the interviewees mentioned that PD issues are at best reported in a non-prioritized list also by the stakeholders, which does not help them get attention. This is an issue that we know well in connection with TD: to be prioritized, the TD issues need to be assessed and estimated. This is not something that is currently being done with PD issues, probably because of the lack of a framework, practices and responsible for implementing or changing the process.
  2. Technology and tools: the infrastructure is important to support the processes, and to automate and facilitate their steps. The lack of infrastructure or the presence of infrastructure debt (described earlier) can cause additional PD, like in the case when an old tool configuration management tool does not support fast deliveries.
  3. Cost of process changes: sometimes, it is known how to eliminate or avoid some PD. However, the cost of removing the PD can be prohibitive, especially if the value and the interest paid by the practitioners due to PD are not clear and assessed. In addition, company C mentioned that in many cases the estimations for changing the process turned out afterwards to be incorrect, which caused them to be cautious about fixing further PD.
  4. Organizational causes: as for the cultural factor, there are many organizational issues that can affect the process. Examples of organizational issues are related to a structure where roles and responsibilities are not clear. This is directly responsible for Roles’ debt, as the roles created for the process do not have clear matches in the organization and the process is not carried out by the individuals who are supposed to.
Another issue is related to the interaction with very different organizations with different cultures, interests andpower: examples are processes for example (not) followed by open source organizations developing an OSS component used by the development team (e.g. the lack of a correct library versioning), or other stakeholders that may have interests in receiving data to compute analytics without knowing about the burden for the developers, or yet again organizations that are just used to employ unnecessarily heavy processes, which make software development inefficient. The issue is not so much the existence of external organizations, but rather thedistance between the stakeholders in the software development team and such organizations. It is possible that the different organizations, to communicate, have to go through several levels of indirection (talking to a manager who talks to another manager etc.), which does not contribute to making the stakeholders aware of each other needs and challenges. Yet other organizational issues might be related to the sheerscale of the organization. The feedback loop between the process designers and the many stakeholders (e.g. many teams) is prohibitive and efficient top-down followup is not possible. Tailoring the process to all possible contexts is not feasible without empowering the stakeholders themselves to tailor the process: however, this might easily diverge from the original purpose, as the stakeholders might try to optimize for their local optimum, creating PD that affects other stakeholders.
External trends: in some of the interviews, especially from company A, several of the participants described external trends that affect how processes are adopted in the company. Adopting processes that are not suitable for the company according to trends can lead to PD.
Lack of trust
Especially in the longitudinal study, we found that a lack of trust affected PD. For example, in Company E, the interviewees described that some developers were reluctant to share knowledge and their competence. One explained that sharing his expert knowledge could make him less important to the company and that others could take over his job. Another explained that developers resisted letting others access the source code as they did not trust them to do a good job with it.

4.5 Which PD causes are the most common? (RQ2.3)

From Figure 5, it is possible to see how the participants from the cross-company interview chose the causes that the most were causing PD (RQ2.3). Three voters for company A, two for company B, 3 for company C and 2 for company D.
The most voted, and the one that was voted by all the participating companies is the presence of poor technology and tools . The second most voted one, especially from company A, was theneglect of the process value . Special context and solution and Lack of improvement prioritization were voted on by three organizations.
However, it is interesting to see how different roles and participants from different companies have voted differently. This might mean that in different sub-contexts, different causes might generate more PD. All in all, one could consider most of the causes as contributing to generating PD.