0% found this document useful (0 votes)
53 views7 pages

A Comparative Analysis of Two Popular Ag

Uploaded by

willie2210
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
53 views7 pages

A Comparative Analysis of Two Popular Ag

Uploaded by

willie2210
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

International Journal of Computer Science and Telecommunications [Volume 8, Issue 2, March 2017] 1

Comparative Analysis of Two Popular Agile Process


Models: Extreme Programming and Scrum
ISSN 2047-3338

Faiza Anwer1, Shabib Aftab2, Syed Shah Muhammad Shah3 and Usman Waheed4
1-4
Department of Computer Science, Virtual University of Pakistan
1
[email protected], [email protected]

Abstract— Since last two decades, agile software development Extreme Programming (XP) and Scrum are most widely
methodologies have been one of the most debating topics for used agile models especially for small scale projects. These
researchers. These are called light weight development methods are called light weight development methodologies because of
because of informal, adaptive and flexible approach. These
excluding formal activities from development process for the
models are based on the collection of best practices which help to
handle problems related to changing requirements, customer sake of simplicity and agility. Both of these models have some
satisfaction, and product quality. A number of agile models are common and contrasting features. This study is conducted to
available to meet the needs of different projects. However explore and compare them in detail. This comparison provides
Extreme Programming and Scrum are two most familiar and a deep insight about these two methodologies that will greatly
commonly used models. This study makes a valuable contribution helpful for developers and researchers.
by exploring these models in detail. In this paper a detailed
Rest of the paper is organized in following sections; Section
comparison of Extreme programming and Scrum is conducted to
find their similarities, differences and explores those features II and III explain extreme programming and scrum in detail
which complement each other. respectively. Section IV provides a detailed comparison of
these two methodologies. Section V presents critical analysis
Index Terms— Extreme Programming, Scrum, Agile Models and section VI finally concludes this paper.
and Comparison
II. EXTREME PROGRAMMING

I. INTRODUCTION Extreme programming (XP) is an agile software


development methodology developed by Kent Beck in 1996

A GILE software development methodologies provide an


iterative and evolutionary development paradigm with
more emphasis on changing requirements, customer
while working on a C3 payroll project. Later in 1999, Kent
Beck published his book “Extreme Programming Explained”
to present a refined form of XP. It is a lightweight, more
satisfaction, and team collaboration [1]. These methodologies flexible and low risk disciplined approach of software
emerged in 2001 in response to limitations of plan driven development with ability to manage vague or rapidly changing
methodologies [1]. High rate of failed, cancelled and delayed requirements [2]. It is considered more suitable for small and
projects forced software practitioners to reconcile the medium sized teams [3]. XP is a collection of values,
development principles and practices. Agile models are principles and practices that are applied in a disciplined way
actually collection of best practices and principles of software [4]. It is called “Extreme Programming”, because of the fact
engineering. These principles may not be new for software that it took those practices to extreme which were considered
industry but in agile modeling these are used with different helpful in developing high quality software [5]. XP accentuate
approach that makes them more flexible and adaptive during greatly on customer satisfaction. Rapid feedback and frequent
development. These agile principles can accommodate rapid releases help in managing the defects near to its origin. Lower
software development needs. defect rate reduce the cost of development and result in a
more acceptable final product at lower cost.
Due to their simplicity, flexibility, and suitability to present
needs of software development, agile models are getting A. XP Phases
popularity from last few decades. Many agile models like
Extreme programming (XP), Scrum, Feature driven Whole development process consists of six phases:
development (FDD), Dynamic system development method Exploration phase, Planning phase, Iteration to release phase,
(DSDM), Kanban, Lean software development (LSD), Productionizing phase, Maintenance phase and Death phase
Adaptive software development (ASD) are available. Fig. 1.

Journal Homepage: www.ijcst.org


Faiza Anwer et al. 2

