INF5181 – Process Improvement and Agile …...INF5181 – Process Improvement and Agile Methods in...

INF5181 – Process Improvement and Agile Methods in Systems Development

Title: Process improvement for Scrum driven development

Date: 15.11.2012

Author: Adrian Manuel Arevalo Soria

E-mail: [email protected]

Table of Contents

Table of Contents.........................................................................................................1

1 Introduction...............................................................................................................21.1 Context description.............................................................................................................21.2 Method................................................................................................................................31.3 Issues..................................................................................................................................41.4 Goals...................................................................................................................................4

2 Baseline process.........................................................................................................42.1 Elements of the baseline process.........................................................................................42.2 Descriptive model of the baseline process..........................................................................72.3 Performance of the baseline process...................................................................................9

3 Target process............................................................................................................93.1 Changes to the baseline.......................................................................................................93.2 Outline of the new Process................................................................................................11

4 Implementation of target process..........................................................................15

5 Measurement and control.......................................................................................175.1 Measurement plan.............................................................................................................185.2 Action plan........................................................................................................................20

6 Discussion.................................................................................................................206.1 Underlying rationale of proposed changes........................................................................206.2 Risks of proposed changes................................................................................................21

7 References................................................................................................................22

1 Introduction

This report presents a software process improvement plan (SPI) for a company that develops software for the health sector. To accomplish this we have 3 Purposes or objectives.

Figure 1.1 Purpose model(Solingen & Berghout, 1999, p. 21).

Figure 1.1 shows the relations between the purposes. Information about the process will give us “visibility of the current development process and the characteristics of the software products.” By doing this we can increase our understanding of the process. This causes a potential for control “by defining corrective and preventive actions”(Solingen & Berghout, 1999, p. 21) which leads to a potential for improvement. This report uses prescriptive or preventive actions to control the process.

In section 1 I will describe the context and the organizational structure, list what methods I use and issues. Section 2 describes the baseline with a graphical representation of the process. Section 3 consists of a target process, section 4 sketches out a plan for improvement and section 5 explains how measurement is to be done in this case. Finally section 6 discusses about why I introduce changes to the baseline model and risks of the target process.

1.1 Context description

This Software Process Improvement plan will focus on a company that develops software for the e-health market. One of their projects, focuses on delivering a e-journal for the public sector. It is a part of a larger solution for delivering higher quality e-health systems for the public sector.

The E-journal will contain critical information about a given patient, showing allergies, if the patient has any implants etc.

Other systems that will be working along side the e-journal are patient treatment systems, admin systems, analyse systems (radiology, biochemical, x rays, ultrasound). These system are also integrated with other systems like a IT transport systems and

2

other hospitals. This Software Process Improvement Plan (SPI) will only focus on parts of a scrum(Jeff & Schwaber, 2011) process in the development of the e-journal and how the process-related solutions can reach the defined goals in section 1.4.

The team that works on the process of developing this is composed of 14 people. Where 10 are programmers, 5 are core programmers and 5 focus on the user interface.They have one product owner and 2 IT-architects.

1.2 Method

The SPI initiative will use several methods for reaching the goals described in section 1.4. One of the main method it will use is the PROFES method; PROFES is a “methodology that helps to improve product quality by focusing process improvement on those parts of the process that have a direct effect on the customer-oriented product quality requirements of a particular organization.”(PROFES, 1999, p. 1-1).

Figure 1.2 PROFES outline (PROFES, 1999, p.3-2).

Figure 1.2 shows how the outline of the PROFES method (PROFES, 1999). The report will focus on

• Step 4: Determine current process capability• Step 5: Set product improvement goals• Step 6: Determine necessary process changes• Step 7: Describe process changes• Step 8: Set metrics for the processes and products• Step 9: Prepare improvement implementation• Step 11: Evaluate results

3

• Step 11: Update experience base.

I will also be using the Goal Question Metric (GQM) method (Solingen & Berghout, 1999). In relation to section 5, measurement and control. GQM is an method that “provides a framework for deriving measures from measurement goals.” and is used to “increase the knowledge of software organizations about their own practices and lay the quantitative foundations for improvement of software processes and products” (Morasca, 2001, pp. 243-244).

I also use the learn by doing method to implement the target process.(Bareiss & Sedano, 2012).

