Figure 6. Consequences of PD
When analyzing the consequences (Figure 6), it was evident that PD has two kinds of negative effects: besides the generation of a long-term interest (as for TD), process sub-optimality can actually often lead to initial waste (of time, effort, budget, etc.) for the stakeholders. The initial waste can in some cases, be reduced by refining the process. However, in many cases, such negative effects can also easily become a long-term interest. This means that the two groups are not mutually exclusive, but the consequences listed as initial waste might also belong to the long-term category, although they might show up early.

4.6.1 Long-term consequences

  1. Late customer deliveries: although skipping some steps and activities in the process might promote quicker deliveries of customer value in the short-term, the interviewees reported that commonly such a way of working would cost more in the long run and could also cause longer delivery times in the long term. In some reported cases, the customers were not aware of the PD and how it was accumulated and its consequences, which made them unhappy when the unexpected long-term delays showed up.
  2. Low software product quality and TD: one of the purposes of processes is to assure that products are delivered to the customers and are satisfying several qualities critical for the customers. Many PD instances have been mentioned by the interviewees as generating quality issues in the long term. For example, not delivering proper coverage for unit testing can create additional defects in the long run, and can undermine the confidence of the organization in delivering additional features that are not appropriately tested (company C). Another example is given by several of the companies, who mentioned how PD quite often generates TD. For example, sub-optimal code reviews do not catch TD in the code, while the lack of a process to manage the iterative and continuous feedback loop between software architects and development teams can lead to architecture debt.
  3. Hindering other processes: processes are often intertwined, and the presence of PD in some processes might often generate disruption in other processes as well, generating new PD (e.g., in the case of synchronization debt). This is a characteristic that leads to the contagiousness of PD and possible vicious circles. An example mentioned by our interviewees was related to an existing PD (infrastructure debt) related to an outdated tool whose technical issues prevented the implementation of continuous integration.
  4. Issues with certification: another example reported by companies A and D was related to skipping process steps related to certifications. Such steps often provide documentation and evidence that the product has indeed successfully gone through all the steps that are required by the certification authorities. In the end, this could cause difficulties in obtaining certifications or the need to re-validate and re-perform steps of the process wasting a large amount of time, resources and budget in the long term.
  5. Increased turnover: In Company E, some people were frustrated by the PD issues related to the incompatible processes between the on-site and off-site teams, resulting in a higher attrition rate. Especially lack of competence among the off-site team members caused frustration. Further, role debt in the case of the product owner and team lead in Company E caused people to quit because they did not understand their responsibility, authority and how to best collaborate and coordinate with other team members and stakeholders.

4.6.2 Initial waste

When process designers create a process, it can be the case that the process is sub-optimal right from the beginning. This can be due to many challenges, such as, for example, the difficulties of satisfying all the stakeholders involved. Although these effects can be multiple, we focus here on the effects that the initial waste has on the software developers.
  1. Developers overhead: besides tedious work and errors, several of the PD mentioned in the interviews directly caused an overhead for the software developers. Sub-optimal documentation granularity, infrastructure debt, the presence of unsuitable processes, and other activity-specific debt were the source of unnecessary effort spent by the developers in activities that were sub-optimally designed as mentioned for several instances presented in section IV.B.
  2. Developers’ mistakes: some PD affects the developers by making their workflow error-prone. For example, a developer from company D mentioned how the frequent copy-paste and duplication of information from one tool to another (because of infrastructure debt) caused him to make mistakes that were then propagated to the stakeholders consuming the documentation created during the process. In general, when processes and workflow are not well synchronized (see synchronization debt), the developers often have to switch tasks continuously from one process to the other, one tool to another etc. Although this does not perhaps directly create a measurable extra-effort, developers suffer from unnecessary task switching as an additional layer of complexity on their job, which is not very different from having a more complex architecture to deal with. However, such additional complexity created by PD is difficult to see, unless the workflow is visualized. In companies B and D, where we were able to visualize the studied process, the interviewees mentioned how they were helped in catching the presence of PD.
  3. Developers’ morale (tedious work): one issue, especially related to documentation debt and infrastructure debt is the creation of documentation or additional steps in the developers’ workflow that need to be delivered but are unnecessary. This can happen for several reasons, as mentioned earlier, because of organizational or cultural issues, or because of sub-optimal infrastructure. These issues are the source of overhead and tedious work for software developers, which affects their morale. According to our interviews, it is commonly the case that developers prefer to work with processes that allow them to feel productive. The sense of accomplishment can be highly reduced by the feeling that much of the work has been dedicated to producing documentation that is not really useful for anyone. This is also related to the neglect of value and unclear purpose. In some cases, developers might not be aware of what the value of some of their processes is, which has the same effect on their morale, although the additional steps and documentation might not actually be unnecessary.
  4. Uncertainty about the process: the lack of documentation and clarity about purposes and roles often creates confusion and uncertainty for the process executors. This leads to mistakes related to the outcome of the process, which in turn can generate several of the other consequences listed here, including the generation of additional PD. For example, in Company E, the product owners we interviewed described that in one of the meetings, when they shared obstacles, they felt that managers always overreacted and immediately tried to solve the issues. Consequently, people stopped sharing concerns that they had, which reduced information flow and knowledge sharing. While the product owners understood the meeting as a place to share and discuss problems – not necessarily fix them – the managers felt the pressure to solve all issues that could hinder the teams.
  5. Loss of trust in the processes: the presence of PD, especially related to the other initial waste categories mentioned previously, can create the perception for the developers that the processes are generally not trustable. Consequently, this can create a sub-culture in the teams for which processes are not worth being followed (even in those cases where the process might be optimal and valuable).

4.7 Which consequences are the most impactful? (RQ2.5)

From the cross-company interview, we collected data as in Figure 7 Three voters for company A, two for company B, 3 for company C and 2 for company D. The most impactful PD consequence was considered the one generating low software quality and technical debt. Other voted by four or five participants, and generally voted by more than two companies, are the uncertainty about the process, theloss of trust in the processes and the impact ondevelopers (morale and overload ).