Exploration Phase: Exploration phase is first phase of XP life and steering phase [5]. Customer writes story cards to identify
cycle which deals with requirement and architecture modeling the required features of system. These features are then sorted
of the system. In this phase, user requirements, architecture, according to their importance and a smaller set of story cards
tools and technology are defined. A meeting among customer, for the recent release is selected. This is an iterative process
users and developers is arranged to plan release. Customer that can be adjusted by adding, removing, merging or splitting
writes user stories on stories cards that provide requirement some stories.
about software. These user story cards comprises of short
Iteration Planning: Each iteration starts with iteration
name, priority of story and one or two text paragraph without
planning. In this phase, developers prepare a plan of their
technical detail [5]. User story should be detailed enough that
activities to implement required features of the current release.
help the developers to understand system requirement and also
Like release planning, iteration planning also has exploration,
in making estimates. Time estimation means time required to
commitment and steering phases but customer is not involved
implement a story. If a story require longer implementation
in this step [5], [8]. During iteration planning programmer
time that story can be converted in to small stories by
select tasks to implement and estimates required cost, time
customer. For architecture modeling metaphors are created
and effort for selected task. Tasks can be given to other
during architectural spike to consider different alternative
programmers to balance the workload.
solutions. Metaphor is not a complete architecture but a
framework with basic objects and their interfaces. Exploration Iteration to Release Phase: This phase incorporate the basic
phase can last from few weeks to few months. However in [5] development activities like designing, coding, testing and
Kent Beck suggests that at the end of exploration phase integration [9]. This is an iterative phase in which each
enough material should be available from user stories that can iteration can span over one to four weeks. Each iteration starts
provide a good start for first product release and developer with iteration planning. In first iteration, such stories are
should have confidence about cost and time estimation of selected that make overall architecture of the system [5].
tasks to be implemented. Tasks selected for current iteration are actually implemented
by a pair of programmers. Programmers select tasks, make a
simple design and code it. After coding, functional testing is
performed and then code is integrated. Code refactoring is
used if developed code does not fulfill requirements. Final
development may take several iterations in which coding,
testing, listening and designing is performed repeatedly.
Standup meeting are used to discuss development progress or
any issues that need to be resolved [5]. After final iteration
code is ready for production.
Productionizing Phase: Being an iterative and incremental
process, XP delivers software in small releases. A release is a
small part of planned software that implements some business
needs. Frequent releases in XP allow to build required system
in increments. A release cycle can consists of a number of
iteration that can span from 1 to 4 weeks [10]. Productionizing
phase is about deployment of the software in small releases.
Fig. 1: Life Cycle of Extreme Programming [6] To check, whether the software is ready for production,
acceptance testing, system testing and load testing is
Planning Phase: After exploration phase, planning phase performed. During this phase, programmers slow down the
starts that aimed to find the answers of two questions rate at which system evolves. As the risk become more
basically; what can be built within due date that have some important whether a change should go to next release or
business value And what is the plan to do for next iteration? If not [8].
exploration phase was gone well then planning phase only
demand a day or two to complete [5]. During planning phase, Maintenance Phase: Maintenance is a natural phenomenon
task are drawn from user stories and written on task cards. for software systems. In XP, software continues to evolve over
In XP, planning process is called planning game that further a period of time. In this phase new functionality is built while
performed in two parts: Release planning and Iteration keeping the old one running [5]. New architectural design and
planning. During planning phase decision about team size, technologies can be introduced however XP team has to do
code ownership, schedule, working hours are taken [7]. more care as the system is in production also. The changes
that cause production problems are stopped immediately [6].
Release Planning: Basic objective of release planning is to
find out the features to be needed in the system and delivery Death Phase: This is the last phase of XP. There are two
schedule of these features. Both customer and developers possible situations in which a software system reaches to death
participate in release planning meeting. Release planning phase. In first case, if the developed software has all the
consists of three phases: exploration phase, commitment phase needed functionality and customer is satisfied and has no more
stories, then it is time to finally release the system. A small
International Journal of Computer Science and Telecommunications [Volume 8, Issue 2, March 2017] 3