1.3 Issues

There are several issues that have hindered an optimal process taking place in the scrum phase. A sub-optimal implementation of SCRUM leads to a less agile and flexible process. Sprint efficiency is not high, leading to restriction within management.

The efficiency restriction is a factor in not letting the company be as competitive as it can be and limits freedom of control in management. See section 6 for a discussion on the matter.

1.4 Goals

This section is aligned with PROFES step 5 in figure 1.2 “set product improvement goals”. The goal of this SPI is to improve the quality of the software process model, this will result in improved efficiency in terms of weighted average sprint efficiency (15%). This is a process goal and should be reached after 4 projects with the target process described in section 3.

The improvement of the process can lead to a reduction in effort, less work hours can be be used to complete a similar task thus reducing cost (van Solingen , Rini . Berghout, 1999, p. 13). See section 6 for a discussion on this matter.

2 Baseline process

This section is aligned with step 4 of the PROFES methodology (PROFES, 1999, p. 3-31). The section describes an overview of the baseline process using a descriptive model of the process that is “concerned with specifying a process now used within a organisation” (Acuna, Juristo, Moreno, & Mon, 2005, p. 28). I choose to use a graphical model using a flow chart diagram in section 2.2. This shows the organizational hierarchy and execution flow in a better way than using table notations for this case.

2.1 Elements of the baseline process

4

This section is composed of different artefacts, activities and roles/methods/techniques/tools used in the baseline process.

Activities

• Requirement Specification• An activity that creates the needed requirements for the software

product. • Build requirement list

• An activity that makes a list of requirements that should be implemented in the software that is under development.

• Prioritize requirements• An activity that prioritizes requirements from the the requirement list.

Gives importance to elements of the list and prioritizes accordingly. • Prioritize tasks

• An activity that prioritizes tasks. A task is given a priority in relation to other tasks.

• Refine tasks• An activity that refines tasks into objectives which can be done in the

development phase of the process.• Effort estimation

• An activity that finds estimates for tasks. • Develop plan

• An activity that is used to plan the development phase of the process. • Development work

• An activity that is where composed of the development work of the software.

• Monitor task progress• An activity that is in charge of monitoring the progress of a given

sprint.• Sprint review

• An activity that inspects the increment, what was done in the Sprint, problems and how they where solved.

Artefacts• Collection of product needs

• A collection of needs for the product. It is a collection that is agreed upon by the customer and Product owner.

• Requirements• A document that contains the full detailed requirements for the

software and is the product of the requirement specification activity.• Requirement list

• The list of requirements for the software. This is a more short and concise document of the requirements.

• Prioritized requirements• The prioritized requirements. This is the hierarchical structure of

requirements in terms of priority.• Prioritized Tasks

5

• The prioritized tasks that are extracted from the prioritized requirements.

• Refined tasks• The tasks that are refined by the “refine tasks” activity. Prioritized

requirements are made into a tasks that can be used for effort estimation.

• Estimate• The estimate of the effort for the refined tasks.

• Plan• The action plan for a given sprint. This encapsulates how the execution

of the development of software is to be done. And has a sprint Goal.• Increment

• Is the sum of the completed requirement items in a sprint, and previous sprints.

• Task progress• Is the progress of the given tasks for a given sprint.

• Burn Down Chart• Is a chart that represents the work that is left given an amount of

time.• Review

• A document that contains the conclusion and review of the Sprint review

Roles• Product Owner

• The voice of the stakeholder and represents the customers interests and define the features of the product.

• Development Team• The development team is composed of programmers, designers and

testers. • Architect

The architect is in charge of understanding the requirements addressed by the technical design of the solution and directs the design.

• Customer

• The customer of a given product that will be developed in a given process.

Methods/tools/techniques

• Planning Poker• Consensus-based technique used for estimating tasks.

• Wiki• Used for organization and track of work.

• Eclipse• An tool IDE for programming.

• InteliJ

6

• Another IDE used for programming.• Jira

• A management tool that is used in several activities. This tool uses several plug-ins for SCRUM development.

• Maven • A tool used for building and managing a Java-based project

• Subversion• Is used for software visioning revision control and to maintain

historical versions of code.• Daily Scrum meeting

