6. CONCLUSION

In this paper, we extensively explored the phenomenon of Process Debt in five companies in three steps, including interviews, workshops, direct observations over a longitudinal case and cross-case validation comparisons.
Current state of the art and practice of PD is lacking a solid framework to reason about the concept and empirical evidence of the state of art and practice. Consequently, the phenomenon is overlooked, and software organizations do not have a reference point to manage PD.
This paper presents a novel framework to categorize Process Debt and its empirically-based state of art and practice concepts. Our contributions offer a comprehensive approach to understanding PD across domains and provide a starting point for software organizations to manage the phenomenon efficiently. By understanding how different parts of software organizations can manage PD and its effects, we articulate a strategy that allows software organizations to manage PD efficiently. We provide an initial framework, including a definition, taxonomies and an overall conceptual model, representing a novel reference point for practitioners to understand, reason about and manage PD.
The framework also defines the interrelations between various elements of PD and emphasizes that managing PD is a cyclical, iterative process. The framework can be used to make connections between different PD processes, identify commonalities among them and thus better comprehend the complex PD landscape. Furthermore, the framework can be used to analyse and structure PD initiatives, suggest improvements, and provide guidance for decision-making. It can also be considered the foundation to support further research: PD is a harmful phenomenon affecting software products and practitioners: it needs attention in software organizations and, consequently, in academia with empirical investigation and additional practices. We report a state of practice including concrete causes, consequences, occurrence patterns over time and mitigation strategies to manage PD, which can help practitioners systematically manage PD in practice. The interviewees also give valuable insights on what is needed in the field to manage PD better, supporting further research and tool development on the topic.
We found that the debt metaphor helps reasoning about the prioritization of process improvements concerning competing activities such as feature development. We argue that some existing TD practices can be adapted to help with the management of PD, while new approaches are needed to tackle specific issues, as processes have many aspects that might not concern the management of TD.
We suggest that Process Debt can be managed by recognizing it as such, formalizing it, prioritizing its resolution, and using relevant metrics to keep track of its progress. We emphasize the need for collaboration across organizational and team boundaries to ensure that Process Debt is properly identified and managed.
With this first comprehensive study, we encourage and envision a larger and joint community effort to further develop theories related to PD and to improve its state of the art and practice. We seek to continue a dialogue to identify and discuss the specifics of the diagnoses and prescriptions for better Process Debt management and to raise awareness of the issue in the wider community. We hope our work will provide a useful starting point for further research, theory and collaboration.
ACKNOWLEDGMENT
We thank the interviewees from the Software Center companies (company A-D) for the invaluable insights provided as well as the participants in company E.
REFERENCES
[1] T. Dingsøyr, S. Nerur, V. Balijepally, and N. B. Moe, “A decade of agile methodologies: Towards explaining agile software development,” Journal of Systems and Software, vol. 85, no. 6, pp. 1213–1221, Jun. 2012
[2] O. Pedreira, M. Piattini, M. R. Luaces, and N. R. Brisaboa, “A systematic review of software process tailoring,” SIGSOFT Softw. Eng. Notes, vol. 32, no. 3, pp. 1–6, May 2007, doi: 10.1145/1241572.1241584.
[3] R. G. Schroeder, K. Linderman, C. Liedtke, and A. S. Choo, “Six Sigma: Definition and underlying theory,” Journal of Operations Management, vol. 26, no. 4, pp. 536–554, Jul. 2008
[4] Software Engineering Institute, “CMMI for Development, Version 1.3,” Carnegie Mellon University, Pittsburgh, Pennsylvania, Technical Report CMU/SEI-2010-TR-033, 2010. Accessed: Oct. 09, 2020.
[5] S. Zopf, “Success factors for globally distributed projects,” Software Process: Improvement and Practice, 2009.
[6] D. Moitra, “Managing change for software process improvement initiatives: a practical experience-based approach,” Softw. Process: Improve. Pract., vol. 4, no. 4, pp. 199–207, Dec. 1998
[7] T. Besker, A. Martini, and J. Bosch, “Software developer productivity loss due to technical debt—A replication and extension study examining developers’ development work,” Journal of Systems and Software, vol. 156, pp. 41–61, Oct. 2019, doi: 10.1016/j.jss.2019.06.004.
[8] T. Besker, H. Ghanbari, A. Martini, and J. Bosch, “The influence of Technical Debt on software developer morale,” Journal of Systems and Software, vol. 167, p. 110586, Sep. 2020, doi: 10.1016/j.jss.2020.110586.
[9] Z. Li, P. Avgeriou, and P. Liang, “A systematic mapping study on technical debt and its management,” Journal of Systems and Software, vol. 101, pp. 193–220, Mar. 2015, doi: 10.1016/j.jss.2014.12.027.
[10] A. Martini, V. Stray, and N. B. Moe, “Technical-, Social- and Process Debt in Large-Scale Agile: An Exploratory Case-Study,” in Agile Processes in Software Engineering and Extreme Programming – Workshops, Cham, 2019, pp. 112–119, doi: 10.1007/978-3-030-30126-2_14.
[11] P. Avgeriou, P. Kruchten, I. Ozkaya, and C. Seaman, “Managing Technical Debt in Software Engineering (Dagstuhl Seminar 16162),”.”
[12] D. A. Tamburri, P. Kruchten, P. Lago, and H. van Vliet, “What is social debt in software engineering?,” in 2013 6th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE), May 2013, pp. 93–96, doi: 10.1109/CHASE.2013.6614739.
[13] K. H. Rolland, L. Mathiassen, and A. Rai, “Managing Digital Platforms in User Organizations: The Interactions Between Digital Options and Digital Debt,” Information Systems Research, vol. 29, no. 2, pp. 419–443, May 2018, doi: 10.1287/isre.2018.0788.
[14] A. Martini and J. Bosch, “An empirically developed method to aid decisions on architectural technical debt refactoring: AnaConDebt,” 2016, pp. 31–40, doi: 10.1145/2889160.2889224.
[15] I. Sommerville, Software Engineering. Pearson Education, 2007.
[16] P. Veyrat, “What are the differences between workflow and processes?,” HEFLO BPM, Jan. 30, 2018. https://www.heflo.com/blog/bpm/workflow-and-processes/ (accessed Jul. 15, 2020).
[17] Küpper, Steffen, et alt. ”How has SPI changed in times of agile development? Results from a multi‐method study.” Journal of software: evolution and process 31.11 (2019): e2182.
[18] Kuhrmann, Marco, Philipp Diebold, and Jürgen Münch. ”Software process improvement: a systematic mapping study on the state of the alt.” PeerJ Computer Science 2 (2016): e62.
[19] Clarke, Paul, and Rory V. O’Connor. ”The influence of SPI on business success in software SMEs: An empirical study.” Journal of Systems and Software 85.10 (2012): 2356-2367.
[20] Moe, Nils Brede. ”Key challenges of improving agile teamwork.” International conference on agile software development. Springer, Berlin, Heidelberg, 2013.
[21] Argyris, Chris and Schön, Donald A., Organizational Learning II: theory, method and practice. Reading, Mass.: Addison-Wesley. (1996).
[22] Walsham, G. 1995. “Interpretive Case Studies in IS Research: Nature and Method,” European Journal of Information Systems, (4:2), pp. 74-81.
[23] Klein, H. K., and Myers, M. D. 1999. “A Set of Principles for Conducting and Evaluating Interpretive Field Studies in Information Systems,” MIS Quarterly (23:1), pp. 67-93.
[24] A. Martini, T. Besker and J. Bosch, ”Process Debt: a First Exploration,” 2020 27th Asia-Pacific Software Engineering Conference (APSEC), 2020, pp. 316-325
[25] Runeson, P., Höst, M. Guidelines for conducting and reporting case study research in software engineering. Empir Software Eng 14, 131 (2009). https://doi.org/10.1007/s10664-008-9102-8
[26] M. Unterkalmsteiner, T. Gorschek, A. K. M. M. Islam, C. K. Cheng, R. B. Permadi and R. Feld“, ”Evaluation and Measurement of Software Process Improvement—A Systematic Literature Revi”w,” in IEEE Transactions on Software Engineering, vol. 38, no. 2, pp. 398-424, March-April 2012, doi: 10.1109/TSE.2011.26.
[27] an Solingen, R., Berghout, E., Kusters, R., & Trienekens, J. (2000). From process improvement to people improvement: enabling learning in software development. Information and Software Technology, 42(14), 965-971.
[28] Mikalsen, Marius, et al. “Agile digital transformation: a case study of interdependencies.” Proceedings of the 39th International Conference on Information Systems (ICIS). Association for Information Systems (AIS), 2018.
[29] Stray, Viktoria, et al. ”An empirical investigation of pull requests in partially distributed BizDevOps teams.” 2021 IEEE/ACM Joint 15th International Conference on Software and System Processes (ICSSP) and 16th ACM/IEEE International Conference on Global Software Engineering (ICGSE). IEEE, 2021.