document of five to ten pages is created, about the system for for developers [6]. Tired and bored programmers make more
future use. In other case, customer may require a set of mistakes that’s why unnecessary overtimes are avoided in XP.
features that cannot be developed economically. In such It is a rule of XP, to work 40 hours a week not more than this.
situation, it will be better to close the software development
which is called entropic death of system [5]. On-Site Customer: A customer’s representative is a part of
XP team and remains on site all the time [6]. He/ she is
B. XP Practices usually a domain expert that can decide about system's desired
features, answer the questions and can steer the development
There are twelve XP practices that distinguish XP from process. On-site presence help to reduce communication gap
other software process models. These practices are used between developers and customer. A quick feedback remains
during software development under the guidance values and available to developers about desired software.
principles of XP.
Coding Standards: Coding standards are followed in XP.
Planning Game: System requirements are collected on story
Code is owned collectively and can be accessed or changed by
cards that are used for further planning. Different team roles,
any programmer. To share the code among programmers, it is
team size, working hours and overall schedule is defined
necessary to follow some common coding standards [5].
during planning game [11]. Planning game is performed in
two parts called release planning and iteration planning.
C. XP Values
Small Releases: In each release a set of requirements are
developed that have some business and development value There are five XP values which are focused while XP
[5]. Small releases make the system open and available for practices are applied. These values are simplicity,
evaluation by the customer. Small releases help in getting communication, feedback, courage and respect [5], [10].
immediate customer’s feedback about system. Simplicity: XP keeps things simple like simple plan, simple
design and simple code. It prefer on designing simple solution
Metaphor: It is the architectural design of the system that
of the problem. No extra functionality is added until customer
describes how system should works. For developers, It is very
asked for [5]. Simple and small iteration of XP helps to avoid
important way to understand the system [11]. the risk of project distraction.
Simple Design: Simple design is a great practice of XP that Communication: Instead of documentation, XP uses active
helps to design basic required functionality of the system and and continuous communication among team members. All the
avoids unnecessary details. It focuses on currently needed team member and customer present on site and communicate
features not on future requirements. continuously to find more suitable and economical solution of
Continuous Testing: Continuous testing provide quick the problem.
feedback. XP uses unit testing and acceptance testing Feedback: XP uses feedback that span on different time
continuously. scale from second to months. Unit testing and integration
testing is performed on daily bases, provide quick feedback
Refactoring: Refactoring is restructuring the system without
about system. Feedback and communication help to keep
changing its behavior [11]. It is performed to improve the
project on the right way. On site presence of customer is a
quality and flexibility of design. It is a routine activity of XP distinguishing feature of XP that helps to get rapid feedback
developers to make the code quality better. about the developing software.
Pair Programming: It is very interesting feature of XP that Courage: XP practices require courage. Sometime it is
distinguish it from other development approaches. In XP, needed to refactor the code or design that was completed after
coding is performed by the two programmers at same machine great effort. It also means that making such decision that never
[5], [28]. The idea behind pair programming is to develop been made before for the system.
high quality software at lower cost. As most of the errors are
Respect is another important value of XP introduced in
captured and corrected within seconds by the companion
[12]. Self-respect and respect for other members is equally
programmer.
important that make it possible to implement XP practices
Collective Ownership: Any programmer can access any part (like pair programming, collective code ownership). Showing
of code any time to improve it. This is called collective respect towards work can force the developers to do high
ownership of code. Code review by number of programmers; quality work.
enhance the quality of software to be developed.
D. XP Roles
Continuous Integration: After completing every task,
system is integrated and tested. It may happen many times a XP define seven roles of team members with their qualities
day. This reduces integration problems and improves software and responsibilities that they must have to perform in team
quality. [5], [6].

40-Hour Week: XP discourages extra-long working hours


Faiza Anwer et al. 4