• A meeting used for synchronization of activities and for making a plan for the next day.

2.2 Descriptive model of the baseline process

The descriptive model of the process in focus is shown in figure 2.1 notation for the flow chart is in the figure. It shows the interplay of the artefacts, activities, roles and methods. The definition of notations are in the top left corner.

The customer and Product Owner agrees on a collection of product needs. These are made into requirements by the Product Owner and the Architects. They use the Jira tool to accomplish this. They then build a requirement list and prioritize the requirements. The Jira tool is used to prioritize tasks and Refine tasks, the development team carries out the two last mentioned activities. They are also in charge of the effort estimation that is done on the basis of the refined tasks.

The development plan is done by a architect and is used for the development work of software. The development is done with several tools. The output of that activity is an increment and information on task progress. To monitor the development a burn down chart is used. This activity uses Jira as a tool and is done by the development team.

If the sprint has reach its deadline a Sprint review is performed. This is done by the Product Owner, Development team and architect. When this is done the flow continues to the develop plan activity that the architect is in charge of. If it the deadline in not reached the development continues.

7

Figure 2.1 Process baseline flow chart

2.3 Performance of the baseline process

The company has hired a measuring specialist team that monitors the amount of person-hours and the amount of lines of code (LOC) that is used per sprint. It also monitors the amount of sprints that have been done in a given software development project and measure the weight of a given sprint.

The weighted average sprint efficiency is 61%.

Sprintn Delivered LOC Person-hour Weight(Importance)

Sprint1 2600 140 3

Sprint2 2000 152 4

Sprint3 3300 164 3

Sprint4 2600 128 5

Table 2.1 Data about Sprints.

The table 2.1 is an example of data from a project. It shows different sprints and respectively the delivered LOC, Weight and the amount of person-hours that where used for each sprint. It was in total 4 sprints in this dataset.

3 Target process

This section is aligned with the PROFES step 7 in the Plan phase (PROFES, 1999, p. 3-65).The section is composed of a prescriptive model that “focus on defining how the process should be enacted. ”(Acuna et al., 2005, p. 28). These are the changes to the process model that can improve the efficiency as defined in section 1.4.

3.1 Changes to the baselineThere are a number of activity changes in the target process. This section describes the new activities, new artefacts, new methods/tools/techniques , new roles, removed activities, removed artefacts and removed roles.

New activities

• Build Product Backlog.• This activity produces the Product backlog.

• Plan Sprint• This activity is where the Development Team and Product Owner

plans what will be delivered in the increment as a result of the sprint they are planning. They will also look at how the work will be done.

• Guide Development

9

• An activity where the Scrum Master guides and helps the Scrum team in terms of resolving potential issues.

• Improve Product Backlog• An activity that improves and modifies the product backlog.

• Sprint retrospective• The activity is where the Scrum team, analyse itself and creates a “plan

for improvement” that can be used in the next sprint.

New Artefacts

• Product Backlog• Is the ordered list of what is needed in the product and the source of

requirements. The Product owner is in charge of doing this activity.• Sprint Backlog

• Is a document containing selected requirements from the product backlog that are relevant for the sprint.

• Issues • Are the problems encountered in the process.

• Advice• The advice that the SCRUM Master gives to improve the process in a

SCRUM framework.• Plan for improvement

• The plan for improving the sprint and that could be done in the next sprint.

New Methods/tools/techniques

• User stories• This method is a description of requirements from the user of a system

point of view.

New Roles

• Scrum Master• Is the role that secures the insurance of improvement within the Scrum

framework.

Removed Activities• Requirement Specification.• Build Requirement list• Prioritize requirements.

Removed Roles• Architect

Removed artefacts• Requirements• Requirement list

10

• Prioritized requirements

3.2 Outline of the new process

This section shows the prescriptive changes of the target process. All the objects in the figures of this section show the old activities, artefacts, methods/tools and roles in light blue colour, the changes are in black.

Figure 3.1 Product backlog

The first change is to use a Product backlog. Figure 3.1 shows the changed activity in the beginning of the process. The Build Product backlog activity is done with Jira and the Product Owner uses user stories to create the Product Backlog

The product backlog contains an “ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. “(Jeff & Schwaber, 2011, p. 12).

