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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 ).