Programmer: This is most important role in XP team. adjusting the process in case of any unacceptable deviation
Coding is main activity in XP which is performed by [13], [14]. Scrum provides an iterative and incremental
programmer. There is no analyst, designer or architect in XP framework of development that builds software product in
team, all these tasks should be performed by programmer. small cycles called Sprints. Sprints have one month or less
duration. Scrum framework consists of three roles, four
Customer: Customer is another very important member of
ceremonies and three artifacts Fig. 2.
XP team who plays an active role throughout the development
process. He writes stories, derive functional test and verify
these test.
Coach: Coach is a person that should have both managerial
and technical skills. Good communication and decision power
help the coach to keep the team members together and on right
track.
Tracker: Duty of tracker is to gather metrics like load factor
and functional test scores about the project. Tracker collect
data from each developer after two or three days and record
how much time is spent on a task and how much is still
required to complete it. It is tracker’s responsibility to check
that iteration and commitment schedule are realistic and can
be meet [5].
Tester: The responsibility of tester is to guide and help
Fig. 2: Scrum Framework [14]
customers to write functional tests and verify them. As in XP,
unit testing is performed by the programmers so tester has a
A. Scrum Phases
very little to do.
Consultant: XP team has no specialist but in some cases Scrum activities can be grouped in three phases called
team needs technical guidance from an expert, in that case a Pregame, Game and Postgame [15], [16].
consultant can be hired for a time being. Two or more Pregame: This phase starts by defining the vision of the
developers discuss with consultant in a meeting to learn about project which may be unclear initially but can be refined
solution of the problem. further in later sprints. Product owner is responsible to define
Big Boss: He is a coordinator of the project that has the vision and prepared a prioritized list of functional and
responsibilities of team building, providing necessary nonfunctional requirements for the software. This prioritized
resources, equipment and tools. Big boss has to show courage list of required features is called Product Backlog [13]. A plan
while supporting team’s decision that is never experienced that includes the time and cost estimation is also prepared in
before. this phase with final product delivery date and number of
releases in which final product will be delivered. A high level
architectural design is developed that tells how to implement
III. SCRUM
different tasks, defined in product backlog. Some other
Scrum is most widely used agile software development important task completed in this phase includes risk
model. It provides an iterative and incremental framework for assessment, definition of development team, validation of
software development that is based on best practices used in development tools and verification of approval and funds.
Japanese industry. In 1995 Jeff Sutherland and Ken Schwaber Game: This is actual development phase of the scrum which
introduced the Scrum methodology that was later presented by is performed in small iterations called sprints. Sprint is a time
Ken Schwaber and Mike Beedle in a Book named “Agile boxed development period ranges from one week to four
Software Development with Scrum” in 2001. The idea behind weeks based on complexity and risk involved. Each sprint
scrum was to handle drawbacks of traditional development incorporates activities like develop, wrap, review and
methodologies. In scrum each product release is planned adjust [15].
according to customer requirements, time pressure,
competition, product quality and available resources. Postgame: This is a closure phase. After implementing the
Scrum is an empirical approach that is based on process desired features during development phase, final release
control theory to add flexibility, adoptability and productivity occurs. A release is declared closed when all the goals defined
in the development process [13], [28]. The strength of scrum during pregame phase are met. In closure phase final
lies in three points transparency, inspection and adaptation. integration testing is performed, user manuals and training
Transparency means that every aspect of process that affect materials are prepared for the final release.
the result should be visible to all members involved in product
development. Inspection means keep eye on process to detect
any unacceptable deviation. Finally adaptation helps in
International Journal of Computer Science and Telecommunications [Volume 8, Issue 2, March 2017] 5

B. Sprint Cycle Product Owner: Product owner is a customer’s


