Context: Technical debt (TD) can bring short-term benefits to software projects, but its presence is also associated with issues such as decreasing product quality. Recent literature has proposed indicator-based strategies for TD identification and different approaches for TD management, but most of them focused on the point of view of software developers. Little is still known about how project management practitioners actually discuss, experience, and manage TD. Goal: This work investigates, from the point of view of project management practitioners, how they commonly discuss, experience, and manage TD. Method: We mined, curated, and selected a total of 42 TD discussions on Stack Exchange Project Management (SEPM), totaling 583 messages. We analyzed this data set quantitatively and qualitatively. Results: The most commonly discussed types of debt are process and people, revealing 47 indicators for recognizing debt items. We also found 72 practices related to TD management. Conclusion: The perspective considered by project management practitioners to analyze the TD phenomenon is different from the one considered by other roles in the software development process. This work organizes the TD indicators and management practices identified in SEPM into a Sankey diagram, which may assist practitioners and serve as guidance for future research.

Context: Contemporary software development is typically conducted in dynamic, resource-scarce environments that are prone to the accumulation of technical debt. While this general phenomenon is acknowledged, what remains unknown is how technical debt specifically manifests in and affects software processes, and how the software development techniques employed accommodate or mitigate the presence of this debt. Objectives: We sought to draw on practitioner insights and experiences in order to classify the effects of agile method use on technical debt management, given the popularity and perceived success of agile methods. We explore the breadth of practitioners’ knowledge about technical debt; how technical debt is manifested across the software process; and the perceived effects of common agile software development practices and processes on technical debt. In doing so, we address a research gap in technical debt knowledge and provide novel and actionable managerial recommendations. Method: We designed, tested and executed a multi-national survey questionnaire to address our objectives, receiving 184 responses from practitioners in Brazil, Finland, and New Zealand. Results: Our findings indicate that: 1) Practitioners are aware of technical debt, although, there was under utilization of the concept, 2) Technical debt commonly resides in legacy systems, however, concrete instances of technical debt are hard to conceptualize which makes it problematic to manage, 3) Queried agile practices and processes help to reduce technical debt; in particular, techniques that verify and maintain the structure and clarity of implemented artifacts (e.g., Coding standards and Refactoring) positively affect technical debt management. Conclusions: The fact that technical debt instances tend to have characteristics in common means that a systematic approach to its management is feasible. However, notwithstanding the positive effects of some agile practices on technical debt management, competing stakeholders’ interests remain a concern.

In seeking to complement consultants' and tool vendors' reports, there has been an increasing academic focus on understanding the adoption and use of software development methods and practices. We surveyed practitioners working in Brazil, Finland, and New Zealand in a transnational study to contribute to these efforts. Among our findings we observed that most of the 184 practitioners in our sample focused on a small portfolio of projects that were of short duration. In addition, Scrum and Kanban were used most; however, some practitioners also used conventional methods. Coding Standards, Simple Design and Refactoring were used most by practitioners, and these practices were held to be largely suitable for project and process management. Our evidence points to the need to properly understand and support a wide range of software methods.