Implementation of Risk Management with SCRUM to Achieve CMMI Requirements

Published Online October 2014 in MECS

Majority of the organizations are improving software development processes in order to achieve high quality products. The Capability Maturity Model Integration (CMMI) is one of the ways to improve software development processes. CMMI provides an integrated approach across the enterprise for improving processes. Scrum is one of the best methods that can be used with CMMI to improve the software development processes. Scrum is an iterative and incremental agile software development framework for managing software projects/products. Scrum is compatible with CMMI level 2 with a high percent but it is compatible with level 3 only with 24%. This research focuses on how we can adapt Scrum more compatible with CMMI to achieve level 3 by the implementation of risk management.

Risk management is one of the most important practices in software industry. Risk management is not indicated in the practices of Scrum where as it is one of important practices of CMMI level 3. In this paper, we discuss how risk management can be a part of the Scrum sprints. We propose a risk register that can be used as a tool for risk management.

Further paper is organized as follows.

Section II covers the related work. Section III describes the problem and the proposed solution.

Validation of the proposed solution is illustrated in section IV.

• II.    Related Work

  Gannon [1] explores the fundamentals of SCRUM as well as how this agile development methodology has been implemented on a project at the Johns Hopkins University Applied Physics Laboratory. The team members faced some difficulty in time management, colocated with the rest of the team and each team member's amenability to change [1]. Guang [2] has developed a vehicle management system using scrum as software process method with the template visual studio 2010 in order to improve the productivity and efficiency of SCRUM.

Łukasiewicz and Miler [3] proposed a C–S model to improve an actual software development process that defined a diagnostic questionnaire, a practice selection algorithm, an application process and built a software tool, these proposals implemented on two case studies. 3.5% of the suggested practices were rejected by the companies. Some 24.5% of suggestions were evaluated as not applicable for organizational or economic reasons, which leaves room for further improvement of proposed questionnaire. It is discussed that how to implement collaborative agile scrum software for complex multivendor competing environments [4]. A framework is proposed for collaborative agile software development. The roles of project manager, product owner and scrum master are specified. The specialty of this framework is that scrum master can work with product owner and business analyst. The main limitations of this study are [4] poor collaboration between teams due to distance factor (different time zone) and lack of time commitment from the customer representatives.

An extension of the scrum framework is proposed to improve learning of teams [5]. This extension is expected to support organizational learning and deliver benefits at strategic level. Four different flexible agile methods are identified to transfer knowledge across projects:

• •    mentoring and coaching;

• •    staffing project teams with members of other projects;

• •    participation in multi-project reviews;

• •    anticipation in multi-project retrospectives.

These four methods can be used as a guide for    framework that is a customized approach to improve development of strategies to promote learning across    software development by integrating CMMI and scrum.

scrum projects [5]. Samina and Javed [6] introduce a

Table 1. brief description of related work

Title of Papers	Limitations
An Agile Implementation of SCRUM [1]	•    In the beginning most of the team members on the project working with scrum found difficulty in time management •    Another limitation was each team member's amenability to change •    Another limitation is for the team was that one team member was not colocated with the rest of the team.
study and practice of Import Scrum agile software development [2]	This paper does not focus on the difficulty of the Scrum master to plan, structure and organize a project that lacks a clear definition.
Improving agility and discipline of software development with the Scrum and CMMI. [3]	•    3.5% of the suggested practices were rejected by the companies. •    Some 24.5% of suggestions were evaluated as not applicable for organizational or economic reasons,
Collaborative and Competitive Strategies for Agile Scrum Development [4]	•    Distance factor due to the different time zone for collaboration •    lack of time commitment from the customer representatives •    larger customer with larger projects are unwilling to collaborate agile software •    Problems in gathering and clarifying requirements are not mentioned.
Scrum and CMMI – Going from Good to Great [7]	• This paper not focuses carefully on cross functional team interactions and dynamics.
Challenges Faced While Simultaneously Implementing CMMI and Scrum [8]	• This paper does not attempt to present an exhaustive list of the challenges successfully faced and overcome by The Tax Company
Research on Combining Scrum with CMMI in Small and Medium Organizations [9]	• The organizations aiming to reach beyond the CMMI maturity level 2 are not fully attended by using the Scrum practices.
Can scrum help to improve the project management process? A study of the relationship between scrum and project management process area of cmmi-dev 1.3 [10]	•    Scrum practices do not leave a paper trail that can retrospectively demonstrate the implementation of some of the SGs of CMMI •    SCRUM can't cover process area like: Risk Management, Supplier Agreement Management and Quantitative Project Management •   Deferent meaning of product owner in CMMI & SCRUM
Mapping CMMI Project Management Process Areas to SCRUM Practices [11]	•   Scrum does not cover all the specific practices of the project management process area. •   Organizations searching higher maturity levels are not fully attended by SCRUM practices. •   Other alternative practices are necessary to complement SCRUM and address CMMI requirements.

Jeff et al. [7] assert that scrum and CMMI combination brings adaptability and predictability. It is suggested that Lean software model can be used as an operational tool for CMMI level 5 companies to identify improvement opportunities [8].