representative who has overall responsibility of product. He
Scrum works in sprints that are a time boxed duration in
creates and prioritizes the list of required features to be
which team actually develop the software according to
developed in the form of product backlog. He can reposition
product backlog [15], [17]. During sprint, scrum team works
the item in product backlog according to changing business
on product backlog under the guidance of scrum master to
needs. He decides the project schedule and is responsible of
develop functional software which will be delivered at the end
providing finance accordingly. He negotiates with scrum team
of sprint. Following activities are performed during sprint.
to convey the interests of all stakeholders. Product owner is a
Sprint Planning: Each sprint starts from sprint planning that person accountable for the profit or loss of the product. A
is completed in two phases. In part one, product owner and scrum team can have only one product owner. To fulfill his
scrum master review the product backlog tasks that are most duties, product owner must have clear understanding of
important. They decide the objectives and context of the high business, engineering and marketing. Good communication
priority tasks which help the team members to understands the skills are very important to deal with different stakeholders
product needs clearly. Part one of this meeting mainly focuses having different interests.
on the aspect of product.
Scrum Master: Scrum master is a team facilitator who
In second part of meeting focus is shifted on how to build
makes sure that team members are following scrum practices,
task till the end of sprint. Team reviews the probability of task
rules and values to gain the business value. His role is
completion irrespective to product owner decision. Then team
different from traditional project manager. He conducts a
commit to complete the work in decided time period. Scrum
brief meeting with team daily, called daily scrum to watch the
teams are self-organizing that divide the tasks and
progress. He is responsible of protecting team form outside
responsibilities according to their interest.
intervention and provides good circumstance to work. At the
Daily Scrum: Scrum team member daily conduct a 10 to 15 end of each sprint, an evaluation meeting called scrum
minutes meeting called daily scrum. This meeting helps the retrospective is conducted. In this meeting all the members
team members to know about the project progress. Team share their experience and lesson learned during sprint. This
members can find the cause of any speed interruption and take greatly helps in enhancing team knowledge and deciding what
corrective action accordingly. In this meeting every member should be done in next sprint.
tries to answer the following three questions [14].
Team: Scrum teams are self-organizing which consists of 3
What did I do yesterday to achieve the sprint goal?
to 9 members. In scrum team, specific roles are not assigned
What will I do today to achieve the sprint goal?
to members. They can divide tasks among them according to
Is there any hindrance in doing what I planned to do?
their interest. The entire team should have skills in designing,
First two questions help to understand the project progress and
developing, testing or documenting the product. These are the
last question helps to find the solution of problem that is
people who are responsible of delivering a working product
causing delay in the project progress.
after each sprint.
Sprint Development: During this phase activities like
design, development and testing is carried out for each tasks
IV. COMPARISON OF XP AND SCRUM
in product backlog. These tasks are implemented according to
their priority defined by product owner. Both XP and Scrum are well-known, widely used agile
Sprint Review: At the end of each sprint, a review of the models with some similarities and differences. To explore
developed product is conducted. This is inspected and adopt them from different perspectives a detailed comparison is
phase of product. In this review meeting product owner judge conducted by considering different factors and features in
whether the development is going according to needs. Table I. This comparison can be very useful for researcher and
Detailed conversation among product owner, scrum master developers to make a good choice according to project needs.
and team members help to get feedback about product which For the sake of comparison we have consulted a number of
may change the development directions [13]. research papers and studies which include [1], [3], [5], [6],
[15]–[25], [27]-[32], [33].
Sprint Retrospective: Sprint retrospective is inspect and
adopt phase for the process. During this phase, scrum master V. CRITICAL ANALYSIS
and team members discuss what is working and what is not
working in the process. This helps in deciding what practices Detailed comparison of XP and Scrum reveals very
should be carried out in next sprint and what should be interesting facts about both models. Both of these have some
changed in next sprint. This meeting greatly helps in common and some distinguishing aspects. It is observed that
improving the process. both models are focused towards building fully functional
software using an adaptive approach. Both have incremental
C. Scrum Roles and iterative nature however iteration duration is different.
There are three roles in scrum called product owner, scrum XP has set of twelve principles that provide a concrete
master and team [14], [17]. guidance about whole development process whereas in Scrum
selection of development practices is left on team members
Faiza Anwer et al. 6

[6], [21]. Scrum provides a framework rather than concrete used for small projects especially. These models used best
development practices. That’s why Scrum greatly depends practices in agile fashion to accommodate rapid application
upon developers’ skill and experience [3]. XP mainly focus on development needs. In this study a complete description
engineering aspects of software projects whereas Scrum deals explaining their different phases, practices and roles is
with management related issues. These contrary practices are provided. A detailed comparison is also conducted to get
also complementing each other. Joint application of Scrum deep understanding about these models. This can be very
and XP can give positive impact on team productivity, product helpful for developers, researchers and scholars interested in
quality [26]. these agile models. This comparison reveals that these models
have common and contrasting features. Some of contrasting
VI. CONCLUSION feature complement each other that encourage researchers to
experiment with combination of XP and Scrum for software
XP and Scrum are renowned agile models that are widely development.