This activity is replacing the “requirement specification”, “build requirements list”, and “Prioritize requirements list” activities that are in the baseline in section 2.

The dynamism of the product backlog will be described in section 6 of this report.

11

Figure 3.2 Sprint Plan.

Figure 3.2 shows how that the develop plan activity has been replaced by Plan sprint (Jeff & Schwaber, 2011). This is done by the development team and the product owner instead of only being done by the architect.

The artefact of this activity is a sprint backlog instead of a development plan. The sprint backlog contains a number of product backlog items that will be used in the sprint.

The Plan sprint activity also uses a Plan for improvement artefact that contains a plan that will improve the next sprint. This makes the Plan sprint activity more flexible. The first sprint may not use Plan for improvement. The activity that produces the plan for improvement is described further down this section.

12

Figure 3.3 Modify and improve the Product Backlog.

Figure 3.3 shows how the Improve Product Backlog activity will be added to the baseline process. If the the Development team or Product Owner decides to modify the Product Backlog based on the Sprint review they will be doing the improve Product Backlog activity which is done by the development team and the Product Owner.

The artefact that is the result of the Improve Product Backlog activity is a revised Product backlog with new or modified items (Jeff & Schwaber, 2011, p. 11).

13

Figure 3.4 Scrum guidance.

The figure 3.4 shows how the new activity, Guide development be used in the target process. The artefact Issues is the problems and issues that the team encounters in the development software activity or issues and problems that is encountered in the scrum. The Scrum Master that is responsible for the Guide development and ensures that the development follows the SCRUM framework.

14

Figure 3.5 Sprint retrospective.

The figure 3.5 describes how the sprint retrospective activity will be performed in the target process. The dotted line is used to show that other flow chart objects are that are there are not shown in this figure to show the changes in an effective manner. The activity uses the review artefact from the sprint review activity that is in the baseline. Roles that are involved is the Product Owner, Development team and the Scrum master. The duration is about 2-3 hours long depending on how long the sprint was.

It is done to identify items that where successful and find potential improvements in regards to the sprint. A plan for improvement is created as an artefact of the “Sprint Retrospective”. This plan for improvement is composed of the identified changes that should be implemented in the next sprint (Jeff & Schwaber, 2011).

4 Implementation of target process

This section is aligned with PROFES step 9: Prepare improvement implementation, “resulting in a detailed action plan for the process improvements”(PROFES, 1999, p. 3-85).

Table 4.1 describes how the target process from section 3 will implemented.

Step What When Who How

15

1 HR management February 12013

HR Hiring a Scrum Master

2 Resource allocation February 102013

Product Owner Allocate the needed resources to make the changes possible.

3 Inform about why the changes are done and a Plan for change.

February 21 2013

Product Owner, Development team, Scrum master

A meeting that informs the participants about the changes.Entry condition: step 1,2Exit condition : agreement on the Plan

4 Kick-off meeting February 272013


A meeting will start the process changes.Entry condition: step 3

5 Training in Scrum methodology.

March 1 2013

Product Owner, Development team

A training session that has the aim for SCRUM knowledge transfer

6 Documentation on Scrum methodology

March 22013


Documentation, guidelines on the new methodology.

7 Training in User Story method for requirements.

March 202013


Training session for the user story methodology.

8 Introduce Build Product Backlog activity.

April 22013

Product OwnerDevelopment team

Introducing the activity with user stories and the Jira tool. Entry condition: step 5,6,7Exit condition : Positive feedback from step 9

9 Improvement progress meeting

June 152013


A meeting about how the implementation is going.

10 Introduce Plan Sprint activity

October 152013


Introduce the activity to the process.Entry condition: step 5,6Exit condition : Positive feedback from step 11.


December 152013



12 Introduce Guide February 27 Product Owner, Introduces the guide

16

development activity and improve product backlog activity.

2014 Development team, Scrum master

activity for the process.Entry condition: step 5,6Exit condition : Positive feedback from step 13.


May 12014



14 Introduce Sprint retrospective activity.

June 192014


Introduces the sprint retrospective activity.Entry condition: step 5,6Exit condition : Positive feedback from step 15.

15 Final Improvement progress meeting

October 152014


A final meeting about how the implementation is going.

Table 4.1 Plan for implementation

