A Critical Evaluation of Velocity of Scrum Methodology against Traditional Software

Development Methodology

Malaka Gallage

28th January 2011

Supervised by: Chris Bates

This dissertation does NOT contain confidential material and thus can be made available to

staff and students via the library.

A dissertation submitted in partial fulfillment of the requirements of Sheffield Hallam University for

the degree of Master of Science in Enterprise Applications Development.

SRI LANKA INSTITUTE OF INFORMATION TECHNOLOGY

AND SHEFIELD HALLAM UNIVERSITY FACULTY OF ACES

ii

Acknowledgements

I like to thank participants in the survey who shared the lessons learnt throughout their IT career

with a mix of failures and success. Also I should thank to my supervisor who let me to choose this

interesting topic for my research project which adds enormous value to my career in IT project

management and for his directions to make it complete work. Finally I like to thank my wife and

daughter who let me to spend considerable time on this work sacrificing their family time.

iii

Abstract

One group may argue that software engineering is a science while other group may argue that it is

simply an art which is highly human talents dependable. If we think about software development

approaches like traditional waterfall method, we can relate it to other engineering disciplines. But

when we have a look into agile methodologies, we feel that it is somewhat closer to be an art rather a

science because there is no very strong process and definitions like we see in usual scientific

practices. On such grounds, it is important to evaluate which methodology is more reliable to give

desired results to its customers and which process is comparatively faster than other.

Hence in this research, it aims to investigate into two main development strategies such traditional

waterfall method and Scrum, an agile version to compare how efficient in delivering what customers

expect.

iv

Contents

Acknowledgements ............................................................................................................................................ ii

Abstract .............................................................................................................................................................. iii

Introduction ............................................................................................................................................... 1 1

1.1 Background ........................................................................................................................................ 1

1.2 Aims of Study .................................................................................................................................... 2

Literature Review ...................................................................................................................................... 4 2

2.1 The Waterfall Model ......................................................................................................................... 4

2.1.1 Phases ......................................................................................................................................... 4

2.1.2 Key Characteristics of Waterfall Model ................................................................................. 6

2.2 Scrum: An agile methodology ......................................................................................................... 6

2.2.1 Scrum Summery ........................................................................................................................ 7

2.2.2 Scrum Roles ............................................................................................................................... 8

2.2.3 Scrum Phases ........................................................................................................................... 10

2.2.4 Key Characteristics of Scrum Process ................................................................................. 12

2.3 What is Velocity? ............................................................................................................................. 13

2.4 Analysis of Basic Challenges .......................................................................................................... 13

2.5 Gaps in the literature leading to research question .................................................................... 14

Methodology ............................................................................................................................................ 15 3

3.1 Methodological Options ................................................................................................................ 15

3.1.1 Quantitative Research ............................................................................................................ 15

3.1.2 Qualitative Research ............................................................................................................... 16

3.2 Justification of the approach ......................................................................................................... 17

3.3 Data Collection Approach ............................................................................................................. 18

v

3.3.1 Planning and conducting interviews .................................................................................... 18

3.4 Population and Sample ................................................................................................................... 19

3.5 Expected Limitation ....................................................................................................................... 20

Findings .................................................................................................................................................... 21 4

4.1 Broad Summary of results .............................................................................................................. 21

4.2 Key findings from the interviews.................................................................................................. 22

Discussion ................................................................................................................................................ 25 5

5.1 Literature vs. Survey results ........................................................................................................... 25

5.2 Contributing factors for faster Velocity ....................................................................................... 26

Conclusions and Recommendations .................................................................................................... 28 6

6.1 The outcome of the research ......................................................................................................... 28

6.2 Recommendations ........................................................................................................................... 28

6.3 Future work ...................................................................................................................................... 28

Evaluations .............................................................................................................................................. 31 7

7.1 Actual limitations and proposed improvements of research methods used .......................... 31

7.2 Lessons learned................................................................................................................................ 31

References: ............................................................................................................................................... 32 8

Appendices .............................................................................................................................................. 34 9

9.1 Project Proposal .............................................................................................................................. 34

9.1.1 Title: Evaluate Agile Methodology (Scrum) against Conventional Software

Development Methodology for greater Velocity ............................................................................... 34

9.1.2 Problem Statement ................................................................................................................. 34

9.1.3 Discussion ................................................................................................................................ 34

9.1.4 Research Method .................................................................................................................... 35

9.1.5 Data Collection and Analysis Approach.............................................................................. 36

9.1.6 Issues of participants and Ethical Considerations ............................................................. 39

vi

9.1.7 Outcome................................................................................................................................... 39

9.1.8 References: ............................................................................................................................... 40

9.2 Summary of interview data ............................................................................................................ 40

1

Introduction 1

In the modern world, the organizations have become very competitive and depend on software

systems than ever. So delivering software for them to either sell or use in house as quickly as

possible with the lowest budget is crucial. So managing software development projects that ensures

the predictability and flexibility is also equally important.

However software development project management approaches are yet evolving as the most of

challenges which development projects face, are not addressed by the most conventional

management approaches. Demand for a different project management approach is surprisingly

increasing. However we still use the different flavors of traditional project management

methodologies which were based on waterfall methods are being widely used in the industry.

Different flavors of agile methodologies which are opposed phased development that offers in

traditional methods are being used for developing software. Fairly new agile process is Scrum and it

is also becoming popular and attracted by a wide audience.

Therefore, this thesis evaluates the scrum development process over conventional software

development approach to improve the velocity of the development while leaving the flexibility for

customer to change the requirement as required.

1.1 Background

Velocity in software development is very relative measure because the velocity has many different

definitions which will be discussed in detailed later. Velocity may be dependent on many factors as

well. So it is very important to study what would be more generic definition for velocity and then see

which methodology will provide the better velocity because time has been always one of the critical

factors in software development.

For this research, I have decided to analyze two different software development processes which are

opposed to each other fundamentally. That is traditional waterfall method and SCRUM, an agile

version. Waterfall and SCRUM methods are being discussed in the section 2.1 and 2.2 respectively.

2

1.2 Aims of Study

This research aimed to study which development process provide the better velocity. However this

may not be achievable unless following problems are understood and defined where necessary.

What is the velocity?

How do we measure the velocity?

How do we compare velocity across different methodologies?

Which method is more reliable for faster velocity?

So this study aims to define the velocity that can be considered as more general for both

methodologies under the question. Then measuring and comparing velocities will be defined. This

helps to put the experience, literature and date into the context where it can be analyzed against to

the model.

3

4

Literature Review 2

This section presents two major software development methodologies which are traditional and

agile. Agile world, there are many variations, but now Scrum is widely accepted agile process.

Therefore, literature review will focus on traditional and Scrum.

So, review of literature reveals that the core drivers of methodologies. Basically, in this research, it is

only analyzed the traditional water fall software development methodology and Scrum, an agile

software development methodology.

2.1 The Waterfall Model

