Figure 8 Mitigation strategies proposed by the interviewees. Dark grey
boxes have sub-categories.
We have previously reported the causes of PD. By mitigating such causes,
organizations can also reduce the generation of PD. On the other hand,
some of the mitigation strategies can be less proactive but more
reactive.
From the interviews conducted in step 1, we distilled three main
categories of mitigation strategies: Process Governance, Process Design
and Process Education. These categories were validated in step 2.
In two cases, Process Governance and Process Design strategies overlap.
Process Governance: these are strategies that can be employed
by the process owners and stakeholders to reduce the chances of
accumulating PD or to increase the chances of changing the processes
to reduce PD.
Stakeholders feedback: one of the effective strategies to
understand where PD hides in the organization, is to ask the
stakeholders and actors involved to report on hinders such asdelays, lack of quality, time waste etc.
Some PD might be difficult to measure in practice, and the stakeholders
are the only ones who can observe if there is an issue related to the
process. Process owners should take the initiative to reach out to
stakeholders, not only to set up the process, but to receive feedback
from them during the continuous execution.
At the same time, it is also important that stakeholders are
incentivized to report issues with the process, especially in explaining
the impact of the issue.
As one of the respondents from company D mentioned: “I think it
has originated from us developers pushing on very much […] we’re
using way too much time on this, and then at some point it gets too
much, and then the management hears it [we reported] both the amount
of time that it takes and the amount of time that it delays our
releases” “I remember at least one of the optimizations that were done. The
way it got approved was that some of the other managers had to write
“we do this perhaps 200 times a year, and we’ll save two hours every
time.” Suddenly 400 developer hours. Then it’s suddenly justifiable.”Evaluation metrics: measurements can be analyzed by the process
owners, for example understanding the speed with which the process is
executed, the satisfaction of the stakeholders (for example via surveys
or direct contact) and the quality of the software that is implemented.
Practitioners enumerate some solutions, but also mentioned that current
approaches are rather inefficient and better approaches need to be
developed.Prioritization of PD issues: practitioners mentioned several
ways in which they promote the allocation of resources to change
processes and remove or mitigate PD.
First, like for TD management, they advocate the need for aprioritized list of PD issues: a generic and long list without
having already provided a priority (e.g. based on cost/benefits
analysis) by the makers of the list (process owners, developers, etc.)
would not be taken in consideration by the responsible for allocating
resources (PM, POs, etc.). It is more valuable to advocate for changing
a few, well supported PD issues rather than just having a long list of
issues for which the RoI is uncertain and the time is not enough to
discuss in meetings.
However, even when the list is present, practitioners mention that the
best strategy is to “sell” and “mature
the discussion” around the PD issues that are the most critical to be
mitigated during meetings with the responsible for allocating resources
(PM, POs, etc.). Often, they mentioned, it takes several meetings before
the participants of the meeting perceive a (PD) issue as important to be
taken into consideration. Prioritizing PD is therefore perceived as
mostly a social and “political” activity to lobby for the most
important PD issues to be considered in a highly competitive race for
resources (against features, technical debt, bug fixing, social issues,
etc.).Process enforcement: Some of the practitioners mentioned how
enforcing the process with checks and tools can help reduce and avoid
PD. For example, when referring to an obligatory form to be filled in
during the process to comply with an external certification process, one
of the interviewees from company D mentioned:“We’ve made the system in a way where we can’t really ignore them
[data to be filled in during the process]. We have to fill them. And
I think that’s actually quite good, because otherwise we would close the
tasks and then when we hit the release date, then we discover, okay,
half the things haven’t been filled out, and then it’s a huge task to
fill in the data.Coordinator for different organizations: when different
organizations require a process to be in place for the software teams
(e.g. for safety certification, analytics etc.), it is important to have
an effective coordinator to bridge the needs of the two sides and to
foster their communication. For example, company C managed to conduct a
comprehensive effort (managed by an appointed coordinator) to share the
same language between the software and the hardware units leveraging
system engineering practices, while company D mentioned that they are in
the process of appointing a coordinator between the software teams and
the analytics unit to improve the reporting process, discussing what
additional information is really needed by the software developers and
which one is not and can be removed from the mandatory documentation.
This strategy overlaps with process design, as the coordinator
can be a role that is included in the role definition of the process.Automation and checks: the process owners and executors can
decide to implement automated steps of the process, and to build
automated checks that the process is indeed followed. “A lot of
these [manual steps in the process], almost all of the things that I
find annoying here could be automated. Definitely.”However, such practice is not widespread: in many cases automation
requires an investment by a developer or a dedicated “process and
tools” team to implement such automations. One of the issues mentioned
by the interviewees is that such automations also need to be prioritized
by the management to allocate resources, and in many cases, it is
difficult to advocate for the benefits against the cost of
implementation (or else, it is difficult to show that the principal paid
would cover saving the interest).
Automation and checks are both a governance strategy, but can be part of
the process design overall category, as their definition can be included
in the design of a process.
Process Design: these strategies are the ones that can be
made when a process is either designed from scratch, or when an
emerging process is improved and optimized.
Process visualization: one of the ways to identify PD and to
argue for its reduction is to visualize the process. Company D also
showed us an instance of the discussed process that was reproduced by
one of the developers that were skilled with visualization techniques.
In such an illustration, it was quite clear where the bottlenecks were
happening (for example where a manual copy-paste from two different
tools was performed). According to the participants, presenting the
visualization to the managers convinced them that the PD was detrimental
and that it needed to be tackled (for example by introducing automation
between the two tools). Process visualization can also include
data-driven approaches. However, this doesn’t seem to be currently an
approach that is in use at the interviewed organizations.Process size reduction: some of the companies, for example A
and B, are very large organizations including several disciplines and
are characterized by the need of having formal processes that, in some
cases, are pre-defined. In other words, some steps that are included in
the processes are there because the process has been standardized: for
example, a process to ensure that unit tests reach a given coverage
might be more suitable for some teams but not others. Company B
mentioned that such a process, once standardized for the many software
teams, might need to be reduced for some of the teams. In other cases,
(emerging) processes tend to grow unchecked because of the needs of
different organizations, but are not revised to be improved, and, in
particular, simplified, for example, by removing obsolete steps.Optional and better checklists: to help executors follow the
processes, often checklists with the main steps of the process. However,
practitioners mentioned that often such checklists are obsolete or not
optimal and would need to be continuously updated. “So when
people are learning and giving feedback […] so that we
actually can update when we find better ways of doing things [process
checklists].”Interviewees mentioned that checklists could be improved mainly in two
ways: by restructuring overgrown checklists, and by reducing them: in
fact, checklists are especially useful the first time a process is in
use, while after a while, experienced practitioners might just disregard
the whole checklist as they feel like they have already learnt the
process and they find following the whole checklist tedious and
time-consuming. However, this can cause them to miss a critical step. By
reducing checklists according to the experience of the team with the
given process, can therefore reduce the overhead of the teams and still
allow practitioners to be reminded of critical steps that should not be
overlooked.Process complexity reduction: In Company E, they decided to
backsource the development to reduce the complexity caused by two
incompatible development processes at two locations. By ending the
outsourcing relationship, they could instead have a well-defined process
in one place.
Process education: the last set of strategies to reduce PD is
related to the education of processes. Executors, especially in large
companies, need to be informed about not only how to follow a process,
but also about why processes need to be followed (value). In many
cases, processes can be useful for one purpose and for a selection of
stakeholders, but they are carried out by others. If these latter
practitioners (e.g. developers in a team) are not informed and do not
understand the value of such a process for the organization, they are
not well motivated to follow the process. For these reasons, education
is massively used by company A:
“The process here is quite complex, and there are a few other
teams that see the value of how to do it. […] We have to educate
people. If we have something that people don’t understand, then we have
to have an education that explains it.”.
In Company E, they held internal workshops to get a common understanding
of roles and processes, and cross-department workshops on agile culture.
In addition, they established cross-company guilds on agile methods for
all departments, not only the software development department.