The table 4.1 has 5 columns. They inform about what activity is performed, when it is performed by who and how it performed. The dates are flexible. The Implementation of the target process uses learn-by-doing principles (Bareiss & Sedano, 2012).

Due to the fact that there are quite a few activities that will be changed the plan for implementation the target process. The implementation will be iterative. One activity is implemented at a time and the personnel is given time to learn and adapt the new activities and give feedback in the progress meetings. One possible outcome of this is that the dates for implementation can be altered. The iterative plan cannot be done in a single sprint.

Resistance to change is often present when one changes a process (Solingen & Berghout, 1999, p. 36). See section 6 for a discussion on the matter.

While the baseline process used some scrum methods it is necessary to do training in the new activities.

5 Measurement and control

This section is aligned with PROFES step 10 : Implement and monitor improvements (PROFES, 1999, p. 3-93). The section describes how to measure the performance of efficiency in terms of weighted average-efficiency in respect to the goal defined in section 1.4. This sections also includes how to see if the software improvement plan is a success or a failure. I will also describe what actions to take given an outcome of the software improvement plan initiative.

I use the goal/metric/metric(GQM) method to do the measurement, GQM “represents a systematic approach for tailoring and integrating the objectives of an organization into measurement goals and their stepwise refinement into measurable values

17

(metrics)”(Hamann, Pfahl, Järvinen, & Solingen, 1998, p. 5). This method uses an object of study that is the “entity or set of entities that should be studied”. A purpose that is the “reason/type of result that should be obtained is also a central factor of the GQM method. Quality focus is the “attribute or set of attributes that should be studied”. A point of view that is a view for a person or organization for whose benefit measurement is carried out. The measurement is carried out in an environment that is the context in which the measurement is to be carried out (Morasca, 2001, p. 4).

The following properties are relevant to this case.

Analyze Sprint process.For the purpose of improvement with respect to efficiencyfrom the viewpoint of Scrum process participantsin the environment of the context described in section 1.1.

5.1 Measurement plan

This section describes how to measure efficiency in terms of average weighted sprint efficiency. The measures below uses : name, measurement unit, attribute, range and situational factors that are: by whom and who is responsible for validity.

To calculate the average sprint productivity that is a derived measure I need several base measures. A derived measure is made up from base measures.

Derived measure. Base measure. Base measure.

Name: Average Sprint efficiency Name: Sprint Code size Name: Sprint-effort

Entity : Sprint Process Entity: Software Entity: S.Process

Attribute: Efficiency Attribute: Size Attribute: Effort

Unit: LOC/Person hour Unit: LOC Unit: Person-hour

Range: [0 - ∞] Range:[0 - ∞] Range: [0 - ∞]

Base measure. Base measure.

Name: Sprint weight Name: Spring Count

Entity: Software Entity: Sprint process

Attribute: Weight Number Attribute: Sprint Number

Unit: Number Unit: Number

Range:[i-m] Range: [1....n]

18

x̄=∑

1

n

(LOC

person−hour)×wi..m

n

Formula 1. Weighted average sprint efficiency.

Formula 1 above shows how to calculate the average weighted Sprint efficiency. The Weighted average sprint efficiency is calculated by the lines of code (LOC) divided person-hour times weight w i..m per sprint. These results of a sprint is summed from from sprint 1 to sprint n and the result is divided by n.

I define LOC without counting lines of comments and blank lines. Doing this “is sensible, in a specified development environment, to define a consistent mechanism for counting LOC, so the measures collected are comparable.”(Morasca, 2001, p. 24).

Activity When By who Quality control

Prepare measurement programme

Before measurement

Test agency Test agency, Product Owner

Weighted average sprint efficiency

After 4 projects are done.

Test agency Test agency, Product Owner

Sprint Code size

At the end of every Sprint

Development team

Product Owner, Test agency

Sprint effort At the end of every work day

Development team


Sprint code weight

When the Project is delivered

Development team


Sprint Count When the Project is delivered

Development team


Data analysis and interpretation

After weighted average sprint efficiency

Test agency Product Owner, Test agency

GQM feedback sessions

Every other month

Product Owner, Test agency, Development team

Product Owner, Test agency, Development team

Table 5.1 Plan for efficiency.

