EAD Thesis-Scrum for Faster Velocity - 49
-
Upload
chanakawee3525 -
Category
Documents
-
view
452 -
download
5
Transcript of EAD Thesis-Scrum for Faster Velocity - 49
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.
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