A case study is conducted by Miller and Haddad [9] to find the challenges in a growing software company to achieve CMMI level 2 while implementing Scrum. Five things are recommended for companies who are willing to achieve CMMI with scrum implementation [9].

• •    Invest money to train a team.

• •    Ensure active participation.

• •    Maintain optimum staffing level.

• •    Facilitate access to information.

• •    Establish effective communication.

Lina and Dan [10] mention that numerous problems are encountered while applying CMMI in small and medium software development organizations. These studies are written to identify the relationship between Scrum and CMMI [11-13]. It is found that the main relationship lies in the project management process areas.

It is also reported that scrum is not fully compliant with CMMI because a weak adherence of scrum to risk management area [11-13].

• III.    The Problem Statement and The Proposed Solutuon

The main problem is to find the appropriate alternative method that can be used with Scrum to achieve CMMI requirements without losing agility.

We have to adapt the most important practice ‘risk management’ that is required by most of the methodologies in order to achieve SCRUM compatibility with CMMI. This adaptation can be achieved by including a ‘Risk Register’ component. The main benefits of the ‘risk register’ component are management of risks and improve quality of process and project. The working of ‘risk register’ component is as follows.

• A.    Risk Definition

Risk factor is a direct result of uncertainty in a software project. The two main factors, to manage risks in a software project, are:

• impact of risk (helpful/ harmful);                           • the source of the risk (internal/ external) [14].

Table 2. The main attributes of the proposed ‘Risk Register’ component

Risk description	Data identified	probability	impact	Solution/ action		owner	status	exposure	priority
Serious security flow discovered may allow hackers to breach the system security	Gaps in the security of the application	40%	5	Hiring application security expert, do extra testing for each module.		scrum owner/ team		10	5
Late in delivery of the project	Complexity in specific code / cause of another risk	25%	4	Use CBD and other extra resources		scrum team		4	4
Fire , flood, bad weather	Natural event	5%	2	Be sure to back up the project at different places, keep working from homes at the work hours		scrum master		0.2	1
Incorrect modules of the application	Unclear      / Ambiguity in requirements	20%	3	Focus on the requirements and be sure it’s right understood		scrum team		1.8	3
Customer suggest additional features	New requirements	10%	3	Add cost estimation and new delivery time		scrum owner		0.9	2
								Total ≈ 17

• B.    Risk Management

Risk management plan is developed by software development team to precede, contain and mitigate the effects of risk to a project. Each risk will be analyzed in order to understand its source, effects, probability of loss and how a team can prevent it. The management plan includes attributes such as a brief risk description, the data which identify the risk, probability of occurrence of the risk, degree of its impact, the person who manages, controls, and takes action in response to a risk, action against risk and risk status [15].

• C.    Risk Management Within Scrum

It is necessary not to lose agility of a project while integrating risk management with scrum. We propose a ‘Risk Register’ component to track and manage risks in Scrum projects. The proposed ‘Risk Register’ component will contain risk assessments corresponding to a particular sprint to monitor how many risks will be added and removed. Fig. 1 shows the functioning of the proposed ‘Risk Register’ component.

The attributes used in the proposed ‘Risk Register’ component are:

• 1)    risk description contains a brief description about the risk;

• 2)    data identified causing a risk;

• 3)    probability of a risk in percentage value (If the risk has a high percent of probability means high attention);

• 4)    impact on the project (It ranges from 1 to 5);

• 5)    way to solve a risk;

• 6)    allocate resources to handle a risk;

• 7)  status of a risk;

• 8)    exposure;

• 9)    priority high means manage first.

Fig 1. Functioning of the proposed ‘Risk Register’ component

The main attributes of the proposed ‘Risk Register’ component are shown in Table 2. The proposed ‘Risk Register’ will be used at each sprint to add suspected risks. Scrum team will use the ‘Risk Register’ component to deal with the risk before the implementation phase of a sprint. Team and ‘Scrum Master’ will review the risks using the proposed ‘Risk Register’ during sprint retrospective meeting. Table 3 shows to identify how many risks are removed during each sprint. Fig. 2 shows risk Burn-down chart that will used to represent the status of the risks. The ideal burn-down would be a linear decrease of consolidated risk exposure over the sprints [15].

Table 3. Diminishing Exposure through Sprints

Sprint	Exposure
1	17
2	15
3	10
4	7
5	3
6	0

exposure

线性

(exposure)

-5

sprints

Fig 2. Burn down charts for Table 2

Table 4. cumulative analysis of goal 1

Q. No.	Strongly disagree	Disagree	Nominal	Agree	Strongly agree
q1	2.44	2.44	24.39	65.85	4.88
q2	0	2.44	12.2	68.29	17.07
q3	0	2	19.51	65.85	12.2
q4	0	5	14.63	73.17	7.32
q5	2	19.51	17.07	31.71	29.27
q6	0	7.32	24.39	65.85	2
q7	0	9.76	12.2	31.71	46.34
q8	2	10	56.1	31.71	0
total	6.44	58.47	180.49	434.14	119.08
avera ge	0.81	7.31	22.56	54.27	14.89

60.00

50.00

с 40.00