The Waterfall Model is one of the earliest methods of structured system developments. It was

introduced by Dr. Royce in 1970. According to the Center for Technology in Government (1998),

although it has come under attack in recent years for being too rigid and unrealistic when it comes to

quickly meeting customer’s needs, the Waterfall Model is still widely used. It is attributed with

providing the theoretical basis for other Process Models, because it most closely resembles a

―generic‖ model for software development.

2.1.1 Phases

The Center for Technology in Government (1998) gives a good overview of each phases of the

waterfall method as follows:

5

Software

Requirement

Analysis

Program Design

Testing

Operations

System

Requirement

Figure 2-1: Traditional Software Development Life Cycle (Waterfall Model)

2.1.1.1 System Conceptualization

System Conceptualization refers to the consideration of all aspects of the targeted business function

or process, with the goals of determining how each of those aspects relates with one another, and

which aspects will be incorporated into the system.

2.1.1.2 Systems Analysis

This step refers to the gathering of system requirements, with the goal of determining how these

requirements will be accommodated in the system. Extensive communication between the customer

and the developer is essential.

2.1.1.3 System Design

Once the requirements have been collected and analyzed, it is necessary to identify in detail how the

system will be constructed to perform necessary tasks. More specifically, the System Design phase is

focused on the data requirements (what information will be processed in the system?), the software

6

construction (how will the application be constructed?), and the interface construction (what will the

system look like? What standards will be followed?).

2.1.1.4 Coding

Also known as programming, this step involves the creation of the system software. Requirements

and systems specifications from the System Design step are translated into machine readable

computer code.

2.1.1.5 Testing

As the software is created and added to the developing system, testing is performed to ensure that it

is working correctly and efficiently. Testing is generally focused on two areas: internal efficiency and

external effectiveness. The goal of external effectiveness testing is to verify that the software is

functioning according to system design, and that it is performing all necessary functions or sub-

functions. The goal of internal testing is to make sure that the computer code is efficient,

standardized, and well documented. Testing can be a labor-intensive process, due to its iterative

nature.

2.1.2 Key Characteristics of Waterfall Model

This is a phased approach where each phase has a clear start and end. A phase should be dedicated

for certain goals such design, development and so on. However the next designated phase will not

be started until the current phase is fully completed. That means no coding should start until

designing is fully completed. However it might be questionable delaying the testing until

development phase is completed is a wise decision or not. Other noticeable fact is strong project

management presence which tries to drive the team according to a pre-defined (rigid) project plan.

2.2 Scrum: An agile methodology

Scrum is one of most popular agile methodologies. It was strongly influenced by a 1986 Harvard

Business Review article on the practices associated with successful product development groups; in

this paper the term ―Scrum‖ was introduced, relating successful development to the game of Rugby

in which a self-organizing (self-managing) team moves together down the field of product

development. It was then formalized in 1993 by Ken Schwaber and Dr. Jeff Sutherland. According

to Schwaber and Sutherland (2010) Scrum is now used by companies large and small, including

7

Yahoo!, Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE, CapitalOne and the US

Federal Reserve.

In 1995, Scrum process was jointly presented by Jeff Sutherland and Ken Schwaber with the claim

that accepted philosophy for systems development is that the development process is a well

understood approach that can be planed, estimated and successfully completed which has proven

incorrect in practice. Schawber (1995) states that software development process is in general

complex and complicated. So maximum flexibility and appropriate control is required. This is

somewhat justifiable because software development is closer to product development rather product

manufacturing.

Methodology may well be the most important factor in determining the probability of success.

Methodologies that encourage and support flexibility have a high degree of tolerance for changes in

other variables. With these methodologies, the development process is regarded as unpredictable at

the onset, and control mechanisms are put in place to manage the unpredictability (Langton, 1998).

Schwaber (1995) identifies following attributes should be supported by the development process.

1. Need of an approach which enables development teams to operate adaptively within a

complex environment using imprecise process

2. Complex system developments occurs under rapidly changing circumstances

3. Producing orderly systems under chaotic circumstances requires maximum flexibility

4. The closer the development team operates to the edge of chaos, while still maintaining

order, the more competitive and useful the resulting system will be.

2.2.1 Scrum Summery

Scrum is an iterative, incremental framework for projects and product or application development.

It structures development in cycles of work called Sprints. These iterations are 1-4 weeks in length,

and take place one after the other. The Sprints are of fixed duration – they end on a specific date

whether the work has been completed or not, and are never extended. They are time boxed. At the

beginning of each Sprint, a cross-functional team selects items (customer requirements) from a

prioritized list. They commit to complete the items by the end of the Sprint. During the Sprint, the

chosen items do not change. Every day the team gathers briefly to report to each other on progress,

and update simple charts that orient them to the work remaining. At the end of the Sprint, the team

8

reviews the Sprint with stakeholders, and demonstrates what they have built. People obtain feedback

that can be incorporated in the next Sprint. Scrum emphasizes working product at the end of the

Sprint that is really ―done‖; in the case of software, this means code that is integrated, fully tested

and potentially shippable. Key roles, artifacts, and events are summarized in Figure 2-2 Scrum

