Personal tools


Authors: Ville Ylimannela

Category: research article

Keywords: risk management, agile, scrum, software development

Abstract: This paper researches risk management in agile software development. In traditional waterfall-model risks were usually managed by using project risk management frameworks. Nowadays agile methods have started replacing the traditional models. One of the reasons was old models inability to respond constantly changing business requirements. Agile development is based on short iteration cycles, which allow them to respond to changes in business environment. Using agile development is itself risk management at project level. Problems started arising, when people tried to merge the old school heavy project risk management models with agile models. One of the key principles in agile development is to avoid unnecessary bureaucracy and documentation. The traditional risk management is heavily centered around documentation. Two companies were interviewed during the making of this paper. The goal was to address the issues which arose during the interviews. The suggested model is based on existing models and interviews.

Permanent link to this page:

File Initial submission
reviewer357 says:
Oct 03, 2012 11:29 AM

Topic/title is relevant for practitioners and for academia.
Not ready for publishing without major rework. The paper lacks methodology and design. Furthermore, the proposed model itself appears to be build on opinions, ignores substantial elements of risk mgmt.

Research questions vague/unknown to reader.
what research method is used?
Who is interviewed?
what were the concrete results of the interviews?
Company description missing. Case description missing.
What does the BoK say to answer the RQs?
Reference section is extremely thin.
Risk management and security are mixed as they would be the same thing. IMO they are completely different issues.

general: how does the model solves the issues found from the interviews?
Where is the model coming from (based on what data is the model constructed)?
3.1. what is new here? I think this is straight from a textbook.
3.2. appears that team has a lack of competence in security area. Is RM to educate the team? IMO, security is a product requirement (might be both functional and non-functional) like many others. Potentially in some software security is of higher importance compared to other requirements.
Fig 4. How does the process tackle the risk. I see only that the process produces documentation. How are risks followed? How are the related actions monitored? What happens in the very beginning i.e. at release planning (if exists). What happens before sprint planning conc. the risks?
Table1. What are the reasons that all risk mgmt related activities are focused in Sprint planning? Where does this come from? What alternatives are there?

Once more the author jumps from Risk mgmt to security requirements of the products. Only training for security is highlighted. Why is this in the model? Why not training for risk mgmt? What has this training anyway to do with the model – as this is competence development?

Some add-on thoughts:
Risk mitigation of larger (or unknown) feature by refining the features (and User Stories) seemed missing in the model?
What has the SoS to do with risk approval? Misconception of SoS? Risk approval is business decision and belongs to Product Owner.
The heart of the risk mgmt is in executing the preventive and mitigation actions, not in identifying and listing risks.

Pasi Tyrväinen
Pasi Tyrväinen says:
Nov 14, 2012 04:23 PM

Editor decision

We have good comments from the reviewer. Looking forward for a revised version of the paper (with response for the reviewer on how their comments were treated).

Pasi Tyrväinen
Pasi Tyrväinen says:
Oct 13, 2013 06:48 PM

The review process of this submission has been finished. Thank you for your submission.

  • partners