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