Managing software development projects (2nd ed.): formula for success
Managing software development projects (2nd ed.): formula for success
Project retrospectives: a handbook for team reviews
Project retrospectives: a handbook for team reviews
Evaluating software architectures: methods and case studies
Evaluating software architectures: methods and case studies
Agile software development
Postmortem: Never Leave a Project without It
IEEE Software
Using Post Mortem Analysis to Evaluate Software Architecture Student Projects
CSEET '05 Proceedings of the 18th Conference on Software Engineering Education & Training
Postmortem reviews: purpose and approaches in software engineering
Information and Software Technology
Problems and their mitigation in system and software architecting
Information and Software Technology
Electronic Notes in Theoretical Computer Science (ENTCS)
A tool supporting root cause analysis for synchronous retrospectives in distributed software teams
Information and Software Technology
Perceived causes of software project failures - An analysis of their relationships
Information and Software Technology
Hi-index | 0.00 |
Retrospective analysis is a way to share knowledge following the completion of a project or major milestone. However, in the busy workday of a software project, there is rarely time for such reviews and there is a need for effective methods that will yield good results quickly without the need for external consultants or experts. Building on an existing method for retrospective analysis and theories of group involvement, we propose improvements to the root cause analysis phase of a lightweight retrospective analysis method known as post mortem analysis (PMA). In particular, to facilitate brainstorming during the root cause analysis phase of the PMA, we propose certain processual changes to facilitate more active individual participation and the use of less rigidly structured diagrams. We conducted a controlled experiment to compare this new variation of the method with the existing one, and conclude that in our setting of small software teams with no access to an experienced facilitator, the new variation is more effective when it comes to identifying possible root causes of problems and successes. The modified method also produced more specific starting points for improving the software development process.