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