Table 5.1 describes the measurement activity, when it is to be performed by who and who will do the quality control.

19

Goal Question Measure

G1 Q1 Weighted average sprint efficiency, Sprint Code size, Sprint-effort, Sprint weight, Sprint Count

Table 5.2 GQM PlanFigure 5.2 shows a the goal, question and measure where :G1: Find out what weighted average sprint productivity is in the target process.Q1: What is the weighted average sprint productivity?A1: See explanation of formula 1 above.

5.2 Action plan

There are several possible outcomes of the SPI program. This section describes a action plan for the possible outcomes and. The section is aligned with PROFES step 11: Evaluate results (PROFES, 1999, p. 3-105).

The target process is considered a successful if the weighted average sprint efficiency is improved between 8%-15% or more. If it is lower than 8% the SPI is considered a failure.

A evaluation meeting should be held where the participants can influence potential changes of the process and discuss the measures. In this meeting analysis of data and lessons learned is discussed.(PROFES, 1999, p. 3-105). A Postmortem review should be held. (Birk, Dingsøyr, & Stålhane, 2002; Dingsøyr, 2005)

If the target process is a failure the Product owner should investigate if the training was sufficient for the participants of the process and if any points from the improvement progress meetings (see table 4.1) where not taken into account in the proper way. One should after the evaluation reject or modify activities that does not integrate well according to the participants and data .

If the target process meets its goals then one should still evaluate if activities can be improved with modification. One should also document how the changes where a factor in reaching the goal. They should make a plan for reuse of the process, information that was gained should be stored and packaged in the Experience base so that it can be reused.(PROFES, 1999, p. 3-113).

6 Discussion

This section describes why the changes in section 3 where made to the baseline process and discusses potential risks of the proposed changes.

6.1 Underlying rationale of proposed changes

Although it is insisted that the baseline model is a scrum model it lacks vital agility and flexibility compared to a scrum model that is recommended in SCRUM-Guide.(Jeff & Schwaber, 2011).

20

The requirement specification was not as flexible, the architect and Product Owner was responsible for it. The fact that the development team did not have any input in the activity did decrease the agility of the process. Using a Product Backlog that the development team and and the Product owner can modify is one factor that increases the visibility of the process for the development team and gives them more freedom and control (Upender, 2005).

The same goes for the Activity of Plan Sprint. Having the development team being able to work on this with the Product Owner and modify it after a sprint retrospective creates what agile process should be in their core: “to encourage change rather than discourage it” and “creating and responding to change”, to meet the pressures of business and technology situation.(Highsmith, Consortium, & Cockburn, 2001, p. 122). An agile SCRUM process should also “rely on frequent, good quality feedback to facilitate the ability to change direction as business needs change.”(Berczuk, 2007, p. 382).

This can in sum increase the communication within the process, something that can be a factor of a successful process that uses SCRUM. (Hu, Yuan, & Zhang, 2009)

The guide activity is vital for a scrum process. This activity aids the development and ensures that it is within a SCRUM framework. Upbender (2005) states that staying agile is just as hard as becoming agile. This activity can aid and guide the participants towards an agile way of work.

The target process could have used other agile models, I choose SCRUM because the baseline process is supposed to be a SCRUM process even though it is flawed. This means less cost in training and the participants in the feedback meetings have a comparative experience they can use. The persitance with the SCRUM model is also based on the fact that a “large number of scientific publications and press releases demonstrate that organizations are adopting the Scrum software development method with success”(Sienkiewicz & Maciaszek, 2011, p. 329).

The increased efficiency gives business leverage for deciding what to do with the resources that are gained from the target process. One could use less work hours and be able to complete a similar task thus reducing cost or produce more per person-hour. Calculating this is a complex task and would go beyond the scope of this report(Rozum, 1993).

6.2 Risks of proposed changes

Using methods or activities wrongly may impact the success of the target process. This risk can be be mitigated with a meeting to asses what goes wrong and using training the weaknesses in the implementation of the methods. This will cause the maturity of the team to increase as knowledge increases.

Resistance to change to a more agile and flexible way of working can exist and pose a risk for the successfulness of the target process. This can lower team moral and restrict the knowledge transfer. To mitigate the risk one should conduct interviews and map the inhibitors to the process change and the drivers to enforce process

