SRI LANKA INSTITUTE OF INFORMATION TECHNOLOGY AND SHEFIELD HALLAM UNIVERSITY FACULTY OF ACES

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.

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.

ii

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.

iii

Contents
Acknowledgements............................................................................................................................................ ii Abstract .............................................................................................................................................................. iii 1 Introduction ............................................................................................................................................... 1 1.1 1.2 2 Background ........................................................................................................................................ 1 Aims of Study .................................................................................................................................... 2

Literature Review ...................................................................................................................................... 4 2.1 The Waterfall Model ......................................................................................................................... 4 Phases ......................................................................................................................................... 4 Key Characteristics of Waterfall Model ................................................................................. 6

2.1.1 2.1.2 2.2

Scrum: An agile methodology ......................................................................................................... 6 Scrum Summery ........................................................................................................................ 7 Scrum Roles ............................................................................................................................... 8 Scrum Phases ...........................................................................................................................10 Key Characteristics of Scrum Process .................................................................................12

2.2.1 2.2.2 2.2.3 2.2.4 2.3 2.4 2.5 3

What is Velocity? .............................................................................................................................13 Analysis of Basic Challenges ..........................................................................................................13 Gaps in the literature leading to research question ....................................................................14

Methodology............................................................................................................................................15 3.1 Methodological Options ................................................................................................................15 Quantitative Research ............................................................................................................15 Qualitative Research ...............................................................................................................16

3.1.1 3.1.2 3.2 3.3

Justification of the approach .........................................................................................................17 Data Collection Approach .............................................................................................................18 iv

3.3.1 3.4 3.5 4

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

Population and Sample ...................................................................................................................19 Expected Limitation .......................................................................................................................20

Findings ....................................................................................................................................................21 4.1 4.2 Broad Summary of results..............................................................................................................21 Key findings from the interviews..................................................................................................22

Discussion ................................................................................................................................................25 5.1 5.2 Literature vs. Survey results ...........................................................................................................25 Contributing factors for faster Velocity .......................................................................................26

Conclusions and Recommendations ....................................................................................................28 6.1 6.2 6.3 The outcome of the research .........................................................................................................28 Recommendations...........................................................................................................................28 Future work ......................................................................................................................................28

Evaluations ..............................................................................................................................................31 7.1 7.2 Actual limitations and proposed improvements of research methods used ..........................31 Lessons learned................................................................................................................................31

8 9

References: ...............................................................................................................................................32 Appendices ..............................................................................................................................................34 9.1 Project Proposal ..............................................................................................................................34 Title: Evaluate Agile Methodology (Scrum) against Conventional Software

9.1.1

Development Methodology for greater Velocity ...............................................................................34 9.1.2 9.1.3 9.1.4 9.1.5 9.1.6 Problem Statement .................................................................................................................34 Discussion ................................................................................................................................34 Research Method ....................................................................................................................35 Data Collection and Analysis Approach..............................................................................36 Issues of participants and Ethical Considerations .............................................................39 v

9.1.7 9.1.8 9.2

Outcome...................................................................................................................................39 References: ...............................................................................................................................40

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

vi

Introduction

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.

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.

Literature Review

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 customers 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:

System Requirement

Software Requirement

Analysis

Program Design

Testing

Operations

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

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 subfunctions. 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

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 7

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 8

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.

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: 2.2.3.2 Development of a comprehensive backlog list. Definition of the delivery date and functionality of one or more releases.
Selection Mapping

of the release most appropriate for immediate development. 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 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. 10

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. 11

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.

12

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 teams 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 customers 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.

13

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 doesnt 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.

14

Methodology

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 15

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: preexperimental, 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 participants 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 16

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. 2. 3. 4. 5. 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 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

17

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:

18

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 nontechnical (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 19

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 Group A Group B Group C

Table 1 Participants Groups

Participants 5 8 3

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.

20

4
4.1

Findings
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 didnt 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

21

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

Interviewers 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. 22

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 reestimation 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. 23

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

24

Discussion

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 Defined Process Final Product Completion Date Responsiveness to Environment Team Flexibility and Creativity Knowledge Transfer Probability of Success Limited - cookbook approach Training prior to project Low Unlimited during iterations Team work during project High Required Determine during planning Determine during planning Planning only Scrum Planning & Closure only Set during project Set during project Throughout

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 doesnt 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.

25

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, its 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 teams productivity.

26

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.

27

Conclusions and Recommendations

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 28

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.

29

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.

30

7
7.1

Evaluations
Actual limitations and proposed improvements of research methods used

Even though generally qualitative approaches dont 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 developers 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.

31

References:
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 32

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

33

9 9.1
9.1.1

Appendices
Project Proposal
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 34

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 appreciationthat building software is complex, new product development with high change rates, and not predictable manufacturingis 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: 35

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 36

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 didnt. 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: 37

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).

38

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: 9.1.7 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. 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 whats 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.

39

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 Brewerton, P., Millward, L., 2001, Organizational Research Methods: A Guide for Students and Researchers, Sage Publications. Larman, C., 2003, Agile and Iterative Development: A Manager's Guide, Addison Wesley. Patton, M, Q., 2002, Qualitative Research and Evaluation Methods, 3ed, Sage Publication. Schwaber, K., Scrum Development Process, Advanced Development Methods, http://jeffsutherland.com/oopsla/schwapub.pdf Wysocki, R, K., 2006 Effective Software Management, Wiley Publishing Inc., USA

b. c. d. e. f.

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 Traditional method can adapt to requirement changes quickly? Why? No No Group A Group B Group C

New requirements are Overhead is high when it is typically included in the required and required. 40 Yes Yes approval to absorb new next phase. Re-planning requirements even though they are is less complicated technically

Can Scrum respond to changes in requirement in a better way? Reason? Its far more New than requirement be in flexible

traditional when it will comes adapting to included changing requirements. Is it practical to have all No No

future sprints based on the priority. No

requirement in detailed at the start of the project? Reason? 1. Requirement changes from the customers and users 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? Reason?

Yes

Yes

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

41

the development phase? Reason? It might change the Can align with the Cam align with requirement and impact expectation the schedule recommend for delivering the given. However answers aligned product quickly? And Why? are closer to the fact customer that if a mix of agile and expectation waterfall will do better. the expectation is product less with constructing the and with

What process would you like to No clear answers were Scrum helps to be Scrum

reviews will help overhead to deliver what customer wants project Typical project easy. (at given time).

What are the biggest issues in No long term plan and Typical Scrum? rather having a solid easy. architecture

architecture is evolving planning is not planning is not Difficult to reach contractual agreement there is since no

fixed end date to deliver all the functionality Nonfunctional requirement may be missed. Productivity Depends and team the project Productivity because -Daily increase pressure Productivity high because updates -Daily updates peer increase pressure peer seems to be high seems to be

42

-Simple and very -Simple few overheads -Full team productive Reasons to failures or delays in -Requirement traditional developments issues -Overheads are high -Plans are two rigid -No frequent reviews Reason to failures or delays in -No exact end date agile developments management presence -Teams lacks of Un-skilled product -Scrum Master is owners not enough insight to the product being development -Backlog prioritizing poor is -Lack of strong project relevant skills clarity -No reviews freeze too early very is overheads

and few

-Full team is productive

frequent -No frequent reviews are -Designs freeze early are too

-Design doesnt scale up -Designs

and

having scrum masters

43