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.