21

change. Then reinforce the drivers and evaluate how to reduce the inhibitors. To increase the behavioral intention to use the target process and the actual use of it (Overhage, Schlauderer, Birkmeier, & Miller, 2011).

What Sutherland and Frohman (2011) calls “Hitting the wall” might also be a potential risk. They describe this in an example where:

“Aggressive hiring plans continued to accelerate the increase in staff. Despite the growth in product development, there had been little investment put into the infrastructure and operations as required foundational support.” (Sutherland & Frohman, 2011, p. 2)

To mitigate this risk one should invest in the infrastructure when efficiency and potential productivity increases.The authors recommend the following steps: 1. Form a Scrum team to focus on infrastructure and operations. Communicate team expectations to the organization as a whole. 2. Evaluate hardware needs carefully. 3. Document existing infrastructure and operational processes. Evaluate for impediments and develop a backlog. 4. Implement a simple continuous build process. 5. Identify needs of infrastructure operations in support of a Continuous Integration vision (Sutherland & Frohman, 2011 p. 5).

Following these steps and adapt them to the situational reality could help overcome this risk

7 References

Acuna, S. T., Juristo, N., Moreno, A. M., & Mon, A. (2005). Overview of Software Process Models and Descriptive Criteria for their Analysis. A software Process Model Handbook for Incorporating People’s Capabilities.

Bareiss, R., & Sedano, T. (2012). A Gentle Introduction to Learn by Doing. 2012 IEEE 25th Conference on Software Engineering Education and Training (pp. 81–84). Ieee. doi:10.1109/CSEET.2012.32

Berczuk, S. (2007). Back to Basics : The Role of Agile Principles in Success with an  Distributed Scrum Team All Development is Local. Agile Conference (AGILE), 2007 (pp. 382–388).

Hamann, D., Pfahl, D., Järvinen, J., & Solingen, R. V. (1998). The Role of GQM in the PROFES Improvement Methodology.

Highsmith, J., Consortium, C., & Cockburn, A. (2001). Agile Software Development :  The Business of Innovation. Computer, 37(9), 120–127.

Hu, Z., Yuan, Q., & Zhang, X. (2009). Research on Agile Project Management with Scrum Method. 2009 IITA International Conference on Services Science, Management and Engineering (Vol. 3, pp. 26–29). Ieee. doi:10.1109/SSME.2009.136

22

Jeff, S., & Schwaber, K. (2011). The Scrum Guide, (October).

Morasca, S. (2001). Software measurement. Handbook of software Engineering and Knowledge Engineering - Volume 1: Fundementals (pp. pp239–276). Knowladge systems Institute, Skokie, IL.

Overhage, S., Schlauderer, S., Birkmeier, D., & Miller, J. (2011). What Makes IT Personnel Adopt Scrum? A Framework of Drivers and Inhibitors to Developer Acceptance. 2011 44th Hawaii International Conference on System Sciences, 1–10. doi:10.1109/HICSS.2011.493

PROFES. (1999). PROFES user manual. Consortium, Profes.

Rozum, J. A. (1993). Concepts on Measuring the Benefits of Software Process Improvements. Carnegie-Mellon Univ Pittsbrugh Pa Software Engineering.

Sienkiewicz, L. D., & Maciaszek, L. A. (2011). Adapting Scrum for Third Party Services and Network Organizations. Computer Science and Information Systems (FedCSIS), 2011 Federated Conference on (pp. 329–336).

Solingen, V. R., & Berghout, E. (1999). The Goal/Question/Metric Method: a practical guide for quality improvement of software development. McGraw-Hill Publishing Company.

Sutherland, J., & Frohman, R. (2011). Hitting the Wall : What to Do When High  Performing Scrum Teams Overwhelm Operations and Infrastructure. System Sciences (HICSS), 2011 44th Hawaii International Conference on System Sciences (pp. 1–6).

Upender, B. (2005). Staying Agile in Government Software Projects. Agile Conference, 2005. Proceedings (pp. 153 – 159).

23

INF5181 – Process Improvement and Agile …...INF5181 – Process Improvement and Agile Methods in...

Documents

Transcript of INF5181 – Process Improvement and Agile …...INF5181 – Process Improvement and Agile Methods in...