Improving the effectiveness of root cause analysis in post mortem analysis: A controlled experiment

Bjørnson, Finn Olav; Wang, Alf Inge; Arisholm, Erik

doi:10.1016/j.infsof.2008.02.003

Cited by 29 publications

(44 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Generally speaking, retrospectives aim to recognise software engineering successes and failures and to link the related experience to action proposals that will improve future successes and decrease the likelihood of future failures. The tangible outcome of a retrospective is a report (Dingsøyr 2005), which may include positive and negative experiences (Bjørnson et al 2009), detected problems (Lehtinen et al 2011;Stålhane et al 2003), voting results (Lehtinen et al 2011) and action proposals (Lehtinen et al 2011). Retrospectives are used at various levels, including the level of software teams, organisations and companies (Lehtinen 2014).…”

Section: Methods For Conducting Retrospectives In Software Engineeringmentioning

confidence: 99%

“…The target definition aims to focus the scope of the retrospective analysis on a relevant and important topic. Such topics have included the causes of software defects (Jalote and Agrawal 2005;Card 1998;Lehtinen et al 2014a), the detection of negative and positive development experiences (Schwaber and Sutherland 2011;Bjørnson et al 2009), analysis of the requirements problems (Tiedeman 1990;Jin et al 2007), lead-time problems (Lehtinen et al 2014a), installation problems (Lehtinen et al 2014a) and expectation mismatches (Lehtinen et al 2015b).…”

Section: Methods For Conducting Retrospectives In Software Engineeringmentioning

confidence: 99%

“…Bjørnson et al (2009) presented the outcomes of team-level retrospectives via two examples. However, they did not thoroughly analyse the outcomes.…”

Section: The Outcomes Of Lightweight Software Engineering Retrospectivesmentioning

confidence: 99%

“…In our terminology, a team-level retrospective refers to a retrospective conducted by the software development team members, such as sprint retrospectives or team-level post-mortem analysis (Schwaber and Sutherland 2011;Bjørnson et al 2009). …”

Section: Research Objective and Questionsmentioning

confidence: 99%

See 3 more Smart Citations

Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives

2016

View full text Add to dashboard Cite

Team-level retrospectives are widely used in agile and lean software development, yet little is known about what is actually discussed during retrospectives or their outcomes. In this paper, we synthesise the outcomes of sprint retrospectives in a large, distributed, agile software development organisation. This longitudinal case study analyses data from 37 teamlevel retrospectives for almost 3 years. We report the outcomes of the retrospectives, their perceived importance for process improvement and relatVed action proposals. Most discussions were related to topics close to and controllable by the team. However, the discussions might suffer from participant bias, and in cases where they are not supported by hard evidence, they might not reflect reality, but rather the sometimes strong opinions of the participants. Some discussions were related to topics that could not be resolved at the team level due to their complexity. Certain topics recurred over a long period of time, either reflecting issues that can and have been solved previously, but that recur naturally as development proceeds, or reflecting waste since they cannot be resolved or improved on by the team due to a lack of controllability or their complexity. For example, the discussion on estimation accuracy did not reflect the true situation and improving the estimates was complicated. On the other hand, discussions on the high number of known bugs recurred despite effective improvements as development proceeded.

show abstract

Section: Methods For Conducting Retrospectives In Software Engineeringmentioning

confidence: 99%

Section: Methods For Conducting Retrospectives In Software Engineeringmentioning

confidence: 99%

“…Bjørnson et al (2009) presented the outcomes of team-level retrospectives via two examples. However, they did not thoroughly analyse the outcomes.…”

Section: The Outcomes Of Lightweight Software Engineering Retrospectivesmentioning

confidence: 99%

Section: Research Objective and Questionsmentioning

confidence: 99%

See 2 more Smart Citations

Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives

2016

View full text Add to dashboard Cite

show abstract

“…The major resources are participants' memory and collaborative effort to reconstruct the project, and various facilitation techniques exist (e.g. [ 11 ] ). In this paper we generically refer to retrospective reflection to indicate activities conducted at the end of a project phase to rethink the working process with the goal of learning from experience.…”

Section: Introductionmentioning

confidence: 99%

Supporting Reflection in Software Development with Everyday Working Tools

Krogstie

Divitini

2010

Proceedings of COOP 2010

View full text Add to dashboard Cite

Through their day-to-day usage collaboration tools collect data on the work process. These data can be used to aid participants' retrospective reflection on the process. The paper shows how this can be done in software development project work. Through a case study we demonstrate how retrospective reflection was conducted by use of an industry approach to project retrospectives combined with the examination of historical data in Trac, an issue tracker. The data helped the team reconstruct the project trajectory by aiding the recall of significant events, leading to a shift in the team's perspective on the project. The success of the toolaided retrospective reflection is attributed to its organization as well as the type of historical data examined through the tool and the tool features for navigating the data. These insights can be used to help project teams determine the potential of their tools to aid retrospective reflection. IntroductionSoftware development (SD) is highly cooperative work which has received considerable attention in CSCW [1][2][3] . In SD, mistakes are common as well as costly [ 4 ] , and learning from experience is essential [ 5 ] .In SD organizations using large integrated systems to support and coordinate work, efforts to have the organization learn from experience may be integrated into predefined work processes and supported by tool functionality for collecting and providing experience data. The idea of experience factories [ 6 ] reflects a similar idea. In other settings, as in agile software development [ 7 ] , learning from experience may be more informal and deferred to face-to-face project meetings and retrospective B. Krogstie ( ) and M. Divitini

show abstract

Impacts, causes, and solutions of architectural smells in microservices: An industrial investigation

et al. 2022

View full text Add to dashboard Cite

As a recently predominant architecture style, MicroService Architecture (MSA) is likely to suffer the issues of poor maintainability due to inappropriate microservice boundaries. Architectural Smell (AS), as a metaphor for potential architectural issues that may have negative impacts on software maintenance, can be used to pinpoint refactoring opportunity for evolving microservice boundary. However, existing studies mostly focus on AS detection with little further investigation on the possible impacts, causes, and solutions of AS, which does little help in addressing the bad smells in architecture. Our goal in this study is to bridge this gap by investigating the possible impacts, causes, and solutions of AS in MSA-based systems. An industrial case study is carried out to collect repository data and practitioners' views on six typical ASes in a real MSA-based telecommunication system. Statistical Analysis and Coding techniques are used in the analyses of quantitative and qualitative data respectively.The results show that AS influences the modularity, modifiability, analyzability, and testability of the MSA-based system, which further induce extra cross-team communication, change-and fault-prone microservices. To explore the causes for AS, a five-aspect conceptual classification with technology, project, organization, business, and professional is proposed, in which the business and organization aspects take the major roles. Both technical and non-technical solutions are distilled to deal with ASes despite potential constraints. These results and their comparison to current literature are discussed, which provide practical implications in coping with AS in microservices.

show abstract

Improving the effectiveness of root cause analysis in post mortem analysis: A controlled experiment

Cited by 29 publications

References 12 publications

Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives

Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives

Supporting Reflection in Software Development with Everyday Working Tools

Impacts, causes, and solutions of architectural smells in microservices: An industrial investigation

Contact Info

Product

Resources

About