Table I: Comparison of XP and Scrum

Features Extreme Programming Scrum


Development Iterative and incremental Iterative and incremental
Approach
Project Size Small All
Team Size 2 to 10 Multiple teams of less than 10 members
Team Activities Yes; Planning game, Pair No
programming, Collective code
ownership etc.
Iteration/Sprint Duration 1 to 3 weeks 4 weeks
Stakeholder’s Involvement Throughout the process Not defined
Communication Style Oral, through standup meetings Oral, through Scrum meeting
Project Management No Yes; Practices for project management are
available
Physical Environment Co-located teams Not defined
Abstraction Mechanism Object oriented Object oriented
Focus Towards engineering aspects Towards management and productivity
aspects
Response to Change Quick Quick
Requirement Elicitation User stories and on-site customer Not defined
practices are used
Distinction Among Different Not defined Not defined
Requirements (Functional,
Non-functional)
Documentation Less Less
Upfront design Document No Not defined
Design Flexibility Start from Simple design that can be Focus on simple design
changed using refactoring.
Development order defined by Customer Scrum Team
Development Style Adaptive Adaptive
Code Ownership Whole team Not defined
Changes During Iteration Allowed Not allowed
Acceptance Criteria Defined Defined
Feedback Span from minutes to months Span over a month
Testing Unit testing, integration testing, Not defined
acceptance testing
Structured Review meetings No No
Validation Technique Functional Testing and Acceptance Not defined
Testing
Quality Assurance Activities Test first approach Not defined
Coding Standards Properly defined Not defined
Software Configuration Not defined Not defined
Practices
Support for Distributed Projects No Not defined
Process Management No No
International Journal of Computer Science and Telecommunications [Volume 8, Issue 2, March 2017] 7

REFERENCES [19] A. Ahmed, S. Ahmad, N. Ehsan, E. Mirza and S. Z. Sarwar,


