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.