Figure 2-2 Scrum in a nutshell (source http://pmtips.net/adapting-agile-methodology-startup/ )

2.2.2 Scrum Roles

There are three main roles which make thing simple. The roles are Product Owner, Scrum Master

and the team.

2.2.2.1 Product Owner

The Product Owner is responsible for maximizing return on investment (ROI) by identifying

product features, translating these into a prioritized feature list, deciding which should be at the top

of the list for the next Sprint, and continually re-prioritizing and refining the list. Product Owner

9

role is similar to the Product Manager or Product Marketing Manager position in many product

organizations. However, the Product Owner is somewhat different than a traditional Product

Manager because they actively and frequently interact with the team, personally offering the

priorities and reviewing the results each two- or four-week iteration, rather than delegating

development decisions to a project manager. It is important to note that in Scrum there is one and

only one person who serves as – and has the final authority of – Product Owner.

2.2.2.2 Scrum Master

The Scrum Master helps the product group learn and apply Scrum to achieve business value. The

Scrum Master does whatever is in their power to help the team be successful. The Scrum Master is

not the manager of the team or a project manager; instead, the Scrum Master serves the team,

protects them from outside interference, and educates and guides the Product Owner and the team

in the skillful use of Scrum.

2.2.2.3 Scrum Team

The Team builds the product that the customer is going to use: the application or website, for

example. The team in Scrum is ―cross-functional‖ – it includes all the expertise necessary to deliver

the potentially shippable product each Sprint – and it is ―self-organizing‖ (self-managing), with a

very high degree of autonomy and accountability. In Scrum, teams are self-organizing rather than

being led by a team manager or project manager. The team decides what to commit to, and how best

to accomplish that commitment; in Scrum lore, the team are known as ―Pigs‖ and everyone else in

the organization are ―Chickens‖ (which comes from a joke about a pig and a chicken deciding to

open a restaurant called ―Ham and Eggs,‖ and the pig having second thoughts because ―he would

be truly committed, but the chicken would only be involved‖).

The team in Scrum is seven plus or minus two people, and for a software product the team might

include analysts, developers, interface designers, and testers. The team develops the product and

provides ideas to the Product Owner about how to make the product great. In Scrum, the team

should be 100 percent dedicated to the work for one product during the Sprint; avoid multitasking

across multiple products or projects. Stable teams are associated with higher productivity, so avoid

changing team members. Application groups with many people are organized into multiple Scrum

teams, each focused on different features for the product, with close coordination of their efforts.

10

Since one team does all the work (planning, analysis, programming, and test) for a complete

customer-centric feature, Scrum teams are also known as feature teams.

2.2.3 Scrum Phases

The Scrum process is phased into four as Planning, Architecture, Development Sprints and finally

Closure (Schwaber 1998).

2.2.3.1 Planning

Planning phase is used to define of a new release based on currently known backlog, along with an

estimate of its schedule and cost. If a new system is being developed, this phase consists of both

conceptualization and analysis. If an existing system is being enhanced, this phase consists of limited

analysis.

Planning steps are given below:

Development of a comprehensive backlog list.

Definition of the delivery date and functionality of one or more releases.

Selection of the release most appropriate for immediate development.

Mapping of product packets (objects) for backlog items in the selected release.

Definition of project team(s) for the building of the new release.

Assessment of risk and appropriate risk controls.

Review and possible adjustment of backlog items and packets.

Validation or reselection of development tools and infrastructure.

Estimation of release cost, including development, collateral material, marketing, training,

and rollout.

Verification of management approval and funding

2.2.3.2 Architecture

Architecture phase, as usual, designs how the backlog items will be implemented. This phase

includes system architecture modification and high level design.

Steps in the architecture phase are:

Review assigned backlog items.

11

Identify changes necessary to implement backlog items.

Perform domain analysis to the extent required to build, enhance, or update the domain

models to reflect the new system context and requirements.

Refine the system architecture to support the new context and requirements.

Identify any problems or issues in developing or implementing the changes

Design review meeting, each team presenting approach and changes to implement each

backlog item. Reassign changes as required.

2.2.3.3 Development Sprints

The Development phase is an iterative cycle of development work. The management determines

that time, competition, quality, or functionality is met, iterations are completed and the closure phase

occurs. This approach is also known as Concurrent Engineering. Development consists of the

following macro processes:

Meeting with teams to review release plans.

Distribution, review and adjustment of the standards with which the product will conform.

Iterative Sprints, until the product is deemed ready for distribution.

A Sprint is a set of development activities conducted over a pre-defined period, usually one to four

weeks. The interval is based on product complexity, risk assessment, and degree of oversight

desired. Sprint speed and intensity are driven by the selected duration of the Sprint. Risk is assessed

continuously and adequate risk controls and responses put in place. Each Sprint consists of one or

more teams performing the following:

Develop: Defining changes needed for the implementation of backlog requirements into

packets, opening the packets, performing domain analysis, designing, developing,

implementing, testing, and documenting the changes. Development consists of the micro

process of discovery, invention, and implementation.

Wrap: Closing the packets, creating an executable version of changes and how they

implement backlog requirements.

Review: All teams meeting to present work and review progress, raising and resolving issues

and problems, adding new backlog items. Risk is reviewed and appropriate responses

defined.

12

Adjust: Consolidating the information gathered from the review meeting into affected

packets, including different look and feel and new properties.

Each Sprint is followed by a review, whose characteristics are:

The whole team and product management are present and participate.

The review can include customers, sales, marketing and others.

Review covers functional, executable systems that encompass the objects assigned to that

team and include the changes made to implement the backlog items.

The way backlog items are implemented by changes may be changed based on the review.

New backlog items may be introduced and assigned to teams as part of the review, changing

the content and direction of deliverables.

The time of the next review is determined based on progress and complexity. The Sprints

usually have a duration of 1 to 4 weeks

2.2.4 Key Characteristics of Scrum Process

Main characteristics of Scrum process can be identified as follows:

The first and last phases (Planning and Closure) consist of defined processes, where all

processes, inputs and outputs are well defined. The knowledge of how to do these processes

is explicit. The flow is linear, with some iteration in the planning phase.

The Sprint phase is an empirical process. Many of the processes in the sprint phase are

unidentified or uncontrolled. It is treated as a black box that requires external controls.

Accordingly, controls including risk managements are put on each iterations of the Sprint

phase to avoid chaos while maximizing flexibility.

Sprints are nonlinear and flexible. Where available, explicit process knowledge is used;

otherwise tacit knowledge and trial and error is used to build process knowledge. Sprints are

used to evolve the final product.

The project is open to the environment until the Closure phase. The deliverable can be

changed at any time during the Planning and Sprint phases of the project. The project

remains open to environmental complexity, including competitive, time, quality, and

financial pressures, throughout these phases.

13

The deliverable is determined during the project based on the environment

2.3 What is Velocity?

Schwaber and Sutherland (2010) define, the number of features that can be delivered at the end of a

Sprint is known as the team’s ―velocity‖. The features means, the actual functionality of the product

which add value to the product. For example, placing an order or approving a request can be

identified as a feature. The features are also known as story points.

The question is, whether the same ―velocity‖ can be used to measure the performance of non-agile

software development projects. Generally it looks like the velocity is somewhat subjective rather

objective to use as measuring units. When we take the development process out from the customer’s

perspective, what she wants is a product with certain functionalities. Where the functionalities can

be delivered comparatively faster, we can say velocity is high. In that sense, the ―velocity‖ can be

used as a measurement for measuring productivity of development for non-agile project as well.

Therefore, same definition can be treated as a fair definition for velocity.

2.4 Analysis of Basic Challenges

Fundamental fact in scrum is that ―self-organizing‖ in the best way to tackle the problems on the fly.

By contrast, waterfall method encourages organizing everything in early stages. But the question

begins as the team moves forward with the plan due to following basic reasons:

Requirement changes

Design issues (scalability and expandability)

Testing finds critical defects that require design changes

At the point of final acceptance, there are discrepancies

If requirements change in the middle, what waterfall recommends is to revisit previous phases and

start supporting new requirements. But in scrum, the changes will be absorbed into the development

in the best way team thinks.

14

Scrum usually relies on adding features while revisiting all phases within a sprint. This helps to scale

the design as required. But it may be limited. So in waterfall, it gives ample of time initially to come

up with a design that is scalable and expandable since it is mostly a top down approach.

Testing is very important, but waterfall defers it till the end while scrum relies on testing always.

Therefore, scrum has distinctive advantaged over waterfall by detecting and fixing defects while

coding.

Finally according to waterfall process, product will be handed over to the customers (users) at the

end. But scrum suggests to share the product being developed with one constrain. That is whatever

the functionality built on should be working at any given point. This helps the user to have an early

view on the product and add or modify features as they require.

2.5 Gaps in the literature leading to research question

The literature usually discusses about the contrast between agile and waterfall and why waterfall fails.

But it doesn’t clearly specify why agile is being successful. Other area which is lacking is how we

compare velocities and which one offers better velocity which is the main goal of this thesis.

15

Methodology 3

In the following section, the available research methodologies will be discussed

3.1 Methodological Options

Mainly two options are available as quantitative and qualitative which will be discussed in detail in

following sections.

3.1.1 Quantitative Research

According to Williams (2007), quantitative research which emerged around 1250 A.D. was driven by

investigators with the need to quantify data. Since then quantitative research has dominated the

western cultural as the research method to create meaning and new knowledge.

Williams (2007) clearly states, the research itself is independent of the researcher. Therefore, data is

used to objectively measure reality. Quantitative research creates meaning through objectivity

uncovered in the collected data. Quantitative research can be used in response to relational questions

of variables within the research. ―Quantitative researchers seek explanations and predictions that will

generate to other persons and places. The intention is to establish, confirm, or validate relationships

and to develop generalizations that contribute to theory‖ (Leedy and Ormrod, 2001, p. 102).

Quantitative research begins with a problem statement and involves the formation of a hypothesis, a

literature review, and a quantitative data analysis. The findings from quantitative research can be

predictive, explanatory, and confirming.

Research methodology is defined by Leedy & Ormrod (2001) as ―the general approach the

researcher takes in carrying out the research project‖ (p. 14). Quantitative research involves the

collection of data so that information can be quantified and subjected to statistical treatment in

order to support or refute ―alternate knowledge claims‖ (Creswell, 2003, p. 153). Creswell, (2002)

asserts that quantitative research originated in the physical sciences, particularly in chemistry and

physics. The researcher uses mathematical models as the methodology of data analysis. Three

historical trends pertaining to quantitative research include research design, test and measurement

procedures, and statistical analysis. Quantitative research also involves data collection that is typically

numeric and the researcher tends to use mathematical models as the methodology of data analysis.

Additionally, the researcher uses the inquiry methods to ensure alignment with statistical data

16

collection methodology. There are three broad classifications of quantitative research: descriptive

experimental and causal comparative (Leedy and Ormrod, 2001). The descriptive research approach

is a basic research method that examines the situation, as it exists in its current state. Descriptive

research involves identification of attributes of a particular phenomenon based on an observational

basis, or the exploration of correlation between two or more phenomena. During the experimental

research, the researcher investigates the treatment of an intervention into the study group and then

measures the outcomes of the treatment. There are three types of exploratory approaches: pre-

experimental, true experimental, and quasi-experimental (Leedy & Ormrod). The pre-experimental

design involves an independent variable that does not vary or a control group that is not randomly

selected. Campbell and Stanley (1963) endorsed the true experimental design, which provides a

higher degree of control in the experiment and produces a higher degree of validity. The true

experimental designs result in a systemic approach to quantitative data collection involving

mathematical models in the analyses. Whereas, the quasi-experimental design involves nonrandom

selection of study participants. Therefore, control is limited and true experimentation is not possible.

Since the variable cannot be controlled, validity may be sacrificed. In the causal comparative

research, the researcher examines how the independent variables re affected by the dependent

variables and involves cause and effect relationships between the variables. The factorial design

focuses on two or more categories with the independent variables as compared to the dependent

variable (Vogt, 1999). The causal comparative research design provides the researcher the

opportunity to examine the interaction between independent variables and their influence on

dependent variables.

3.1.2 Qualitative Research

According to Williams (2007), qualitative research is a holistic approach that involves discovery.

Qualitative research is also described as an unfolding model that occurs in a natural setting that

enables the researcher to develop a level of detail from high involvement in the actual experiences.

Key identification of a qualitative research is the social phenomenon being investigated from the

participant’s viewpoint. Qualitative research involves purposeful use for describing, explaining, and

interpreting collected data. Qualitative research can also be described as an effective model that

occurs in a natural setting that enables the researcher to develop a level of detail from being highly

involved in the actual experiences (Creswell, 2003). Qualitative research is conducted within a

poststructuralist paradigm. There are five areas of qualitative research: case study, ethnography

17

study, phenomenological study, grounded theory study, and content analysis. These five areas are

representative of research that is built upon inductive reasoning and associated methodologies.

Opposed to quantitative approach, the qualitative research is based on inductive, rather than

deductive reasoning. It is from the observational elements that pose questions that the researcher

attempts to explain. The strong correlation between the observer and the data is a marked difference

from quantitative research, where the researcher is strictly outside of the phenomena being

investigated (Williams 2007). This empirical research is data collected from the senses and is used to

explain phenomena relevant to social behaviors in new and emerging theories. In addition to the

distinct differences between quantitative and qualitative research designs, notable differences have

also been identified in each respective research methodology. The following sections will briefly

describe the qualitative research methodology.

3.2 Justification of the approach

In software project management, five independent variables can be identified (Wysocky 2006) as

follows:

1. Characteristics of software project itself

2. Software Development life cycle

3. Profiles of the project team

4. Project Management Life Cycle

5. The technology that support the whole

But biggest challenge is all these variables are not purely absolute, so establishing fair measuring

units is almost impossible. That means collecting quantitative data is not practical unless projects

were executed in controlled environments. But there are lots of practical constraints to run the

project in controlled environments. On the other hand, human interaction is too high, it is

doubtful that studies in controlled environment will reflect the real life cases.

One of critical factor for IT projects to be success is human behavior which includes clients,

users, stakeholders, development and quality assurances teams and the project leadership. IT

project management heavily involves in human resource management and collaboration than

anything else. Therefore, in such situations, qualitative approach is known to provide more

practical results compared to quantitative approaches. Therefore, qualitative research approach is

18

mainly used. Interviews which are based on open ended questions are conducted to collect the

data which will be analyzed and compare with the literature being reviewed.

3.3 Data Collection Approach

Individual semi-structured interviews will be used to collect the qualitative data. Semi-structured

interviews have following characteristics (Lancaster, 2005). The questioning centers about the

researcher taking a respondent through predetermined issues and topics, but not in a rigid manner

or necessarily in a rigid order. The difference between this type of questioning technique and

conversations is, of course, the fact that the topics and issues to be covered are largely determined in

advance as are the individuals whom the researcher intends to interview. Normally, interviews of this

type will not involve the use of a pre-prepared interview schedule and certainly rarely will a

questionnaire be used. The semi-structured individual interview is designed to be focused in terms

of topics covered and yet flexible in that it is possible and often desirable to steer questions into

areas that appear promising from the point of view of providing rich data and/or additional insights.

A second major difference between this approach to interviewing and the conversational/story

telling approach is that respondents will, of course, be aware that they are being interviewed and

questioned, a fact that needs to be taken account of, in both the design and the interpretation of

questions and answers.

3.3.1 Planning and conducting interviews

According to Lancaster (2005), the precise steps in planning and conducting interviews will vary

according to, for example, the type of interview being conducted including the sorts of data being

collected, the circumstances of the interview, whether or not the interviewer is from inside the

organization or is external to it, and so on.

However, there are a number of key steps and considerations in planning and conducting interviews

that are common to virtually all interview methods of collecting data (Lancaster 2005). These are as

follows:

Determine data objectives and topics for discussion:

19

The objective of the interviews is to understand the development methodology is being

followed by the interviewee and gauge the overall productivity relative his or her experience.

Identifying and approaching interviewees:

Interviewees will carefully be selected based on their experience, technical and domain

diversity. Regarding the experience, at least interviewee should have more than five years

industrial experience in software development. However it is not considered whether they

worked as managers/leads or not, because development team might have different views

than the management. So it is expected to have a mix of interviewees, technical and non-

technical (management).

Permission: In some circumstances permission to approach and interview respondents will

be required. Obviously, it is important to secure any needed permissions in advance. It is

important to note that simply obtaining permission may not mean that respondents will

automatically comply and/or be willing to disclose information to an interviewer.

Arranging interviews: Assuming permission has been granted and respondents have

indicated that they are willing to be interviewed; the interviewer can then make the necessary

arrangements. This will involve determining the time and venue for the interview and may,

in some circumstances, include an indication to the respondent of the topics to be covered.

Obviously in the case of conversational and unstructured interviews, some of these

considerations may not apply.

Conducting the interviews: Again, depending on the type of interview, the circumstances,

and so on, a variety of approaches can be taken to actually conducting the interviews.

However, in general terms it is important to quickly put the respondent(s) at ease and to

establish a rapport between interviewer and interviewee. Any equipment being used to

record or take notes of the interview should be kept as discreet as possible so as not to put

the interviewee off. In most circumstances it is preferable, and certainly more ethical, to

reveal to respondents how the interview data is being recorded.

3.4 Population and Sample

Twenty individuals were initially identified for interviews based on the criteria as specified in the

section 3.3.1. However only sixteen out of twenty were interviewed finally and the rest were not able

20

to be interviewed due to practicalities and other concerns. The population can be grouped into three

based on their exposure to development methodologies.

Group1: Exposure to traditional software development methodologies only

Group2: Exposure to traditional and agile development methodologies

Group3: Exposure to agile development methodologies only

Group Participants

Group A 5

Group B 8

Group C 3

Table 1 Participants Groups

3.5 Expected Limitation

Participants were limited and they are mainly representing three Sri Lankan software development

companies. Therefore, there can be a biased to certain methodologies to which their companies

practiced. They were also from outsourced development teams (in Sri Lanka) which cater for US

and European clients. So they might be indirectly influenced by their counter parts.

Since participants were from outsourced teams, they may be influenced by the pros and cons which

are directly related to outsourced software development rather generic product development.

21

Findings 4

4.1 Broad Summary of results

Interviews were mainly around two subjects.

Fundamental strengths and weaknesses of Development Processes

How to avoid delays in delivering what customer expect

Group B & C responded almost similar way to the questions while Group A showed that they are

relying on the traditional process with some improvements such as short term reviews and flexible

project plans.

Group B & C stated that Scrum can align with customer/user expectation always as they participate

in Sprint reviews and give the feedback. Therefore, chances of redesigning and constructing of the

modules or whole system are comparatively low. Usually customers are satisfied with the outcome.

Other benefit that they highlighted was, backlog prioritization at the sprint planning which happen

within four weeks maximum. This helps to develop most of critical tasks and depended as early as

possible and some ―nice to have‖ features will be pushed back. So delivering critical functionality is

always met in advance.

Group A is however suspicious about the outcome if customer interaction is high during the

construction phase. One reason they highlighted, as a result of close interaction with customer, they

have to absorb changes to the design and functionality which were not anticipated initially. That

would result in a delaying the final product. Other option that they have is, re-plan and re-negotiate

the agreements with the customer on the deliverables though it will have very high overheads.

Group B generally shows that they prefer agile process over traditional rigid processes because it is

flexible and simple. Therefore it can deliver fast.

Group C didn’t have much voice about comparison with traditional process. But Group C prefers

agile due to its flexibility.

Group B & C stated that it is easy to start a project without having all the information upfront and

that is case for most of software development projects. Then moving forward, new features can be

22

absorbed without having much impact because it is always possible to consider them as the next

sprint planning.

More generalized summery of the interview data can be given as follows.

Customer interaction is required throughout the development phase to make sure that

feature are meeting real needs

For the projects that employs traditional development process, close customer interaction

might lead change of requirement time to time while product is being constructed

Scrum process can respond to changes more successfully than traditional. This includes

changes due to industry trends and other factors such financial and strategic.

Peer pressure in Scrum helps to improve individual productivity

Short iterations are accurate and productive

Small teams can be managed more efficiently

Team adaptability to new technologies and domains

Interviewer’s responses were different when the question was ―Will Scrum gives a better velocity?

―According to the interview data, following reasons have been identified by the participants for the

failure or partial delivery of a project.

1. Limited visibility and rigid plans that based on the initial visibility created a chaos.

2. User( or customer) interaction is minimal in the development phase

3. Resource turns over in the middle of the project.

4. Weak or unskilled project management.

5. Slow response to the new findings

4.2 Key findings from the interviews

Group A stated that close interaction with customer might distract the its original goals but Group B

& C, sees that will be an advantage to deliver desired result early as possible. Participants from all

three groups stated that customer interaction throughout the execution of the project is very import.

23

According to participants, although the requirement specification serves purpose of being as formal

agreement, it does not explicitly expect customer expectation upfront. Other important reason is, in

the middle, customer understands that the requirement given by him or her is wrong later. So taking

immediate corrective measure will help to get the project on track. Scrum teams (Group B&C)

expressed that they experience these kinds of scenarios often, but project can still continue adapting

to changes requested. Group A, stated that it might lead number of complication as the requirement

being changed. Worse case, project will be suspended temporarily if not permanently until re-

estimation and re-negotiation complete. This means traditional development process might fail to

respond to the changes during the execution of the process thought it is really important.

Other important finding from the interviews is the actual peer pressure on the individuals in Scrum

process. This means daily scrum meetings suppose every team member to give an update on the

status of each item. So this helps to keep the productivity up because individuals themselves

responsible for each other to achieve sprint goals as a team. Therefore, each team member has to

make their contribution to the scrum at a competitive level. But in case of traditional, according to

interviews, it is expected to move forward according to the project plan which is most of the time

does not reflect the actual work load. This often leads for the team being slightly out of sync with

the project plan. Hence project managers may rely on the data which does not reflect the actual

status.

Both Groups (B&C) highlighted that small iteration in Scrum followed by the feedback cycle helps

being productive and align with customer (product owner) expectation. In the traditional

development there is no such and most of the planning and designing works are completed early

phase of the project. However Group A admitted that it is not practical to do an accurate planning

and designing at the beginning for most of the project when the requirements are complicated,

domain is new and experience of the team on that specific technologies and domain is limited. So

such projects, Group B expressed more confident on Scrum process achieving its goal faster.

It is important to analyze key problems that affect the velocity of a project. Those are:

1. Clarity of requirements

2. Quality of architecture and design

3. Domain knowledge

4. Planning and estimation.

24

5. Team Productivity

Areas that are interested,

Productivity

Ability to respond efficiently for requirement change

Minimize the impact due to low granularity in requirements

Continuous customer involvement

Team skills set

25

Discussion 5

In the previous section, interview results were discussed. So following section dedicates to analyze

interview data together with literature. This gives an opportunity to see how far the main goals of

the project have been reached.

5.1 Literature vs. Survey results

Schwaber (1995) summarized the Scrum characteristics with other methodologies. However the

comparison between waterfall and scrum is extracted for the simplicity and stay within the scope of

the project

Waterfall Scrum

Defined Process Required Planning & Closure only

Final Product Determine during planning Set during project

Completion Date Determine during planning Set during project

Responsiveness to

Environment

Planning only Throughout

Team Flexibility and Creativity Limited - cookbook approach Unlimited during iterations

Knowledge Transfer Training prior to project Team work during project

Probability of Success Low High

Table 2: Methodology Comparison (source Schwaber 1995)

Participants clearly indicated responsiveness to the environment is high in Scrum process over

waterfall. All groups participated in the interviews admitted that responsiveness to the environment

is very critical delivering the final product successfully. So it is clear Scrum is geared to deliver the

product which is actually usable and address the needs of users/customers. The water is clearly

lacking in that aspect as it doesn’t encourage this.

Regarding the need of a defined process, the responses from the survey is mixed. For example,

Group A indicated that requirements are well known, dependencies are already identified and team

has domain and technical knowledge, then a defined process may deliver the good results quicker.

26

According to the interview data, there is no clear indication which process offer smooth knowledge

transfer activities.

Probability of success is most important factor here when it comes to delivering the product while

achieving a high velocity. Group A indicated that success is sometimes question at the end of the

project and it is not so rare. But surprising Group B & C stated that usually product is being

developed by adding features in short iterations followed by a review which result in a success.

5.2 Contributing factors for faster Velocity

One of important findings is, although traditional process encourage phased approach where

planning should be done upfront even though visibility is limited initially. So participants accepted

that progressing based on inaccurate plans, designs and estimate leads to disastrous situations later.

In other words, take long time (slow velocity) to deliver the desired product. However, interview

data shows that Scrum can handle such situation successfully without leading to a disastrous

situation. Reason as they mentioned, once project has started, it’s up to the team and stakeholders to

choose the best way to proceed.

Other important driving factor in Scrum is customer (Product Owner) interaction throughout the

project. Many responded that short iterations called as sprint followed by the review, will help to

establish a smooth feedback loop with customer. Some of the participants stated that this further

helps to build good understanding between the customer and the team which turns into more

realistic planning and decision making. Therefore, it helps to reach other goals faster and use best

solutions based on priorities.

Third important finding is the effectiveness of the peer pressure. Traditional process, peer pressure

is not much influential because the strong presence of the project management. Surprisingly in the

scrum process, scrum master plays kind of a supportive role that removes the obstacles and being as

a resource person for scrum meetings etc. Ideally it is the team who drives the scrum. That means,

team is very autonomous and presence of management is not so strong. So what drives the team? It

is the peer pressure. Most of the participant from Group B&C expressed that it is very effective in

improving the overall team’s productivity.

27

The forth finding is, for the software development project where team and stakeholders have all the

expertise including technical and domain knowledge, traditional development practice will

outperform over agile processes. This means, if the team has previous experience on similar

projects, they can estimate and plan accurately. This helps the project management to manage the

project properly till the product is delivered.

28

Conclusions and Recommendations 6

This section summarizes the finding of the research and the recommendations.

6.1 The outcome of the research

The research question is whether use of scrum as the development process will have faster velocity

of product development than the traditional process. Actually there were evidence based on the

interview data and literature that Scrum has a potential improve the velocity based on the nature of

the project. As the out of the research, the recommendations are given in the following section.

6.2 Recommendations

Primary finding of this research is scrum can be used to achieve a faster velocity compared to

traditional process for the projects that have following characteristics.

Complex and unclear requirements

Requirements are highly volatile

The vision is clear, but not the end product

Project sponsor (customer) should be able to be guide the team on the expectations (sprint

reviews, back log prioritization)

Secondary finding is projects that have following characteristics may be driven using traditional (or

more structured) method to achieve results faster and efficiently.

Requirements are fixed and well known

Final product can be defined clearly and prototypes can be evaluated with users

Clear requirements and previous exposure to similar project

Estimates are very accurate due to previous experience on similar work

Designs are straight forward due to previous experience

6.3 Future work

It is interesting to look in to this subject further because ―Will scrum give a better velocity?‖ is a

really valuable question for the customers and software professionals when they making a big

29

investment for building new products. This research aimed to take a little step to evaluate the facts

qualitatively. However my belief is there should be quantitative researches as well on the same topic.

Once there are enough specific research about this subject, the professionals can rely on the agile as

well as traditional flavors of project management methodologies depending on certain deciding

factors. That will help the IT industry in two ways:

Organizations may rely on agile methodologies to get their software produced developed

than now (for example, most of organizations still rely on fixed cost & time contract for

large scale complex software development projects)

Utilize traditional methodologies where it can outperform agile.

30

Further refine Scrum and other agile methods

Therefore, researches on evaluating velocities of the methodologies need to be increased and those

researches should try to use more statistical data to build a strong foundation for the community

accepts agile methodologies as a proven practice.

31

Evaluations 7

7.1 Actual limitations and proposed improvements of research methods used

Even though generally qualitative approaches don’t require large sample, Group C participants are

not very satisfactory as their exposure to IT industry is limited compared to the rest. I expected they

would be able to provide more critical feedback on the scrum process.

7.2 Lessons learned

In addition to the main research outcome of the research which is the evaluation of velocity, I

learned few more important lessons as well.

Scrum process is rich in certain areas than we think. Especially the psychological impact and

boosting team work while creating competitive development environment is achieved seamlessly.

Also where creativeness matters, scrum is a good solution because it has more attractive features like

flexibility, being informal, which are closer to developer’s natural instincts. This means developers

are encouraged to focus on product development by minimizing the ―process‖ overhead.

Other important lesson that I learned from the survey that it is difficult to reach contractual

agreements with most of the customers (project sponsors) who used to fixed cost models. The

traditional process gives a clear picture about the cost and time estimates initially. That is another

important aspect though it is not always possible to give accurate values due to various reasons.

32

References: 8

1. A Center for Technology in Government (1998), University at Albany, A Survey on

System Development Process Models, last accessed on 10th august, 2010 at

http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.

pdf

2. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,

Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R.,

Mellor, S., Schwaber, K., Sutherland, J. and Thomas, D. (2001). Manifesto for Agile

Software Development., last accessed on 7th August 2009 at http://AgileManifesto.org

3. Brewerton, P., Millward, L., (2001), Organizational Research Methods: A Guide for

Students and Researchers, Sage Publications.

4. Creswell, J. W. (1998). Qualitative inquiry and research design: Choosing among five

traditions. Thousand Oaks, CA: SAGE Publications.

5. Fairley, R, E., Managing and Leading Software Project, John Wiley & Sons, Inc.,

Hoboken, New Jersey(2009).

6. Lancaster, G., Research Methods in Management, Elsevier Butterworth-Heinemann,

Massachusetts (2005).

7. Langton, Christopher. Artificial Life. In Artificial Life, Volume VI: SFI Studies in the

Sciences of Complexity (Ed. C. Langton) Addison-Wesley, 1988

8. Larman, C., 2003, Agile and Iterative Development: A Manager's Guide, Addison

Wesley.

9. Leedy, P. & Ormrod, J. (2001). Practical research: Planning and design (7th ed.). Upper Saddle

River, NJ: Merrill Prentice Hall. Thousand Oaks: SAGE Publications.

10. Patton, M, Q., 2002, Qualitative Research and Evaluation Methods, 3ed, Sage

Publication.

11. Royce, W, W,. Managing the development of large software systems last accessed on 7th

August 2010 at http://www.valucon.de/documents/managing_softwareprojects.pdf

12. Schwaber, K., Scrum Development Process (1995), Advanced Development Methods,

last accessed on 7th August 2010 http://jeffsutherland.com/oopsla/schwapub.pdf

13. Schwaber, K., Sutherland, J., Scrum Papers, May 2010

http://jeffsutherland.com/ScrumPapers.pdf

33

14. Williams, C. (2007). Research Methods, Grand Canyon University last accessed on 7th

August 2010 at http://www.cluteinstitute-onlinejournals.com/PDFs/200768.pdf

15. Wysocki, R, K., (2006) Effective Software Management, Wiley Publishing Inc., USA

34

Appendices 9

9.1 Project Proposal

9.1.1 Title: Evaluate Agile Methodology (Scrum) against Conventional Software

Development Methodology for greater Velocity

9.1.2 Problem Statement

In the modern world, the organizations have become very competitive and depend on software

systems than ever. So delivering software for them to either market them or use in house as quickly

as possible with a lower budget is crucial. So managing software development projects that ensure

the predictability and flexibility is very important.

However software development project management approaches are yet evolving as the most of

challenges which development projects face, are not addressed by the most conventional

management approaches. Demand for a different project management approach is surprisingly

increasing.

Therefore, the aim of proposed research is to identify the effect of use of agile development

approach over conventional software development approach to significantly reduce the

development duration while leaving the flexibility for customer to change the requirement as

required.

9.1.3 Discussion

Is software development kind of usual product manufacturing or new product development? Most

software is not a predictable or mass manufacturing problem. Software development is new product

devepment (Larman 2003). Becasuse requirments for software is often going to be a function of

time and space. For example, requirements of a software which is for currenrt Sri Lankan market

may be different from the same for UK market because perhaps the cost which is related to the

return on investment (ROI), customizable features etc., may be more demarding here rather than

non functional requirements such scalability etc., On the other hand , development team may not

35

have the same experience that requires for the project. Thus again, even the software is not much

new thing for the industry, is still challenging for the development team. After all, software

development as new product developments, the main critical factor is the specification for the

software being developed. But following basic challenges have to be adressed (Larman 2003):

The clients or users are not sure what they want.

They have difficulty stating all they want and know.

Many details of what they want will only be revealed during development.

The details are overwhelmingly complex for people.

As they see the product develop, they change their minds.

External forces (such as a competitor's product or service) lead to changes or enhancements

in requests.

This deep appreciation—that building software is complex, new product development with high

change rates, and not predictable manufacturing—is at the heart of the motivation for agile and

iterative methods. According to agile principles (Beck 2001), its highest priority is to satisfy the

customer through early and continuous delivery of valuable software. In contrast, traditional

approach promises to deliver software on time within the plan budget.

Agile development methods claim that it can reduce the time-to-deliver because the agile

methodology removes certain problems (overheads) in traditional development. One of its design

goals was to address the issue found in new product development, where conventional approach

biased towards product manufacturing. It is very important to note that time-to-deliver means the

actual duration had taken to deliver the product which met the client expectations, thus gives the

real value to the customer, but not what has been agreed as in traditional projects. In traditional

projects, what has been agreed might be changed during the course of the project and then the

duration should be calculated as the entire duration for the final delivery.

9.1.4 Research Method

In software project management, five independent variables can be identified (Wysocky 2006) as

follows:

36

Characteristics of software project itself

Software Development life cycle

Profiles of the project team

Project Management Life Cycle

The technology that support the whole

But biggest challenge is all these variables are note purely absolute, so establishing fair measuring

units is almost impossible. That means collecting quantitative data is not practical unless projects

were executed in controlled environments. On the other hand, it is not possible to run the project in

controlled environments. Due to these reasons, I have to give up the idea of experimental &

quantitative research approach.

One of critical factor for IT projects to be success is human behavior which includes client, user,

stakeholder, development and quality assurances teams and the project leadership. IT project

management heavily involves in human resource management and collaboration than anything

else. Therefore, in such situations, qualitative approach is known to provide more practical results

compared to quantitative approaches. Therefore, qualitative research approach is selected.

Experiments will be type of quasi-experiments because

1. It is required to observe in real life projects

2. Not possible to have experimental development projects due to the cost factors

9.1.5 Data Collection and Analysis Approach

Data Collection Approach:

In a qualitative research, there is a flexibility to adapt to different ways of data collection. For

example, following data collection approaches are available (Patton 2002):

Interviews: Open-ended questions and probes yield in-depth responses about people's

experiences, perceptions, opinions, feelings, and knowledge. Data consist of verbatim

quotations with sufficient context to be interpretable.

Observations: Fieldwork descriptions of activities, behaviors, actions, conversations,

interpersonal interactions, organizational or community processes, or any other aspect of

37

observable human experience. Data consist of field notes: rich, detailed descriptions,

including the context within which the observations were made.

Documents: Written materials and other documents from organizational, clinical, or

programs records; memoranda and correspondence; official publications and reports;

personal diaries, letters, artistic works, photographs, and memorabilia; and written responses

to open-ended surveys. Data consist of excerpts from documents captured in a way that

records and preserves context.

Therefore, in this project, following two types of data collections approaches are proposed

1. Quasi-experimental data collection (interviews)

Data collection approach will be based on interviewing experienced project managers, developers

(including architects) and testers. A sample may be smaller, but questions will be to get the deep

understanding on what worked well and what didn’t. Sample should include participants from three

groups. The groups are people who are practicing only traditional approach, have practiced both

approaches and practicing only agile approach.

Interviews to be designed to capture

Development Methodology

Evidence of failures of achieving deadlines from the point of the customer ( kind of

customer complains etc)

Any possibilities of improving the velocity as the team thinks

Impact on responding to change request during development ( probably a percentage of the

deviations of duration up to the point where change request was made)

2. Literature surveys (Documents)

Literature surveys will be used for following purposes:

38

Defining a model for evaluation

Analyzing industry awareness and case studies (for example success of open source projects)

Preparation of interview questionnaires

Data Analysis Approach:

In a research project, data analysis part is very important to derive a reliable out come. So following

data analysis approaches were reviewed.

Statistical Data Analysis

Content Analysis

Statistical Data analysis will not be qualifying since the data will not be quantitative. Two other

options are available under the content analysis as qualitative content analysis and structural content

analysis which considers both qualitative and quantitative data. During the research, chances of

having quantitative data is very less, qualitative content analysis method which is described bellow is

proposed for analyzing the data.

Qualitative Content Analysis:

This type of content analysis tends to be more subjective and less explicit about the processes by

which interpretation of the target material occurs. The emphasis is on meaning rather than on

quantification. Initially, the system of classification may be derived from the research question and

the topic guide used by the moderator during process facilitation. Additional conceptual codes may

arise from a closer examination of the data as a whole. Coded segments may include long exchanges,

phrases or sentences. The transcripts are cut and then sorted. Codes can also be developed to signal

useful quotations. Following this, a grid which tabulates code on one axis and focus group identifier

on the other is constructed that provides a descriptive overview of the data. The aim is to locate

quotations to illustrate particular themes or strands of meaning within the transcript. With this form

of content analysis, the aim is not normally to assign numerical values to the data (Brewerton

2001).

39

9.1.6 Issues of participants and Ethical Considerations

Following risks have been identified:

Participant may reveal data that are critical to the organization. So there is a risk that some

organization may not allow their employees to participate in the survey due to the fact the

potential leak of their information to the unwanted parties such competitors.

Participants may not be interested in participating as they have doubts about the

confidentiality of the data that they provide.

Follow actions will be taken to minimize above risks:

The obligation to protect the anonymity of research participants and to keep research data

confidential is all-inclusive, will be provided to participants and organizations if required.

Participant, their organizations will be treated as confidential and preserved the anonymity.

9.1.7 Outcome

According to the literature and personal experience, traditional development methodology seems to

be failing in many complex projects up to some extent. It was also observed that team could deliver

what had been agreed initially, but still did not meet the expectations of the customer (which had

changed since the inception) on time. But conventional practice seems to be working well in less

complicated, repetitive type of work.

Other hand we have agile development methodology that based on scrum (short term iterations)

where customer can review and provide the feedback. Thus provide an excellent flexibility

promising to deliver almost what’s expected in any given time.

Therefore, the potential outcome of the project would be the fact that agile development can deliver

what is expected (given that usually requirements change during the development phase) at

somewhat quicker than conventional development.

40

9.1.8 References:

a. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning,

J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R., Mellor, S., Schwaber, K.,

Sutherland, J. and Thomas, D. (2001). Manifesto for Agile Software Development., viewed 7

August 2009 http://AgileManifesto.org b. Brewerton, P., Millward, L., 2001, Organizational Research Methods: A Guide for Students and

Researchers, Sage Publications. c. Larman, C., 2003, Agile and Iterative Development: A Manager's Guide, Addison Wesley. d. Patton, M, Q., 2002, Qualitative Research and Evaluation Methods, 3ed, Sage Publication. e. Schwaber, K., Scrum Development Process, Advanced Development Methods,

http://jeffsutherland.com/oopsla/schwapub.pdf f. Wysocki, R, K., 2006 Effective Software Management, Wiley Publishing Inc., USA

9.2 Summary of interview data

This section summarizes the findings from the interviews. Participants are grouped into three such

individuals with exposure to only traditional software development (Group A), exposed to both

(Group B) and only exposed to Agile (Scrum).

Group

Question

Group A Group B Group C

Traditional method can adapt to

requirement changes quickly? No No

Why? New requirements are

typically included in the

next phase. Re-planning

and approval is

required.

Overhead is high when it is

required to absorb new

requirements even though they are

less complicated technically

Yes Yes

41

Can Scrum respond to changes

in requirement in a better way?

Reason? It’s far more

flexible than

traditional when it

comes adapting to

changing

requirements.

New

requirement

will be

included in

future sprints

based on the

priority.

Is it practical to have all

requirement in detailed at the

start of the project?

No No No

Reason? 1. Requirement changes from the customer’s and user’s

perspective.

2. Review of the partially or completely developed

product will result in adding or removing features

Can Scrum solve the problem of

not having precise requirement?

-- Yes Yes

Reason? Sprints are usually spanning from

1-4 weeks. So the development will

focus on short term goals where

requirement are easy to clarify to a

great degree. Thus the problem of

unclear requirements will not lead

to re-do work.

Is it a plus if customer involve in No Yes Yes

42

the development phase?

Reason? It might change the

requirement and impact

the schedule

Can align with the

expectation

Cam align with

the

expectation

What process would you like to

recommend for delivering the

product quickly? And Why?

No clear answers were

given. However answers

are closer to the fact

that if a mix of agile and

waterfall will do better.

Scrum helps to be

aligned with

customer

expectation and

reviews will help

to deliver what

customer wants

(at given time).

Scrum is

constructing

the product

with less

overhead

What are the biggest issues in

Scrum?

No long term plan and

architecture is evolving

rather having a solid

architecture

Typical project

planning is not

easy.

Difficult to reach

contractual

agreement since

there is no

―fixed‖ end date

to deliver all the

functionality

Nonfunctional

requirement may

be missed.

Typical project

planning is not

easy.

Productivity Depends the project

and team

Productivity

seems to be high

because

-Daily updates

increase peer

pressure

Productivity

seems to be

high because

-Daily updates

increase peer

pressure

43

-Simple and very

few overheads

-Full team is

productive

-Simple and

very few

overheads

-Full team is

productive

Reasons to failures or delays in

traditional developments

-Requirement clarity

issues

-Design doesn’t scale up

-Overheads are high

-Plans are two rigid

-No frequent reviews

-No frequent

reviews

-Designs are

freeze too early

-

-No frequent

reviews

-Designs are

freeze too

early

Reason to failures or delays in

agile developments

-No exact end date

-Lack of strong project

management presence

-Teams lacks of

relevant skills

-Scrum Master is

not having

enough insight to

the product being

development

-Backlog

prioritizing is

poor

Un-skilled

product

owners and

scrum masters