5 30.00

У 20.00

10.00

0.00

stronglydisagreenominal agree strongly disagree likert scale agree

Fig 3. Cumulative analysis of goal 1

• IV.    Validation

Survey is used as a research design to validate the proposed solution. The survey contains 20 questions that are divided into three sections according to the three goals. Likert Scale is used ranging from 1 to 5 (strongly disagree, disagree, nominal, agree and strongly agree). The gathered data is statistically analyzed and results are displayed using frequency tables and bar charts.

• A.    Cumulative Statisical Analysis of Goal 1 (Focusing on the Risk Management Practice)

Risk management is the most practice that is required in CMMI level 3. This practice is not supported by Scrum. We integrated risk management into Scrum to achieve CMMI. The analysis of goal 1 is shown in Table 4.

We find that that 54.27% of the respondents are agreed and 14.89% are strongly agreed. While 0.81% of the respondents are strongly disagreed and 7.31% of the respondents are disagreed. 22.56% of the respondents are remained neutral. This result is displayed graphically in fig. 3.

• B.    Cumulative Statisical Analysis of Goal 2 (Considering Risk Register as the Tool which Used to Manage the Risks)

Table 5. cumulative analysis of goal 2

Q. No.	Strongly disagreed	Disagreed	Nominal	Agreed	Strongly agreed
q1	2.44	2.44	14.63	51.22	29.27
q2	0	7.32	21.95	41.46	29.27
q3	0	7.32	19.51	60.98	12.2
q4	0	4.88	9.76	30.02	46.34
q5	0	2.44	19.51	31.71	46.34
q6	2.44	7.32	36.59	26.83	26.63
q7	0	0	14.63	48.78	36.59
total	4.88	31.72	136.58	291	226.64
average	0.70	4.53	19.51	41.57	32.38

We need to use a tool to implement the risk management with scrum. We proposed ‘Risk Register’ component. The result of this goal is placed in Table 5.

Table 5 shows that 41.57% of the respondents are agreed and 32.38% of the respondents are strongly agreed with this usage. While only 4.53% of the respondents are disagreed and 0.7% of the respondents are strongly disagreed. 19.51% of the respondents are remained neutral. This result is displayed graphically in fig. 4.

• C.    Cumulative Statisical Analysis of Goal 3 (Keeping the Agility of SCRUM)

50.00 40.00 30.00 20.00 ^10.00     0.70    4.53 0.00 41.57 32.38

We proposed to use the ‘Risk Register’ component at each sprint in order to keep the agility in scrum. The result of goal is shown in Table 6.

stronglydisagreenominal disagree

agree strongly agree

likert scale

Fig 4. Cumulative analysis of goal 2

Table 6. cumulative analysis of goal 3

Q. No.	Strongly disagree	Disagree	Nominal	Agree	Strongly agree
q1	0	2.44	17.07	58.54	21.95
q2	0	7.32	19.51	48.78	24.39
q3	2.44	17.07	31.71	41.46	7.32
q4	2.44	19.51	21.95	48.78	7.32
q5	0	0	9.76	43.9	46.34
total	4.88	46.34	100	241.46	107.32
average	0.98	9.27	20.00	48.29	21.46

Table 6 shows that 48.29% of the respondents are agreed and 21.46% strongly agreed while using the proposed ‘Risk Register’ component at each sprint to keep agility in Scrum. 9.27% of the respondents are disagreed and 0.98% of the respondents are strongly disagreed. 21.46% of the respondents are nominal. The result of Table 6 is displayed graphically in fig. 5.

60.00

50.00

40.00

30.00

20.00

10.00

0.00

strongly disagree nominal agree strongly disagree agree likert scale

Fig 5. Cumulative analysis of goal 3

A final cumulative analysis of all the three goals is shown in Table 7. 70.94% of respondents are highly in favor the proposed solution, 7.94% of the respondents are disagreed and 20.69% are remained neutral. Fig. 6 shows graphical representation of the final cumulative analysis of three goals against the proposed solution.

Table 7. Final cumulative analysis of Three goals

Goals	Disagree	Nominal	Agree
Goal 1	8.1	22.56	69.14
Goal 2	5.22	19.51	73.94
Goal 3	10.23	20	69.75
Total	23.55	62.07	212.83
Average	7.85%	20.69%	70.94%

(U

disagree

20.69

nominal

agree

Fig 6. Final cumulative analysis of three goals

• V.    Conclusion

This paper is written in support of adapting Scum methodology to use with CMMI quality standard. This adaptation is achieved by proposing a ‘Risk Register’ component to cater the possible risks regarding failure of a software project. The main attributes of the proposed ‘Risk Register’ component are defined during this research. Scrum team will use the proposed component during all sprint review meetings. Survey is used as a research methodology to validate the proposed solution. The proposed solution is divided into three goals. A questionnaire is designed against three goals. Questionnaire is composed of twenty questions. The results are displayed using frequency tables and bar charts. A support of 70.94% is achieved against the proposed solution as shown in Table 7 and fig. 6. We anticipate that the proposed research will increase the chances of software companies who are willing to achieve CMMI while implementing Scrum as a software development methodology.