“Agile software development: Impact on productivity and
[1] L. Williams, “Agile software development methodologies and quality,” in IEEE Int. Conf. Management of Innovation and
practices,” in Advances in Computers, vol. 80, Elsevier Inc. Technology, Jun. 2010, pp. 287-291.
2010, pp.1-44. [20] A. I. Khan, R. J. Qurashi and U. A. Khan, “A comprehensive
[2] J. Newkirk, “Introduction to agile processes and extreme study of commonly practiced heavy and light weight software
programming,” in Proc. 24th Int. conf. Software engineering, methodologies,” Int. J. Comput. Sci. Issues, vol. 8, no. 4, pp.
May 2002, pp. 695-696. 441-450, 2011.
[3] E. Mnkandla, and B. Dwolatzky, “A survey of agile [21] P. Abrahamsson, J. Warsta, M.T. Siponen and J. Ronkainen,
methodologies,” The transactions of the SA institute of “New directions on agile methods: a comparative analysis,” in
electrical engineers, vol. 3, pp.236-247, Dec. 2004. Proc. 25th Int. Conf. Softw Eng., May. 2003, pp. 244-254.
[4] E. R. Mahajan and E. P. Kaur, “Extreme Programming: Newly [22] A.M.M. Hamed and H. Abushama, “Popular agile approaches
Acclaimed Agile System Development Process,” International in software development: Review and analysis,” in Int. Conf.
Journal of Information Technology, vol. 3, no. 2, pp.699-705, Computing, Electrical and Electronics Engineering, Aug.
2010. 2013, pp. 160-166. IEEE.
[5] K. Beck, “Extreme programming explained: embrace change,” [23] A. Qumer and B. Henderson-Sellers, “Comparative evaluation
addison-wesley professional, 2000. of XP and Scrum using the 4D Analytical Tool (4-DAT),” in
[6] P. Abrahamsson, O. Salo, J. Ronkainen and J. Warsta, “Agile Proc. Eur. Mediterr. Conf. Inf. Syst., 2006, pp. 1-8.
software development methods: Review and analysis,” VTT [24] J. M. Fernandes and M. Almeida, “Classification and
publ., pp. 3-107 2002. comparison of agile methods,” in 7th Int. Conf. Quality of
[7] T. Saeed, S.S. Muhammad, M.A. Fahiem, S. Ahamd, M.T. Information and Communications Technology, Sep. 2010, pp.
Pervez and A. B. Dogar, “Mapping Formal Methods to 391-396, IEEE.
Extreme Programming (XP)–A Futuristic Approach,” Int. J. [25] U. S. Shah, “An Excursion to Software Development Life
Nat. Eng. Sci., vol. 8, no. 3, pp.35-42, 2014. Cycle Models: An Old to Ever-growing Models,” ACM
[8] T. Dudziak, “eXtreme programming an overview,” Methoden SIGSOFT Softw. Eng. Notes, vol. 41, no. 1, pp.1-6, 2016.
und Werkzeuge der Software produktion WS, 2000/1999, pp. [26] K. Mar and K. Schwaber, “Scrum with XP,” 2002, Available:
1-28. http://www.informit.com.
[9] M. C. Paulk, “Extreme programming from a CMM [27] L. Lindstrom and R. Jeffries, “Extreme programming and agile
perspective,” IEEE softw., vol. 18, no. 6, pp.19-26, 2001. software development methodologies,” Inf. Syst. Manag., vol.
[10] R. Juric, “Extreme programming and its development 21, no, 3, pp.41-52, 2004.
practices,” in. Proc. 22nd Int. Conf. Information Technology [28] G. Rasool, S. Aftab, S. Hussain and D. Streitferdt, “eXRUP:
Interfaces, IEEE, Jun. 2000, pp. 97-104 A Hybrid Software Development Model for Small to Medium
[11] O. Kobayashi, M. Kawabata, M. Sakai and E. Parkinson, Scale Projects,” Journal of Software Engineering and
“Analysis of the interaction between practices for introducing Applications, vol. 6, no. 9, p.446. 2013.
XP effectively,” in Proc. 28th Int. conf. Softw. Eng, May [29] A. Dalalah, “Extreme Programming: Strengths and
2006, pp. 544-550. Weaknesses,” Computer Technology and Application, vol. 5,
[12] K. Beck, and C. Andres “Extreme Programming Explained: no. 1, 2014.
Embrace Change,” Addison-Wesley Professional, 2004. [30] M. Huo, J. Verner, L. Zhu and M. A. Babar, “Software quality
[13] K. Schwaber and M. Beedle, “Agile software development and agile methods,” in Proc. 28th Annu. Int. Conf. Computer
with Scrum,” vol. 1, Upper Saddle River: Prentice Hall, 2002. Software and Applications Conference, Sep. 2004, pp. 520-
[14] J. Sutherland, K. Schwaber, and C. J. Sutherl, “The scrum 525, IEEE.
papers: Nuts, bolts, and origins of an agile process,” 2007. [31] J. Cho, “Issues and Challenges of agile software development
[15] D. Cohen, M. Lindvall and P. Costa, “An introduction to agile with SCRUM,” Issues in Information Systems, vol. 9no. 2,
methods,” in Advances in Computers, vol. 62, 2004, pp.1-66. pp.188-195, 2008.
[16] K. Schwaber, “Scrum development process. In Business [32] L. Rising and N. S. Janoff, “The Scrum software development
Object Design and Implementation,” Springer London, 1997, process for small teams,” IEEE software, vol. 17, no. 4, pp.26-
pp. 117-134. 32, 2000.
[17] P. Deemer, G. Benefield, C. Larman and B. Vodde, “A [33] K. N. Rao, G.K. Naidu and P. Chakka, “A study of the Agile
lightweight guide to the theory and practice of scrum,” Ver, 2, software development methods, applicability and implications
p.2012. in industry,” Int. J. Softw. Eng. its Appl., vol. 5 no. 2, pp.35-
[18] G. Ahmad, T. R. Soomro and M. N. Brohi, “Agile 45, 2011.
Methodologies: Comparative Study and Future Direction,”
Eur. Acad. Res., 2014.

You might also like