Agile Software Development: An Overview &
Methodologies
Hitik Patel Vishv Patel
Department CSE Department CSE
Institute of Technology Institute of Technology
Nirma University Nirma University
Ahmedabad, India Ahmedabad, India
22bce526@nirmauni.ac.in 22bce531@nirmauni.ac.in
Abstract—Agile techniques enable a team or organization to
implement a particular set of policies and procedures based
on the kinds of systems they develop and the company’s or
group’s values and culture. More precisely, each team or business
employs a variant of the agile methodology that is specially
designed to meet the demands of the group or company. There
is disagreement over the ”goodness” of a particular strategy, or
how much it helps an organization accomplish its goals. Many
of the agile assessment techniques now in use either concentrate
on comparative analysis or have a narrow scope and application.
In this paper, we suggest an all-encompassing, methodical, and
organized approach to evaluating the ’quality’ of agile techniques.
Three criteria are used to evaluate an agile approach: (1)
appropriateness; (2) the organization’s capacity to maintain the
ideals and processes outlined in the method; and (3) technique
effectiveness. It is advised that we use the Objectives, Principles,
and Practices (OPP) Framework as a guide for our review. The
agile philosophy’s goals, guiding principles that support the goals,
practices that exemplify the principles, connections between the
goals, guiding principles, and practices, and metrics for assessing
how much an organization supports the application and efficacy
of that practice are all identified within the Framework. In this
study, we report our method for solving the problem along with
some preliminary results and future directions.
I. I NTRODUCTION
Let’s start by taking a look at the beginnings of agile
software development, its evolution throughout the years,
as well as its accomplishments in the world of computer
technology before we move on to defining agile software
development and figuring out exactly what agile software
development is.
A. History
According to Beck et al. (2001), agile methodologies aim to
provide a substitute for documentation-intensive, heavyweight
software development processes. In traditional approaches,
needs are first elicited and documented, followed by high-
level design, development, and inspection for architecture
and other projects. The mid-1990s saw some practitioners
consider these early growth periods to be unachievable or
extremely arduous [Highsmith, 2002a]. Consumers are unable
to express their needs clearly up front while expecting more
from software, industry and technology are evolving too
Arpit Rabadiya
Department CSE
Institute of Technology
Nirma University
Ahmedabad, India
22bce533@nirmauni.ac.in
quickly, and requirements are ”changing at rates that swamp
traditional methods” (Highsmith et al., 2000). In order to
adjust to the impending change, some experts created their
own procedures and methodologies. The values and ideals
of agile methodologies are shared. Many apply the iterative
improvement that was first described in 1975 [Basili and
Turner, 1975].
Based on Cockburn and Highsmith (2001a), the major-
ity of Agile approaches are outdated. Agile approaches are
differentiated from conventional approaches by their focus
and values. Agile requires an analysis of earlier approaches.
Enhancing the software process draws on previous failures and
accomplishments.
Beck thinks that Royce (1970) first utilized the Waterfall
Model to evaluate and design for user needs. A thorough user
requirements study was the first step. Engineers would list all
of the features, functional requirements, and non-functional
requirements following months of interaction with users and
customers. With the help of this well-documented expertise,
engineers work with database and data structure specialists to
create the ideal system design. Perfected system is tested and
released after programmers implement the well-documented
design [Beck, 1999a].
Not every aspect of the system is defined by spiral
models. Spiral approaches requirement prioritization by risk,
whereas iterative development constructs the system based
on functionality. Although Waterfall was less flexible than
spiral and iterative development, some practitioners felt that
these methods were still too slow to adapt to shifting business
needs. Compared to today, iterative projects were less Agile
due to protracted planning and analysis phases and a focus on
documentation.
The development industry was evolving, and although
conventional approaches were still widely used, it was clear
that they were not always effective in all circumstances. It
was acknowledged by practitioners that in order to effectively
handle evolving requirements, new techniques were required.
Furthermore, according to Cockburn and Highsmith (2001a),
these new practices need to be flexible and people-oriented,
providing ”generative rules” as opposed to ”inclusive rules,”
which easily disintegrate in a dynamic setting. Cockburn and
Highsmith enumerate the contemporary difficulties that the
conventional approaches face:
• Following the original plan has not been as important as
ensuring the customer is satisfied.
• Change is inevitable; the focus should be on improving
coping mechanisms and lowering the cost of change
during the development process rather than trying to
prevent it.
• ”Business failure, or being insensitive to business condi- Fig. 1. Process of software development
tions, is the result of eliminating change early.”
• ”The market expects and demands cutting-edge, superior
software that fulfills its needs—and soon.” C. Traditional development methods
B. Background And Progress
The software crisis has helped software engineering
Software engineering acts as the framework for computer mature in some ways. Software development started using a
science engineering methodologies by providing the proce- repetitive process with documentation in the 1990s, based on
dures and standards that must be followed when developing the philosophy of software engineering. A few classic models
software[1]. were released at that time. As the exemplar of conventional
Based on the ideas of software engineering, a software software project management, the waterfall model had a
development process is a framework that is applied to the significant place.
creation of software products[2].Software Development Kits, As per Figure 2, the waterfall model is a software
or SDKs, are another name for software development proce- development model that was created for the purpose of
dures.With the aid of software, people use a wide variety of creating software. The reason for its name is that the model
programs. progresses methodically, resembling a waterfall, from one
Software development approaches aim to address the need phase to the next. The software development cycle seen in
for faster, more agile, and lighter software development pro- Figure 2 is highlighted by the waterfall model. And every
cesses that have been expressed by the hungry corporate step’s cycle stage should be planned, and each step should
community [3]. thoughtfully employ associated technologies and invest time,
In the field of project management, the phrase ”agile labor, and resources. Every phase should conclude with a
software development” first appeared. But what is project review of the findings. The following phase might begin once
management really? What does the term ”project manage- the consumer is happy with the outcomes. Users with fixed
ment” actually mean? The definition of project management, needs or predictable outputs are better suited for the waterfall
as stated by William R. Duncanillam[4] in his book ”A Guide method.
To The Project Management Body Of Knowledge,” is as
follows: ”Project management is the application of knowledge,
skills, tools, and techniques to project activities in order to
meet or exceed customer’s requirements and expectations from
a project.” In order to convert their resources into project
outputs, people will invest in a project. Every project aims to
create and deliver products or services that meet the client’s
needs along the way.
Around the middle of the 1960s, computers with enor-
mous capacity and fast speeds made it possible for computer
applications to proliferate quickly. During this time, soft-
ware development also increased significantly in quantity. The
evolution of operating systems and high-level programming
languages brought about major changes in the methodology
used to construct computer applications. The first database
management systems were developed in response to the need
to process large volumes of data. The challenges of preserv-
ing the dependability of the software systems also became
more noticeable as they became larger and more complex.
The program’s development process must be changed since
the original personal design and approach cannot meet the
requirements. An epidemic of the ”software crisis” occurred
[5]. Fig. 2. Waterfall Model
 Since 2001, the Agile Manifesto has included references to
agile development. Agile development was quite successful
later on. Agile development is becoming more and more
popular, and more people are planning to adopt it to finish
their own projects. These days, there are many other varieties
of agile development, including lean software development,
adaptive software development, extreme programming, and
more.
II. WHAT IS EXACTLY AGILE SOFTWARE
DEVELOPMENT?
The agile team first presented the idea of agile development
to the general public in 2001. Since then, the idea has
been recognized and adopted by numerous additional software
development teams and companies, and as a result, it has
progressively become commonplace in a range of projects.
The Agile Software Development[6] group simultaneously
published the Agile Manifesto, which is shown in figure II,
in support of the idea that software development has entered
a new era. This was done to get ready for the next phase of
software development, which has already started.
By undertaking software development ourselves and assisting
others, we are discovering more efficient ways to do it. As a
result of our work, we now value:
Individuals and their interactions with processes and tools
Working software instead of extensive documentation
Client cooperation in contrast to contract negotiation
Responding to change over following a plan
TABLE I
M ANIFESTO FOR AGILE S OFTWARE D EVELOPMENT
A. 12 principles behind the Agile Manifesto
1) Delivering valuable software on time and consistently
is our top focus in order to satisfy our customers: The
iterative process of agile development results in software that
is useful in small steps. Constant delivery, which emulates
the continuous iteration process of agile development. By
giving our clients helpful tools ahead of time, we are able
to promptly hear their recommendations.that does not stray
from understanding the users’ requirements. The earlier the
issue was identified, the less expensive the deviation repair
was. Customers can fully understand the efficacy, concern,
and satisfaction of a software company by using this notion.
2) Embrace evolving needs, even when they occur toward
the end of development: Agile development is also open to
making the necessary adjustments in response to requirements,
even at a later stage of development. Software is useful when
it truly satisfies user and market needs. Agile development can
reduce expenses associated with requirements modifications
because it has allowed for flexibility in system design.
3) Deliver usable software frequently, ideally in a shorter
amount of time—a few weeks to a few months: The project
team will collaborate with clients more closely if iterations
are done quickly. Building on the work done in the previous
release, the project team will improve the program or add new
features with each new release. Testing is essential to make
sure these improvements and new features are functional and
fulfill the required quality standards.
4) Developers and business professionals need to
collaborate every day during the project to: Data distortion
would unavoidably occur throughout the transmission
procedure. When company people convey client expectations
to developers, they might not fully understand the business.
Therefore, in order to identify issues as soon as feasible
during the project’s development, business and developers
would need to communicate more regularly and meaningfully.
The project team collaborates daily, even though they are in
different locations at different hours, to make it easier for
engineers and business to communicate.
5) Assemble projects around motivated individuals.Give
them the resources and support they need, and have faith in
their ability to complete the task. Each team member’s full
potential can only be achieved with this level of support,
encouragement, and trust.
6) Face-to-face communication is the most effective and
beneficial way to share information with a development team:
Information sharing and communication amongst members
of a large team is more socially acceptable. This allows
him to learn and learn at the same time. However, drafting
documents for communication will take a lot of time in an
agile team, which typically consists of only seven or ten
members. Team members could exchange information more
quickly and effectively if they spoke face-to-face.
7) The main indicator of development is functional
software: Each iteration in agile development aims to produce
a functional piece of software, therefore the number of
software that passes testing, satisfies release standards, and
functions is now used to gauge progress rather than the
quantity of code written or test cases executed.
8) The use of agile methods encourages sustainable
growth. It should be possible for the developers, sponsors,
and users to keep up a steady pace indefinitely: Working
overtime is a regular occurrence in software organizations.
Agile development, on the other hand, opposes working
overtime to finish iterative tasks. Team members will grow
weary and bored over time, making it harder to maintain
productivity.
9) Agility is enhanced by constant focus on technical
excellence and good design. Agile development requires
positive change adaptation and interpersonal communication.
As people pay more attention to these areas, their ability to
be agile will improve.
10) It’s crucial to practice simplicity, or the art of
maximizing the amount of effort not done: It is very
reasonable for anyone to anticipate accurate requirements
modifications. Agile teams believe that rather than focusing
on developing potentially necessary future software features,
everyone should focus on finding the simplest solution to
the challenges at hand. Using complicated technology to
implement software is not supported by agile development.
11) The most effective designs, specifications, and
architectures come from self-organizing teams: A self-
organizing team can effectively communicate with one
another to establish a shared culture and work ethic.Because
they don’t require comprehensive instructions, team members
can be more confident.
12) The group tunes and modifies its behavior in response
to periodic reflections on how to increase effectiveness: In
addition to the requirements changing as the project advances,
there are a number of other unknown variables, such as shifts
in the team composition, Adhering to a predetermined work
plan makes achieving agility challenging. It calls for the
team to evaluate their work at specific intervals and make
necessary improvements.
B. Differences between the agile development and traditional
development
Therefore, what does it mean precisely to speak about
”agile software development,” and how does this approach
to software development differ and differentiate from more
traditional methods?With the aid of the Agile Manifesto, we
first undertake an analysis of the distinctions between agile and
traditional software development approaches. Subsequently,
the definition will be presented.It is not at all difficult to sum-
marize and state that two components are given special atten-
tion in agile software development [?].Change-accountability
is the first, and effective teamwork is the second.
Model Adaptability Teamwork
Traditional An excessive dependence Insufficient communica-
on documentation. Design tion. Process is taken over
and implementation are by the manager.
distinct.
Agile Changes can be made Changes can be made
to the documentation, de- to the documentation, de-
sign, and demand while sign, and demand while
implementing implementing
TABLE II
D IFFERENCES BETWEEN THE AGILE DEVELOPMENT AND TRADITIONAL
D EVELOPMENT
1) Adaptability: Agile development emphasizes adaptability
over predictability. Traditional developers always plan for
extensive and complete documentation when starting a project.
They will examine the complete development process and
each sub-process, such as how many times or people will be
invested in, and write the results in the document. Most crucial
is that the document cannot be changed once detected. The
document must be followed by all project developers.Changes
to the document or schedule are prohibited. This development
approach has advantages when demand remains constant.
People uncovered several problems over time.
A thorough design document requires all project elements
to be implemented, which takes time. This approach, creating
documentation is easy, but development efficiency is poor.
Most modern projects assume the demand doesn’t change
throughout the phase, but too many incentives will modify
requirements.
Agile accepts changes even in late software development.
Its system designers and builders can quickly adjust to
consumer demand changes. It ensures the last iteration satisfies
client requests and market changes. Agile development follows
the plan, unlike waterfall. Agile development starts projects
with a rudimentary plan to allow for adjustments.
Second, without real users participating in requirements
definition, the specification may not meet end-user work
habits. Even if the requirements are specified and shown to
the end user to confirm, demand may alter. Everything is
imaginary until the user runs the system because they don’t
understand programming and can’t perceive illogical things.
Let’s imagine the user attentively participated in requirments
confirmation and identified most of them, however non-
functional needs like performance, smooth operation, etc.
cannot be shown to the user. If someone gives you an iPhone
manual and an Android phone manual, you can decide which
is superior. Besides its stunning design and user interface,
iPhone’s great benefits that attract so many young people
are hard to imagine. Until you grip it and feel the iPhone’s
seamless operation. On iPhone, you can feel the difference.
Agile will have many subprojects, each with a tiny
milestone. Visualize actionable phased achievements instead
of detailed documentation. Allow clients to understand the
development process and give more accurate software advise
in the next step. Agile development delivers meaningful
product to customers quickly to satisfy them and continues
to provide runable software. The delivery time should be
minimal.
2) Teamwork: Traditional process management seeks to
guarantee that the organization’s processes operate as planned
and that the established procedures are closely followed.
People’s responsibilities in document-centric processes are
often defined as dependable, interchangeable machine parts.
Instead of being process-centric, the agile development
process is people-centric.They consider people and the inter-
actions between them to be more significant than systems and
equipment. The lifeblood of methodology is practice[9]. Agile
development places a strong emphasis on letting individuals
adopt a method rather than imposing one on them. The
authority to decide on all technological matters must belong to
developers. Process should be kept to a minimum because it
is the second point. Building a project team with motivated
employees is the core of agile development. Provide them
with the right atmosphere and encouragement so they may
work with complete confidence. In-person interactions are the
most beneficial and efficient form of communication within
the project team. It is the epitome of human-centered design.
When opposed to document-centric communication, oral
communication facilitates information transmission and prob-
lem solving more quickly and effectively. Additionally, it
mandates that developers and business professionals work
together continuously throughout the project’s development.
This represents an agile development project by emphasizing
communication among team members. For business folks,
conducting research does not end with writing a requirement
analysis and sending it to developers. but should interact with
developers more skillfully to make sure they fully grasp the
business.
The definition of agile development follows once we have
a thorough understanding of the concept and how it differs
from traditional development. Agile software development
focuses on delivering high-quality software quickly while also
achieving customer satisfaction. It is able to quickly adapt to
changing software requirements[9].
C. Properties of Agile Software Development Methodologies
1) Deadline Emphasis: Agile methodologies give deadlines
a lot of weight.
2) Methodology: An adaptable approach to software devel-
opment is the agile development methodology.
3) Point of view on change: Agile development welcomes
change adaptability and enables better results.
4) User requirement: The demands of users in agile devel-
opment are extremely emergent, dynamic, and partici-
patory.
5) Quick results are the main objective of agile software
development methodologies.
6) Development life cycle: Using evolutionary and iterative
techniques, the Agile development life cycle is based on
quick model delivery.
7) Style of development: The Agile methodology uses an
adaptable approach to development.
8) Architecture: Agile is distinct in that it was developed
with consideration for the demands of the current con-
text.
9) Documentation: The development has very little doc-
umentation now that face-to-face encounters and tacit
understanding have taken their place.
10) Software development process: After contextual de-
mands are recognized, a flexible approach is used, which
speeds up development.
11) Basic Assumptions: Small teams are ready to develop
adaptive software by applying the ideas of continuous
design, testing, and improvement depending on input
and change. Their efforts have produced the excellent
software.
12) Developers: Developers are intelligent people who re-
spect collaboration. They are typically senior technical
staff members.
13) Team Size: Agile development teams are small, flexible
groups that respond to the demands of the project.
14) Management: Agile development places a strong empha-
sis on people-centric management and leadership traits.
15) The very specific goal of this development is to yield
better outcomes, perhaps by means of exploratory or
adaptive methods.
16) Change: You can implement this lightweight develop-
ment methodology strategy at any stage of the project.
17) Cycle: In order to finish a project using the agile devel-
opment approach, it must go through several cycles.
18) Domain: The domain in this instance is ambiguous and
maybe exploratory in nature.
19) Front-end Planning: Agile development reduces front-
end planning, which boosts efficiency.
20) Return on Investment: When using agile development
methodologies, the early return on investment is the
main priority.
21) Quality Control: In agile development, meticulous re-
quirements, first-rate designs and solutions, and contin-
uous testing satisfy the art form of quality control.
22) Restart expenses are negligible while employing this
type of Agile methodology.
23) Planning and Control: Internalized plans and quality
control are essential to the success of this system.
24) Refactoring: The Agile methodology’s affordability is
one of its key advantages.
25) Risk Impact: Agile development has a substantial risk
because it involves an unknown risk.
26) Testing is the main component of quality because it is
carried out at every stage of the project.
27) Proper Project Scale: Low to medium sized projects that
use the agile software development process are suitable.
28) Organizational culture: This style strongly emphasizes
leadership and collaboration skills.
29) Short-term schedule: Excellent and successful short-term
schedules are produced by agile development.
30) Functionality: Dynamic functionality is used in agile
development.
31) Control over resources: Agile software development
methodologies do not grant any authority over resources.
III. T HE STATE OF KNOWLEDGE
There are four key values in agile software development
that need to be adhered to at all times. These principles,
which form the basis of the Agile Manifesto, were discovered
in 2001 by a group of 17 experts who convened to talk about
ideas that might facilitate the software development process.
The Agile Manifesto[7,8] outlines the following four
essential values:
- ”People drive the development process and are the
ones who respond to the business needs” is a principle that
explains why ”individual interactions are more important
than processes and tools.” Because individuals can adjust
to the dynamic nature of development far more quickly
than technologies and processes can, people should be given
priority over these things.
- ”A concentration on functional software instead of
comprehensive documentation” - this value explains that in
the past, there were extended delays because programmers
had to devote all of their attention to documenting their
code, leaving little time for actually implementing their
requirements. Though shorter and typically presented as user
stories, documentation is still crucial when using Agile. The
developers can devote a significant amount of time to the
actual development as a result of the decreased delays.
- ”Collaboration instead of contract negotiations” is a
value that emphasizes the need for constant communication
between the project manager and the customer so that both
may fully grasp each other’s demands and talents. This
method of working is highly advantageous since it allows
for a greater understanding of the client’s needs, which
means that the finished product will live up to the customer’s
expectations.If there was just negotiation at the beginning
of the project, the customer might not have known how the
software might be developed, which could lead to a lack of
communication and an unhappy end product.
- ”A focus on responding to change” is the guiding
concept of the Agile method, which states that change is
always welcomed since it is considered an opportunity to
enhance the project and provide value. The Agile cycle’s
brief iterations allow developers to determine what works
and what doesn’t, then make adjustments appropriately. This
adaptability enables the group to adjust the procedure to best
suit their requirements.
A few myths exist around the Agile methodology, some of
which are as follows:
- ”It’s unpredictable” -¿ True, but Agile welcomes this
unpredictability, makes use of it to its advantage, and yields
better results, thus it’s no longer always a bad thing.
- ”Agile is more focused on the short term” -¿ well,
really, Agile helps programmers make better decisions
indirectly toward the long run by allowing testing to begin
sooner in the development process.
“Software development is an empirical or nonlinear pro-
cess, where short feedback- loops are necessary to achieve
a desirable and predictable outcome,” assert Williams and
Cockburn in their research, supporting the idea that agile
software development is all about feedback and continuous
change. The procedures involved in agile development are
crucial because they promote quick responses to shifting user
needs and surroundings by defining the agility that eliminates
the majority of traditional software development approaches.
Conboy maintains in his article[9] that agile software devel-
opment techniques support one or more of the following:
• the process of bringing about change;
• advocating for change beforehand;
• responding to change;
• taking lessons from it.
Agile software development techniques should also enhance
rather than take away from:
• perceived economy;
• perceived quality;
• perceived simplicity.
Thus, agile software development has been defined differ-
ently from plan-based or traditional development techniques,
particularly in terms of its emphasis on producing high-quality
products through straightforward workflows and adapting to
change.
These days, the primary distinction between agile software
development and traditional, plan-based software development
methodologies is the ability to react to change and produce
high-quality products using straightforward work procedures.
The core tenets of traditional agile techniques are as fol-
lows: project cycle, development model, ideal organizational
structure, role assignment, knowledge management, control
methodology, management style, and role of the client.
IV. AGILE METHODOLOGIES
Researchers in several fields have proposed and employed
a number of Agile approaches. The goals of several popular
agile software development methodologies are listed in this
section. Agile techniques that follow different approaches have
similar concepts but different practices:
• Extreme Programming (XP)
• Scrum
• Lean Software Development (LSD)
• Kanban
• Adaptive Software Development (ASD)
• Feature Driven Development (FDD)
• Dynamic System Development Method (DSDM)
• Agile Modeling (AM)
• Crystal
• Agile Unified Process (AUP)
A. Extreme Programming (XP)
A simple software development process is called Extreme
Programming.A practice that is also a summarization of
practice, extreme programming’s primary characteristic is
its ability to adjust to shifting conditions and demands
while allowing developers’ arbitrary initiative to run wild.
Extreme programming dedication to lower software project
risk, enhance responsiveness to business changes, boost
productivity during development, and lighten the enjoyment
of the software development process should be enough to
draw in all users, in my opinion.
Beginning with the introduction of the four
variables—cost, time, quality, and scope—extreme
programming allows us to better analyze the progress
of a project by examining how these factors interact with
one another.Extreme Programming contains twelve principles
and four values that must be followed in order to be properly
implemented. A lot of information exists in the Extreme
Programming corpus, and every piece of it merits further
study.
Kent Beck first suggested extreme programming in 1996.
This particular development process is appropriate for small
to medium-sized teams and adapts quickly to changing re-
quirements. Extreme Programming’s objective is to produce
software that can adapt to the changing needs of its customers.
In spiral development, the development process is broken
down into a very simple cycle, which is comparable to
extreme programming. Developers and clients can gain a clear
understanding of the status of software development, identify
 Fig. 3. Life Cycle of the XP proces
changes, identify problems that need to be solved and their
possible challenges, and modify the development process in
real time by using constructive feedback, constructive com-
munication, and a variety of other techniques.
As opposed to the conventional approach to project de-
velopment, Extreme Programming places emphasis on what
works best by listing techniques and concepts; other Extreme
Programming approaches are either categorically rejected or
not supported at all. Instead of causing delays in the project’s
advancement, a rigorous use of the Extreme Programming
methodology should have a quick and effective development
process that can complete a week’s work in 40 hours.
1) Background
Based on their experiences with the C3 project, Ron Jeffries,
Ward Cunningham, and Kent Beck presented it in 1998 [10].
2) Philosophy and Scope
The well-known and simple software development
methodology known as Extreme Programming (XP) focuses
on engineering techniques. The goal of XP is to make
software development feasible even in the face of ambiguous
or dynamic program requirements. It’s a set of procedures
meant to raise the caliber of software while promptly
adapting to the shifting needs of clients in order to satisfy
organizational objectives. In order to improve productivity,
it involves obtaining informal requirements from customers
who are present on-site, setting up pair programming teams,
creating simple designs, continuous refactoring, continuous
integration, and testing. It also promotes frequent releases
within brief development cycles and establishes checkpoints
where new customer requirements can be accepted [4,5,
6]. Projects requiring small to medium-sized teams to work
together in a collocation setting are best suited for XP. From
a project management perspective, XP is best suited for tasks
when needs are erratic and uncertain.
3) Extreme Programming Values
A worldwide, values-driven development process perspective
is offered by Extreme Programming. Four values are necessary
for the team to have in order to accomplish a high iterative
process: [11].
• Communication: Given that most projects fail due to
inadequate communication, it is unquestionably essential
to their success. It is achieved through open status dis-
plays, paired development, co-location of development
Fig. 4. Components of Extreme Programming
and business space, frequent changes in pair partners and
assignments, short stand-up meetings, unit tests, demos,
and oral communication rather than paperwork.
• Simplicity: The idea behind it is to create the simplest
product possible while yet meeting customer needs. It
encourages creating software with the least amount of
complexity possible while still supporting essential func-
tionality, producing code that is easy to read, understand,
maintain, and modify, and focusing on the here and now
rather than the future.
• Feedback: It implies that developers need to get input
from users, the system, and one another, and they should
appreciate it. It is delivered through aggressive iterative
and incremental releases, regular end-user releases, end-
user co-location, automated functional tests, and auto-
mated unit tests.
• Courage: It denotes being ready to make difficult choices
that uphold other values and standards. To follow the
necessary procedures and act honorably in the face of
adversity, one must possess courage.
4) Extreme Programming Activities
The four basic steps of traditional software development are
requirements, design, coding, and testing. Although they share
the same name, the four Extreme Programming tasks are
fundamentally distinct from one another. The four Extreme
Programming activities are briefly described as follows[11].
• Listening: Given that most projects fail due to inadequate
communication, it is unquestionably essential to their suc-
cess. It is achieved through open status displays, paired
development, co-location of development and business
space, frequent changes in pair partners and assignments,
short stand-up meetings, unit tests, demos, and oral
communication rather than paperwork.
• Designing: A somewhat unique viewpoint is presented
by Extreme Programming, which develops projects by
following the design. The process of design is now
dynamic rather than static, like a project phase. The
 developer’s job is no longer to do this.
• Coding: Many techniques used in Extreme Programming,
like pair programming, code refactoring, and test-driven
development, are centered around programming to pro-
duce high-quality programs. Instead of encrypted text
that is difficult to read, Extreme Programming developers
thought of code as intriguing text. In order for the other
team members to comprehend the logic, algorithms, and
procedures, the code must have a high readability level
and an evident meaning.
• Testing: Tests are one of the more difficult tasks in
Extreme Programming.A quality software product is
ensured by conducting thorough tests. Throughout the
entire development process, the Extreme Programming
test is conducted. Since most software bugs should be
fixed quickly rather than waiting until a later stage, the
code could be checked right away. The quality of the
generated software is ensured, and development expenses
are decreased in this way.
5) Extreme Programming Principles
Software development is guided by five essential principles,
which are based on the principles of Extreme Programming:
quality work, incremental change, rapid feedback, presume
simplicity, and embrace change[11].
• Auality Work: The term ”auality work” refers to the prod-
uct’s quality, which cannot be disregarded. Developers are
unable to compromise on software quality as development
moves forward.
• Incremental Change: To fix a problem, developers should
make a number of little adjustments. This idea ought to be
applied throughout the planning, development, and design
phases.
• Rapid Feedback: Developers rapidly assess whether the
present product satisfies client requirements by doing
brief iterative cycles to get feedback.
• Assume Simplicity: try to find the simplest solution to
every problem. This implies that the issue need only be
taken into account by developers for the current itera-
tion. In order to satisfy the requirements of the current
iteration, design should be as simple as possible.
• Embracing change: When tackling urgent issues, use
a patient approach. It is imperative for developers to
acknowledge that as client needs evolve continuously,
so too do the features and functionalities of priority
needs. Developers must find solutions to urgent issues and
frequently adapt appropriately to requirements changes in
order to embrace change.
6) Extreme Programming Practices
The creator of extreme programming condensed 12 extreme
programming approaches into a concise list that accurately
captures the ideas of extreme programming[11].
• Planning game: The Planning Game is meant to direct
the product during delivery [12]. You must ascertain the
demands of the user throughout the project planning
phase. The methods used by Extreme Programming to get
requirements from clients differ from conventional meth-
ods. When using Extreme Programming, clients receive
story cards from developers, which they fill up with all of
their specifications. Developers estimate how long it will
take to complete each card, and then Developers would
choose which tasks in the first iteration should be finished
based on user priorities and expected time. The outcome
will be compared to the original story card following the
first iteration. The user can edit the user card prior to the
next iteration commencing, after which it will begin.
• Simple design: According to Extreme Programming, code
should be written to fulfill the needs of the present
function as simply as feasible. The top-down approach of
traditional software development emphasizes the design
first; a flawless model must exist before any code is writ-
ten. On the other hand, Extreme Programming requires
developers to put in a lot of effort in order to find the
simplest design given the current needs.
• Small releases: The idea behind Extreme Programming
is to provide the user with an iterative version of the
distribution system every three weeks. Additionally, it
increases the chances for clients to interact with devel-
opers. Customers will give input based on this limited
version, letting developers know where issues exist. This
will enable developers to make the necessary changes in
time for the next release.
• Metaphor: A highly clear project outline is provided to
all developers via the system description, which serves
as a system metaphor that explains the fundamental
components of the system and how they relate to one
another. Customers do not comprehend the business’s
terminology because developers do not.phrase used in
software development. These metaphors are intended to
improve communication and prevent misunderstandings
between developers and clients.
• Pair Programming: Each small group has two developers,
one of whom serves as the driver and the other as the
navigator. During programming, they can switch roles
with each other. Though it may appear inefficient, using
two programmers to complete ”a programmer’s work”
really has the opposite effect. It allowed for knowledge
sharing within the team in addition to producing better
code and testing. Everyone has the ability to gain new
information from one another. You’ll start enjoying your
work.
• Coding standards: For the purpose of facilitating com-
munication amongst developers, code must conform to
a widely recognized standard. In extreme programming,
the emphasis should be primarily on developing a deeper
understanding of the code, rather than producing a large
amount of documentation.
• Collective ownership: No part of the code may be owned
exclusively by one person. You may now access every
single line of code in the upgraded repository. The code
can be altered by anyone, and doing so does not require
consent from another person.
 • Continuous integration: It implies that the entire set of
modules should be continually assembled. The goal is
to get continuing client input and identify issues early
on. The way the traditional method operates is as fol-
lows: when all code has been written, execute big-bang
integration, and then take a long time to fix the issue.
It goes without saying that continuous integration helps
identify issues early on. Several times a day should be
spent integrating.
• Refactoring: This is a process that has already been used
to make the code better. It optimizes the internal structure
of the code in the unlikely event that the program’s
external behavior remains unchanged. Its objective is to
improve the software’s maintainability as well as the
design and code quality.
• Testing: The requirement to write tests prior to starting
the coding process is heavily emphasized in Extreme
Programming. Two main forms of testing are conducted:
unit testing and functional testing.
• On-site customer: For extreme programming, at least
one client representative must be involved throughout
the whole development cycle. This representative’s duties
include verifying requirements, responding to inquiries,
and creating functional tests. Based on past experiences,
having a client present can enhance the precision and
effectiveness of the development process.
• 40 hours a week: Extreme programming mandates that
developers work no more than eight hours a day, forty
hours a week, and no overtime for longer than two
weeks in order to maintain productivity. A seamless
development approach guarantees that programmers can
keep working on the task and the team can keep releasing
new software to its clients. Working extended hours will
reduce productivity and cause developers to make more
mistakes.
7) XP Roles and Responsibilities XP Coach: helps the
team follow to the XP approach. XP Customer: establishes
implementation priorities, creates stories, and runs functional
tests. XP Administrator: Set up the local administrator and
programming environment. XP Programmer: writes code and
tests. XP Tracker: monitors iterations using tools such the
program/project manager, reports on the progress of iterations,
and offers comments on the accuracy of estimations. XP
Tester: Assists client in creating functional tests, executes
functional tests, and looks after testing equipment. XP Con-
sultant: a third party who helps the group address challenges.
Decisions are made by managers.
8) Limitations
• XP is not appropriate for complicated, large-scale
projects.
• When pair programming, it takes a lot of cooperation be-
tween the programmers, and even a minor disagreement
might undermine the goal of shared code ownership and
thus affect iterations.
• Carefully sharing the development of ”metaphor” within
the team is necessary to guarantee that everyone is using
the same vocabulary.
• In XP, pair programming is a crucial technique. It cannot,
however, be used for projects with a single developer.
The level of customer collaboration is low. The same
individual writes both the code and does the testing.
Because developers test from the same perspective from
which the product is produced, it’s probable that all
potential issues will go unnoticed.
B. Scrum
In an effort to give object-oriented development full play,
Ken Schwaber and Jeff Sutherland introduced Scrum, which
is an advancement over the iterative object-oriented method.
Scrum is derived from rugby, where players strive to achieve a
common goal—victory—by cooperating to uphold the court’s
rulings overall. Scrum, which was initially implemented in
Easel (1993), works well for software development because
its needs are unpredictable. The Scrum Master, Scrum Team,
backlog, sprint, and meeting have all been adopted by PLOP
as the standard for Organizational and Process Patterns.
The fundamental tenet of scrum is this: You cannot estab-
lish the final product specs up front when developing software,
just like you cannot design new products. Since processes
necessitate investigation, ingenuity, trial and error, no process
can ensure a project’s fixed success. Scrum is familiar with
the best sample model and technology that are required for
the development process, and it has a defined end objective.
with a high degree of independence and adaptability, closer
coordination, and teamwork to overcome obstacles. Make sure
there is a distinct increment for each level each day. Scrum is
therefore perfect for initiatives involving product development.
Fig. 5. Scrum process
Figure 5 illustrates the iteration cycle of 2-4 weeks
that is typical for the Scrum development process. A new
product begins with a client demand, and each iteration cycle
is referred to as a sprint. The development team needs to work
hard to provide outcomes at every cycle. The team meets for
fifteen minutes every day to discuss each member’s plans and
progress, recognize challenges, and decide how to divide up
the work for the next day.
 1) Background
Its design was inspired by Bob Charette’s Lean develop-
ment in the 1980s and the Toyota Production System’s Lean
manufacturing methodology. According to Poppendieck &
Poppendieck (2003), lean software development [9]. It is
ideal for integrating with other agile approaches, like XP,
which concentrate more on the technical parts of software
development. It emphasizes the project management aspects
of a project and does not prescribe any technical practices.
2) Philosophy and Scope
The word ”scrum” comes from the game ”Rugby,” in which
players pass the ball in steps to score goals. This is comparable
to advancing a project via iterations until the main aim is
met. Scrum is an incremental, iterative process for managing
any task or developing any project or product. It’s a simple
software development approach that consists of sprint cycles of
two to four weeks, during which a limited number of customer
requirements are implemented. Small sprints for continuous
integration lower risks and aid in winning over clients. The
daily stand-up meeting is a very effective tool for managing
and advancing the sprint, and by extension, the project [8].
Teams should be small, with seven to ten members. It is
scalable to higher values. The approach is designed to handle
projects in dynamic contexts.
3) Features and Benefits
Team size: Scrum team is usually 5 to 7 members
Iteration length: sprint length is 2-4 weeks
Scrum comprises three phases: Pre-Game (creating a prod-
uct backlog list, evaluating effort, and designing the high level
architecture); Development (doing sprints, analyzing, design-
ing, and delivering the work); and Post-Game (conducting sys-
tem testing, integration testing, and releasing documentation).
Values: Scrum is a strong advocate for the following
values: Courage, Openness, Respect, Commitment, and Focus.
Methods: Burn down charts, Scrum meetings, project di-
vision, team formation, and backlog creation.
Four sessions are held: daily scrum, sprint planning, sprint
review, and sprint retrospective.
Artifacts that are a part of the Scrum framework include:
• The product backlog: which is a comprehensive list of
requirements that are not yet included in the product
release. These requirements can include things like en-
hancement requests, problem fixes, and usability and
performance improvements.
• Sprint backlog: This is the list of backlog items that have
been assigned to a sprint but have not yet been completed
in common practice; no item on the sprint backlog should
take more than two days to finish. The team is able to
more accurately estimate the amount of work that will be
necessary to finish a sprint thanks to the sprint backlog.
• Burn down chart: This chart displays the work that needs
to be completed inside the sprint, and it is updated every
day. The burn down chart is used to track the progress of
the sprint as well as to determine when items on the sprint
backlog need to be deleted and moved to the backlog for
the following sprint.
• Release backlog: Requirements extracted from the prod-
uct backlog that have been categorized and ranked in
order of importance for a forthcoming release. The re-
lease backlog provides further information regarding the
requirements, along with a low-level estimate that is often
estimated by the team that is responsible for carrying out
the work.
The Scrum framework works effectively for tackling
smaller projects. There has been some progress made in terms
of the creation of work releases, and requirements can now be
prioritized in an organized fashion.
4) Roles
A Scrum project may have many distinct responsibilities, but
there are three essential jobs that must always be filled. The
product owner, the scrum master, and the scrum team are the
three key roles that are involved in scrum.
• Product Owner: This particular person is in charge of
managing the work backlog as well as arranging the
sprints and releases in addition to other responsibilities.
They function in this capacity as the project manager
for the Scrum team, despite the fact that the majority
of people in the agile community do not refer to them
as project managers. The product owner is responsible
for acting as a spokesperson for the client and ensuring
that the needs of the end user are taken into account
at every stage of the product development process. This
responsibility falls within the purview of the product
manager. The product manager is responsible for fulfilling
this commitment as part of their job responsibilities.
According to the official Scrum Guide, the primary
responsibility of the product owner is to maintain a record
of the inventory of items that are still in a state that can
be described as ”work in progress.” In order to achieve
this goal, the work needs to be structured and prioritized,
the relevance of the task needs to be determined, and the
upcoming responsibilities need to be conveyed to each
and every member of the team to ensure that they are all
on the same page.
• Scrum Master: Supporting the team in adhering to the
Scrum process is the primary responsibility of this func-
tion, which focuses mostly on the process. They provide
the team with guidance throughout the project by drawing
on their experience and knowledge, but they do not
participate in decision-making.
Their involvement in agile release planning is not
always the same as that of traditional project managers.
It’s what the Scrum team and the product owner do. A
Scrum team is designed to be self-organizing, therefore a
Scrum Master does not function as a kind of psuedo-
project manager. Since they facilitate the daily Scrum
meeting—one of the Scrum ceremonies we go over in
greater detail here—but do not participate in it them-
selves, the Scrum Master serves as the project’s glue.
Together with organizing retrospectives, sprint reviews,
and agile sprint planning meetings, Scrum Masters sup-
 port the team in maintaining its burndown chart.
• Scrum Team: A typical Scrum team, referred to as a de-
velopment team in the Scrum 2020 edition, comprises five
to nine members and typically encompasses the typical
functional roles needed to finish the project, according to
the Scrum Alliance. Architects, testers, developers, and
designers are typically included in software development,
but other specialists in security, performance, hardware,
and other areas may also be included.
The product owner’s priority list guides the team’s
decision-making as they collaborate to identify the best
course of action for achieving their objectives. The Scrum
method, which is overseen by the Scrum Master, serves as
their guidance. The Scrum Master provides the team with
the necessary support to enable them to handle everything
else. For instance, a team member may select a user story
from the product backlog that has been prioritized and
then determine how best to carry out that task on their
own.
Scrum’s foundation is this degree of autonomy. It
promotes close relationships amongst team members and
contributes to the development of a productive workplace.
Although the concept of a team is present in waterfall
projects as well, the team is not self-managed but rather
functions under the project manager’s direction.
• Other Roles: They are assisted in their work by a
wide variety of other specialists working in positions
such as testers, test automation engineers, cybersecurity
experts, user experience designers, business analysts,
functional experts, and performance/load engineers. All
of these individuals have focused their full attention and
dedication on the scrum project. These individuals have
each provided the scrum project with their undivided
attention and commitment to see it through to completion.
Fig. 6. Roles in Agile Scrum
Additionally, there are a number of ancillary responsi-
bilities that are not required to be a part of the Scrum
project team; yet, they are very vital to the successful
completion of the project nonetheless. This category of
stakeholders is comprised of a wide range of interested
parties, including customers, members of the executive
team, and a variety of other interested parties. It is
anticipated that each of these occupations will, at some
point in time, contribute to the completion of this process
in some capacity, shape, or form. This is something that
will occur over the course of this process.
5) Sprint
Sprint typically has a period of 30 days. People develop
and test during a sprint. A sprint ends, and another one
begins afterward, continuing until all of the tasks have been
completed; this process is known as iteration. Be able to
present a functioning product at the conclusion of each sprint.
In order to discuss unfinished work in the upcoming Sprint
Planning Meeting, it is recommended that unfinished work be
written back to the Product Backlog. The product owner will
assist in selecting certain items from the product backlog to
be added to the sprint backlog if the sprint task is finished
ahead of schedule.
There will be two sections to the sprint planning meeting.
The Scrum Master, Scrum Team, Product Owner, and Man-
agement discuss what and how the tasks will be developed in
the upcoming Sprint in the first section. The second section is
only for the Scrum master and the Scrum team. Participants
break down the chosen work into multiple manageable steps
before creating the Sprint Backlog.
Retrospective meetings follow review meetings. Recap the
Sprint is the goal. What worked well in the last sprint and what
may be improved for the next sprint are the two questions that
each participant should respond to.
6) Scrum advantages and limitations
The consensus among all of the members of the project team
is that the implementation of Scrum resulted in a significant
number of advantageous shifts over the course of the project.
These benefits include the ability to rapidly respond to changes
in requirements and release the product on time, as well as
the ability to boost productivity while simultaneously lowering
risk and enhancing product quality. In addition, these improve-
ments include the ability to release the product on time.
Where exactly does this Scrum go wrong, and what exactly
are its limits and bounds? There are two different aspects
that need to be taken into consideration. It does not pro-
vide sufficient support for large and complicated applications,
and its support for distributed development environments is
not very good. Neither of these shortcomings is particularly
exceptional. Neither one of these deficiencies is particularly
noteworthy.
C. Lean Software Development (LSD)
The word LSD stands for ”Lean Software Development,”
and this methodology considers the application of resources to-
ward the accomplishment of any goal to be a sort of production
practice.The amount of money a consumer is willing to spend
on a good or service is the best indicator of its value. The
natural environment serves as the primary inspiration for LSD,
which allows the substance to retain its value while requiring
significantly less effort to produce. The elimination of waste,
the production of excellent goods, the creation of knowledge,
the timely delivery of software, the respect of people, and the
optimization of the whole and dissimilar commitment are the
seven guiding principles that LSD adheres to [13, 14]. This
idea is demonstrated in Figure 7.
Fig. 7. Lean Software Development
1) Background
In the 1980s, Bob Charette’s Lean development and Toy-
ota’s Lean manufacturing systems were the inspiration for
this adaptation. A book titled ”Lean Software Development”
was published in 2003 by James Poppendieck and John S.
Poppendieck [9]. It does not impose any technical methods,
instead emphasizing the administrative aspects of a project; it
works well with other agile approaches, like XP, which con-
centrate more emphasis on the technically complex software
development processes.
2) Philosophy and Scope
The term ”Lean Software Development” (LSD) refers to
an iterative method that places an emphasis on eliminating
waste and improving efficiency throughout the entirety of
the software development process in order to realize the
greatest possible gain. The acronym LSD can alternatively
be abbreviated as ”Lean Development.” Lean has a long and
illustrious history in the manufacturing industry, and in the
software development industry, in more recent years, it has
become increasingly popular. Both industries are examples of
industries that have benefited from its implementation. When
used in conjunction with the six sigma method, it generates
results that are quite satisfying [9].
Any project that requires significant changes to be made,
but particularly one that involves the creation of software.
Designed with the company’s top executives serving as the
primary audience in mind during development. Because LD is
less of a methodology and more of a management philosophy
for the creation of software, there are no standards that must
be fulfilled that pertain to the size of the team.
3) Features and Benefits
Iteration length and team size: The Lean Software Devel-
opment approach does not specifically address team size or
iteration durations because it is more of a management concept
than a development process.
There are seven distinct Lean principles that Lean Software
Development follows and advocates. The Lean methodology
is based on these guiding principles, which are meant to be
reinforced by all of its other components. The seven guiding
concepts are as follows:
• Eliminate All Kinds of Waste: Eliminate anything that
does not offer value to the client experience.
• Build Quality In: Validate and re-validate all assumptions
at several points along the process in order to ”build
quality in.” Throw out a metric or practice if you find
that it is no longer useful.
• Make Knowledge: Make use of short iteration cycles to
deliver immediate and constant feedback in order to make
sure that attention is being paid to the appropriate items.
• Delay Commitment: You need to have a firm grasp of the
issue and the trade-offs of different solutions in order to
make a decision, therefore wait until enough information
is available.
• Deliver Quickly: Reduce the amount of time it takes to
determine an issue with the business and then deliver a
system or product that solves that problem.
• Respect People: Respect other people and provide the
team the tools it needs to be successful.
• Optimize the Whole: Collaborate with members of other
functional areas to ensure that you do not miss any vital
or possibly mission-critical aspects of either the issue at
hand or the solution that is being formulated in order to
address it.
Typically, only the customer will give the team with
the business requirement, although they nevertheless play an
important role. The primary goal is to get rid of waste and
improve the entire process so that we can make the most
feasible benefit, and this works really well with the six sigma
methodology.
4) Principles
The following management techniques are emphasized
throughout the 12 principles of Lean Development [Highsmith,
2002a]:
• It is of the utmost importance to ensure that the needs of
the consumer are met.
• Always offer the best price for the quality you deliver.
• Participation from paying customers is essential to a
business’s success.
• Every initiative that LD undertakes is a group effort.
• Everything is subject to alteration.
• Solutions for the domain, not individual points
 • Finish, rather than build up or construct
• A solution that is 80 percent complete now rather than a
solution that is 100 percent complete tomorrow
• The practice of minimalism is crucial.
• Technology is based on requirements.
• The growth of a product is measured in terms of its
features, not its size.
• Never attempt to push LD over its capabilities.
5) Roles and Responsibilities
There is no specific reference of tasks and obligations in any
way, with the sole exception of the notion that LD must first
be directed toward CEOs in order for it to be implemented in
the company.
6) Advantages and limitations
Advantages:
• By taking a more streamlined approach, more function-
ality may be supplied in a shorter amount of time.
• Reduces costs by doing away with activities that aren’t
necessary and, as a result, saves money
• Provides the development team with the authority to make
decisions, which has been shown to improve morale.
Disadvantages:
• Creating a cohesive team and individual contributions
from each member are critical to the project’s success,
so building a strong team is imperative.
• If the wrong business analyst is not involved, or if their
participation is inappropriate, scope creep may happen.
D. Kanban
Kanban is not an inventory control system; rather, it is a
method for regulating the chain itself, which is of a logistical
nature. This distinction is important to make clear when
discussing production. Kanban was developed as a tool with
the dual purpose of enhancing the system while also ensuring
an adequate level of production. It is amazing that Kanban has
proven itself to be a way for driving improvement in addition
to becoming a well-known and valuable instrument for
assisting in the operation of a production system as a whole.
[7] Kanban became a well-known and useful instrument for
assisting in the operation of a production system as a whole.
This idea is illustrated by the figure number 8.
Fig. 8. Kanban System
1) Background
The Kanban method’s initial conception, which was devel-
oped by David J. Anderson. Unlike sprinting, which includes
beginning and stopping the delivery of work every two to four
weeks, this strategy focuses an emphasis on a continuous flow
of work rather than starting and stopping the supply of work
at regular intervals.
2) Philosophy and Scope
The term’signboard’ is where the Japanese word ’kanban’ gets
its start. Kanban is a visual process management technique that
gives information regarding what should be produced, when
that production should occur, and how much production should
occur. Kanban was developed by Toyota. It is a method for
controlling the production of goods with the primary focus
being on continuous delivery, while at the same time keeping
the development team from becoming overworked.
Kanban is a method that, in a manner very similar to that
of Scrum, seeks to improve the efficiency with which teams
collaborate with one another. Kanban was initially conceived
upon and developed by the Japanese. It promotes the idea
of ’broad communication’ by using the workflow state (such
as TBD, WIP, and Done) as a’signboard’ that offers an all-
encompassing image of the project. This helps to ensure that
everyone involved in the project is aware of its status at all
times. There is widespread support for the Just-In-Time (JIT)
methodology, and it is recommended that the stock level be
dropped in order to reduce the amount of money spent on
overhead.
3) Features and Benefits
The following is a list of the four core principles that form
the foundation of Kanban:
• Start with the existing process: A change management
method that begins with the process that is already in
place, this approach begins with the process that is
already in place. Modifications to the system are imple-
mented in a manner that is iterative and evolutionary.
Kanban does not have a clearly defined process or set of
roles, in contrast to Scrum.
• Agree to continue evolutionary and incremental changes:
After beginning with the process that is currently in
place, the group will need to come to an agreement on
continual, evolutionary, and incremental modifications.
The adjustments ought to be moderate and carried out
step by step. Alterations that are both rapid and extensive
have the potential to be successful, but the team will
likely put up a greater fight against them.
• Admire current roles, processes, responsibilities & ti-
tles: Despite the fact that Kanban recommends making
continual, incremental changes in the process, it pays
attention to the roles, responsibilities, and job titles that
are currently in place. Having this support as they begin
their journey with Kanban is beneficial to the team’s
confidence.
• Leadership at all levels: Kanban does not mandate that
leaders originate from a specific group; rather, it actively
promotes leadership actions to be taken at every level of
 an organization. This is in contrast to other management
approaches, such as the waterfall approach, which antic-
ipates that only a fraction of the workforce will provide
leadership.
Practices of Kanban: Begin with what you are doing right now,
Respect the existing procedures, duties, responsibilities, and
job titles, and encourage acts of leadership at all levels of the
organization. Agree to pursue gradual, evolutionary change.
Agree to pursue incremental change.
4) Roles and Responsibilities
Kanban does not impose any roles on its users. The decision
will be made by the company and the team. It is recommended
by Kanban to keep the cycle time as short as possible; hence,
if adding a role would assist keep the cycle time as short as
possible, then the role can be included; however, if it will
make the process slower, then the role should not be present.
Additionally, if the value of the improved cycle time is less
than the cost of the role, then it is unnecessary overhead.
5) Limitation
• Even a minor glitch in the Kanban system’s operation
might cause the entire line to stop functioning, and getting
it back up and running again involves additional work.
• The throughput of the Kanban system is not managed;
rather, it is the result of controlled work-in-process and
a cycle time that is known in advance.
E. Adaptive Software Development (ASD)
ASD (Adaptive Software Development) suggests that e-
business project needs may be unclear at the start. Project
mission handling, requirements, objectives, time frame, feature
set requirements, estimations, scope, and resource availability
are determined through guesswork. Total project size and
uncertainty level determine iteration length. A time box is
assigned to the iteration after that. Team members create ob-
jective statements for each iteration. In the last iteration, users
and developers contribute features. Trustful and courteous
collaboration is essential for teamwork. Team must collaborate
on quick decision-making, requirements, and issues. Real
comprehension can be enhanced through learning. The focus
on groups includes feedback, technical evaluations, and post-
mortems [6]. Fig-9 shows this.
Fig. 9. ASD Life Cycle
1) Background
In 2000, Jim Highsmith and Sam Bayer provided a description
of it [10]. ASD, which focuses on the quick design and devel-
opment of software systems, is a subset of rapid application
development.
2) Philosophy and Scope
The process of designing and building software systems is
called ASD. It provides methods for developing big, compli-
cated systems incrementally, iteratively, and through contin-
uous prototyping. Product start-up, planning for an adaptive
cycle, concurrent feature development, quality assessment, and
ultimate quality control and release are all involved. It de-
pends on the peer-to-peer work of team members. Customers
typically operate as members with the idea of progressive
elaboration and don’t have all the criteria at first.
It is confined to project management tasks because it is
fundamentally an agile project management mindset. The scale
of the project determines the boundaries of this methodol-
ogy with regard to team sizes, although as with other agile
methodologies, the level of agility declines with team size.
The communication methods used in a project define its level
of rigor and support for distributed development.
3) Features and Benefits
Phases: Collaborate (concurrent feature creation), Learn (qual-
ity evaluation), and Speculate (initiation and planning).
Life Cycle Qualities: Iterative, risk-driven, feature-based,
mission-focused, time-boxed, and change-tolerant.
4) Roles and Responsibilities
Executive Sponsor: Person with overall responsibility for the
product.
Participants: in joint application development sessions
Developer: programmer.
Customer: User
F. Feature Driven Development (FDD)
FDD (Feature Driven Development) emphasizes the build-
ing and design phases of software development, rather than
the entire life cycle. Build involves a feature list phase
when the team identifies and groups features into sets, then
systematically organizes primary feature sets. The feature list
is prioritized by phase and a development strategy is created
to determine the order of feature set implementation. During
the design-based and feature-based fourth build phases, the
team divides into feature teams and executes design, testing,
and feature development within two weeks. This phase is done
until no features remain [15,16,17]. As depicted in Fig-10.
1) Background
It emerged from Jeff DeLuca and Peter Coad’s work in late
1999, and Palmer and Felsing later defined it in 2002 [11, 12].
There are five activities that center around the domain model:
Construct a feature list, Create an overall model, Consider each
step of the process: plan, design, and build.
2) Philosophy and Scope
FDD stresses quality throughout the process, concentrates
on the design and construction phases, and includes regular,
observable delivery in addition to precise tracking of the
project’s advancement. It is a method to building products or
solutions that is easy to understand and powerful [13].

Fig. 10. Feature Driven Development Process
Only small to medium-sized teams (four to twenty members)
can use FDD. The approach is based on object-oriented
modeling and addresses requirements that are not quite clear.
3) Features and Benefits
Team Size: The size of the team varies based on how sophisti-
cated the feature in question is. DeLuca emphasizes the value
of elite individuals, particularly modeling professionals.
Duration of iteration: Possibly two weeks.
Phases: The five stages consist of Build the feature, plan by
feature, design by feature, and build by feature are the steps
in developing the entire model.
Practices: Inspections, Configuration Management, Regular
Builds, Individual Class (Code) Ownership, Feature Teams,
Domain Object Modeling, Developing by Feature, and Visi-
bility of progress and outcomes
Develop the overall model, create a feature list, plan, design,
and build features, as well as milestones.
Values: To scale to larger projects, a system for building
systems is required. The finest processes are straightforward
and well-defined. The steps in the process should make sense
and be immediately apparent to all members of the team.
The genuine work may be prevented by process pride. Good
procedures fade into the background, allowing team members
to concentrate on outcomes. The ideal life cycle is brief,
feature-driven, and iterative.
4) Roles and Responsibilities
• Project manager: in charge of overseeing all project
administration, including reporting and financial matters.
Chief Architect: In charge of overseeing all design meet-
ings, code reviews, and technology selections. Responsi-
ble for the overall system design.
• Development Manager: Responsible for overseeing the
day-to-day development tasks. managing resource con-
cerns and coordinating the work of the development team.
• Chief Programmer: A senior developer designated to
oversee one or more Feature Sets and engaged in ongoing
design and development operations.
• Class Owner: A developer who designs, codes, tests, and
documents features as they are implemented, working
under the supervision of a Chief Programmer.
• Domain Expert: Any stakeholder with a business connec-
tion who is able to specify the features that the system
must have. Clients, users, and different analysts fall under
this category; they are all those with business-related
expertise who may have an effect on the system.
• Tester: In charge of confirming that every feature operates
as intended.
• Deploy Manager: Manages the definition and/or transla-
tion of data between different formats in addition to the
actual deployment of code to different environments.
• The technical writer is in charge of producing and or-
ganizing all of the printed and web documentation that
users will require for the finished product.
5) Limitation
• Project criticality is not expressly addressed in the FDD
prescription.
G. Dynamic System Development Method (DSDM)
In agile project development, the Dynamic Software De-
velopment Method, or DSDM, is a framework that looks
both forward and backward. DSDM prioritizes prompt prod-
uct delivery in addition to a guiding technique for process
control. The Moscow rule, which is applied when prioritizing
requirements, assigns bases on Should have, Must have, Could
have, and Want to have but won’t have this time. When a
project is developed in conjunction with DSDM, the business
and feasibility studies need to be completed in order. These
two stages determine the foundation for the remainder of
the project. The latter three stages are both incremental and
repetitive. In reality, the project is developed during these
stages [6,8, 18]. This can be seen in Fig. 11.
Fig. 11. DSDM Process Diagram
1) Background
In 1995, Stapleton provided a description of it [14]. In an effort
to improve Rapid Application Development (RAD) quality,
a significant number of project practitioners collaborated to
create DSDM in 1994. It emphasizes the early delivery of
significant business benefits.
2) Philosophy and Scope
The project and product management life cycles are combined
into one optimal process using the iterative and incremen-
tal DSDM approach. It was created to close some of the
holes in the RAD methodology by offering a framework that
considers the whole process of development. It is a tried-
and-true paradigm for agile project management and delivery
that focuses on strategic goals and the gradual delivery of
genuine business advantages while maintaining control over
time, money, risk, and quality. This helps to deliver results
fast and effectively.
DSDM isn’t appropriate for every project. DSDM is par-
ticularly ill-suited for usage in real-time, safety-critical, or
well-defined system needs. DSDM works particularly well for
projects whose requirements change over time. The ability to
prioritize these criteria is essential.
3) Features and Benefits
Team Size and Length of Iterations: DSDM is more of a frame-
work than a technique. The structure of DSDM means that
team size and precise iteration durations are not particularly
addressed. Teams can consist of two to six members, although
a project may contain multiple teams.
Stages: Pre-project, Feasibility Study, Business Study, Func-
tional Model Iteration, Design and Build Iteration, Imple-
mentation, and Post-project are the six stages of the DSDM
lifecycle.
Fundamentals: The nine principles of DSDM are as follows:
active user involvement; teams must be empowered to make
decisions on their own; frequent release cycles are more
important than maximizing quality; meeting business needs
is the primary criterion for deliverables; iterative development
is necessary to arrive at an accurate solution; changes made
during development can be undone; high-level requirements
should be set in stone; testing should take place at every stage
of the project’s lifecycle; and all stakeholders must collaborate
and communicate.
Methods: Workshop, Modeling, MoSCoW, Prototyping, Test-
ing, and Time Boxing. A well-known prioritization method
is MoSCoW, which ranks characteristics according to ”Must
have,” ”Should have,” ”Could have,” and ”Would nice to have.”
Compared to XP and Scrum, this is heavier. It offers a method
that is independent of technique and adaptable to changing
requirements. Both in terms of money and time, it is effective.
4) Roles and Responsibilities
• Executive Sponsor: A significant position from the user
organization with the authority and duty to allocate funds
and resources as needed. This position has the final say
in decisions.
• Visionary: The person in charge of starting the project by
making sure that all necessary needs are identified at the
outset. The visionary perceives the project’s and system’s
commercial objectives the most accurately. Overseeing
and guiding the development process is another respon-
sibility.
• Friend: Individual adds the user community’s expertise to
the project and makes ensuring the developers get enough
user input while they are working on it.
• Advisor: A user can be any anyone who contributes
everyday project knowledge and a significant point of
view. The person in charge of overseeing the project
overall may be an IT staff member or a member of the
user community.
• The Technical Coordinator is in charge of creating the
system architecture and overseeing the project’s technical
excellence.
• Team Leader: Guides and guarantees the smooth opera-
tion of the team as a whole.
• Solution Developer: Comprehend the needs of the system,
model it, create deliverable codes, and construct proto-
types.
• Solution testers: Test the system to verify its technical
correctness, report errors when they arise, and retest once
they have been corrected. The tester must provide some
documentation and remarks.
• Scribe: In charge of compiling and documenting the
specifications, agreements, and choices reached at each
workshop. The facilitator is in charge of overseeing the
workshop’s progress and serves as a catalyst for planning
and interaction. Specialist Positions: System Integrator,
Quality Manager, Business Architect, and so on.
5) Limitation
• It is predicated on user participation, which isn’t feasible
for every project.
• The fundamental issue with DSDM is that, in comparison
to other agile development software approaches.
• It can be restricted and challenging to work with due to
its strictness and eight principles.
H. Agile Modeling (AM)
A practice-based method for software development called
Agile Modeling (AM) is used to provide a structured project
management procedure that allows for frequent adjustments.
Agile serves as the conceptual foundation for many soft-
ware engineering endeavors.Software development short time
boxes, also called iterations because of their integration with
the duration, lower risks. Agile development is a catch-all
term that includes several different methodologies. The Agile
Manifesto included the XP, Crystal, Scrum, DSDM, and FDD
methodologies in 2001. That’s what Fig. 12 shows.
Fig. 12. Agile Modeling
1) Background
Scott Ambler first suggested agile modeling (AM) in 2002
[15]. It only addresses modeling and documentation. Since
it isn’t a comprehensive approach, it can be applied to any
software development process.
2) Philosophy and Scope
AM modeling is new. Agile principles are used to adjust
modeling approaches. This practice-based method models and
documents software-based systems. It is a collection of best
practices and ideals, concepts, and techniques for modeling
software that may be implemented to a software development
project efficiently and lightly. It supplements Scrum, XP, and
RUP and is specifically included in the Disciplined Agile
Delivery (DAD) paradigm [16, 17]. The goal is to minimize
models and documentation. Communication and teamwork are
shown to address cultural difficulties.
The methodology targets small teams but does not specify one.
AMDD works with all non-modeling agile methods.
3) Features and Benefits
The team size, precise duration of iterations, distribution, and
system criticality of AM rely on the development process
being employed. This is because AM is not a stand-alone
software process development method and should be used in
conjunction with other development methods.
Values: incorporate the XP principles of courage, communi-
cation, simplicity, and feedback in addition to humility.
Objectives: Applied Modeling (AM) aims to clarify and
demonstrate how to implement a set of values, principles, and
practices that result in lightweight and effective modeling. It
also addresses the question of how to apply modeling tech-
niques on Agile software development processes and how to
apply effective modeling techniques regardless of the software
process that is being used.
4) Roles and Responsibilities
It is anticipated that developers and project stakeholders will
comprise AMDD teams. Developers that are self-motivated
and diligent should make up teams. Everyone has to work in
teams to complete the modeling.
5) Limitation
Applying agile modeling disciplines might be challenging.
• in big teams (more than 30) without sufficient tooling
assistance.
• when it is impossible for team members to communicate
and work together on models (which would make Agile
Software Development challenging in general).
• when one’s modeling abilities are poor or absent.
I. Crystal
Alistair Cockburn created Crystal Methods. Crystal Clear
is used in non-risky projects, whereas Crystal Sapphire is
used in riskier ones to indicate the level of risk to human
life. Interaction, people, communication, community, talents,
and skills on Crystal focus are the six fundamental aspects
of nature. Process is the Crystal method’s secondary consid-
eration. Crystal’s reflective improvement, frequent delivery,
osmotic communication, and ease of access to experienced
users are characteristics that point to a greater likelihood of
success. The methods are flexible and non-rigid due to their
human-powered or people-centric focus. The Crystal family
of techniques uses color to indicate the ”weight” of which
methodology to apply. Crystal Sapphire or Crystal Diamond
are the division of colors in the Crystal family. Methodologies
like Crystal Clear, Crystal Yellow, Crystal Orange, or Crystal
Orange Web, Crystal Red, Crystal Maroon, Crystal Diamond,
and Crystal Sapphire are the division of colors in the Crystal
family. These methodologies can be used for small projects
or for critical projects that may be dangerous for human life.
This can be seen in Fig. 13.
Fig. 13. Crystal Methodology
1) Background
In 2001, Alistair Cockburn developed it. It places greater
emphasis on people than on procedures.
2) Philosophy and Scope
A collection of agile methods called ”Crystal methods” are
chosen based on project complexity and team size, and the
best way is customized for each unique project. More co-
ordination and more sophisticated techniques are probably
required for larger projects than for smaller ones. Four colors
are used to illustrate it: Red for extremely huge scale, Orange
for large size, Yellow for medium size, and Clear, which
emphasizes communication in small teams creating non-life-
critical software. Frequent delivery, reflective improvement,
close communication, attention, personal safety, ease of access
to knowledgeable users, and a technical environment featuring
automated testing, configuration management, and frequent
integration are all components of the crystal methods [17].
Projects are categorized based on team sizes using the Crystal
family of techniques, which is essentially a project manage-
ment philosophy. Because the approach serves as a foundation
for choosing and fine-tuning other techniques, it is somewhat
challenging to define the scope of Crystal.
3) Features and Benefits
Team size: Cockburn values premium individuals, but the
Crystal Family can fit any size team. The team size in Crystal
Clear can reach six developers. The number of developers on
the Crystal Orange team ranges from ten to forty. Systems that
are vital to life are not suited for crystal methods.
Length of iteration: Up to four months for big, important
projects.
Qualities: Regular supply, enhanced reflection, osmotic com-
munication, personal security, concentration, and simple ac-
cess to knowledgeable users Technical setting featuring con-
figuration management, automated testing, and regular inte-
gration
Techniques: Investigative 360°, Prompt triumph, Strolling
skeleton, Gradual reconstruction, Radiators of information
Methods: Delphi estimation using expertise ranking, Blitz
planning, Reflection workshop, Methodology shaping, stand-
up meetings every day, crucial interaction design, side-by-side
programming, and process miniature Burn diagrams
4) Roles and Responsibilities
 • Sponsor: Provides funding for the endeavor and issues
the mission statement.
• Senior Designer: upholds team hierarchy, applies tech-
niques, and creates system designs.
• Screen drafts, design sketches and notes, source code,
packaged systems, migration code, and test cases are all
produced by designers and programmers.
• User: Assists with screen and use case drafting.
• Business Expert: Could originate from senior designer,
sponsor, or user.
• Coordinator, Examiner, Composer: Could originate from
the designers. The following jobs are also organized into
teams at Crystal Orange: external test teams, architecture,
technology, functions, infrastructure, system planning,
project mentoring, and architecture.
5) Limitation
• Four fundamental criticalities are supported by crystal:
the loss of life, essential money, discretionary money, and
comfort due to failure.
J. Agile Unified Process (AUP)
Agile Unified Process (AUP) is a simplified version of
Rational Unified Process (RUP) for real-time and web-based
development. AUP combines RUP with AM (Agile Method).
DAD (Disciplined Agile Delivery) pressed AUP in 2012. AUP
utilizes TDD, AM, agile change management, and database
refactoring approaches to enhance productivity. AUP iteration
involves seven disciplines: model, implementation, testing,
deployment, configuration management, project management,
and environment. Within each discipline, Agile Unified Pro-
cess defines work product sets, roles, duties, and activities
for development team members.AUP consists of four phases:
Inception, Elaboration, Construction, and Transition. A refine-
ment to the Rational Unified Process highlights two types
of iterations: development, resulting in quality assurance and
demo area deployment, and production, resulting in production
area deployment.
Fig. 14. Agile Unified Process Phases
1) Background
The IBM Rational Unified Process (RUP), created by Scott
Ambler, has been condensed into the Agile Unified Process
(AUP). Originally presented in 2005 and updated in 2006 [18].
The primary improvements concentrate on web-based and real-
time development.
2) Philosophy and Scope
The AUP outlines a clear-cut, uncomplicated method for
creating business application software that adheres to the
RUP while utilizing agile approaches and concepts. The AUP
was replaced by Disciplined Agile Delivery in 2012. On the
evolution of AUP, no work has been done since.
To increase efficiency, the AUP uses agile practices like
database refactoring, agile change management, test driven
development (TDD), and agile modeling.
3) Features and Benefits
Disciplines: There are seven work areas or disciplines that
are completed in each iteration. Iterative disciplines define the
tasks that members of the development team carry out in order
to create, test, and deploy software that is functional and satis-
fies the needs of the stakeholders. These seven fields of study
are: Model, Implementation, Test, Deployment, Configuration
Management, Project Management, Environment.
AUP Philosophies: Your staff knows what they’re doing,
Simplicity, Agility, Focus on high-value activities, Tool inde-
pendence.
AUP Phases
The overall development cycle consists of four phases:
Inception, Elaboration, Construction, Transition.
AUP Releases
Two types of iterations are distinguished by the Agile
Unified Process: a production release iteration leads to a
deployment to the production area, and a development release
iteration results in a deployment to the quality-assurance
and/or demo area. This improves the Rational Unified Process
significantly.
4) Limitations
• The issue of model inconsistency is not specifically
discussed.
• If limitations are not properly adhered to, modeling may
jeopardize agility; in fact, there is a lengthy list of AUP
models that are produced as the absolute minimum.
V. A DVANTAGES AND L IMITATION OF AGILE M ODEL
A. Advantages:
• Performance improvement: Knowledge sharing and im-
provement occur in daily stand-ups. Discussion of tough
projects with simple story and design improves team-
work. Better and more frequent communication improves
team trust and productivity, increasing ROI.
• Design flexibility: The ability to change routes quickly
during project development. Agile design is flexible be-
cause it adapts quickly to changing requirements.
• Flexible: Agile software development iterates. Every iter-
ation requires analysis, design, development, and testing.
Customers and end users receive working software for
feedback after each iteration. Agile strategy incorporates
client modifications during software development to im-
prove it.
• Reduces development risks: Delivering updated little soft-
ware to users after each short development cycle and
 collecting user response alerts developers to potential
flaws. It swiftly detects and addresses errors.
• functional software: Agile development delivers tested,
functional software for reliability and user and technology
input. Agile methods leverage working software that pro-
vides more feedback, making projects easier to manage
and offering clients the best product through learning.
• Satisfies customers: Agile software development involves
customers. User receives deliverables after each iteration
for use and enhancement based on customer feedback
only. The program is high-quality and satisfying because
it is developed to customer needs.
• Avoids overproduction: Traditional system requirements
incorporate unnecessary functionality. Despite being low
on the backlog, Waterfall builds low-value features. Agile
builds the best product now.
• Limited software internal design documentation: Ag-
ile approach rarely documents software internal design.
Product features, iteration duration, and date are key doc-
uments, saving development time and speeding project
delivery.
• Fault detection: Business processes need bug-free soft-
ware. Continuous testing and integration with agile meth-
ods like XP create bug-free software. Each fourth iter-
ation checks for and repairs faults before they escalate.
Continuous integration, pair programming, and automated
tests find regression problems earlier. Continuous testing
helps improve future code.
• Best practises: Teams may employ competent, well-
tested applications across platforms and devices by in-
corporating Agile methodology. Agile commences with
“architecture killers”. Failure early is better than late
because most changes are cheap after spending money.
Agile software development benefits both the client and the
development team. Agile handles common project issues like
budget management, schedule predictability, and scope creep.
B. Disadvantages:
• Dealing with customers: Users and project teams must
collaborate in agile software development. Agile pays off
and ensures quality. The user representative must work
hard on these concepts throughout the project.
• Integration testing difficulty: To ensure quality without a
lengthy test process, testing is incorporated throughout
product development. Agile projects require testers, rais-
ing resource expenses. When a project overruns, a long,
unpredictable test period can be costly.
• rapid delivery: Agile supports rapid product delivery,
followed by User Acceptance Testing (UAT), which de-
mands the product owner to be ready to test features
quickly as they are supplied and throughout the project.
• Poor documentation: Agile saves time but damages
engineers. Project deadlines prevent extensive design
and implementation documentation since internal design
changes with every iteration based on users’ expectations.
• Helps management more than developers: Agile helps
management set software development goals, deadlines,
and decisions.
• Culture and co-located teams: Global application devel-
opment teams make face-to-face contact impossible. Most
engineers use video conferencing to deliver high-quality
products.
• Experienced resources: Only senior programmers can
make agile development decisions, frequently with ex-
perienced resources.
R EFERENCES
[1] D. N. M. S. V. TAPASKAR, “Enacted software development process
based on agile and agent methodologies,” International Journal of
Engineering Science and Technology, vol. 3, no. 11, 2007.
[2] D. D. Jamwal, “Analysis of software development models,” IJCST, vol.
1, no. 2, 2010.
[3] J. R. J. W. Pekka Abrahamsson, Outi Salo, “Agile software development
methods - review and analysis,” VTT Elektroniikka, 2002.
[4] W. R. Duncanillam, A Guide To The Project Management Body Of
Knowledge, 1996.
[5] W. Royce, Software Project Management:A Unified Framework, 1998.
[6] K. B. Marten Folwer, James A.Highsmith, Manifesto for Aigle Software
Development, http://agilemanifesto.org/, 11 2011.
[7] ”Agile Software Development,” [Online]. Available:
https://searchsoftwarequality.techtarget.com/definition/agile-software-
development
[8] P. M. Institute, Agile Practice Guide, Agile Alliance, 2017, pp. 8-9.
[9] K. Conboy, Agility From First Principles: Reconstructing the Concept
of Agility in Information Systems Development, Information Systems
Research, 2009, pp. 329-354.
[10] Beck, K. and C. Andres, “Extreme Programming Explained” (2nd
Edition), Addison-Wesley Professional, 2004.
[11] J. Highsmith, Agile Software Development Ecosystems. Addison Wes-
ley, 2002.
[12] M. G. M. Frank, ”Introducing agile methods: Three years of experience,”
IEEE, pp. 334-341, 2004.
[13] R. P. Pawar, “A Comparative study of Agile Software Development
Methodology and traditional waterfall model”, Innovation in engineering
science and technology, pp. 1-8, 2015.
[14] U. Kumari and A. Upadhyaya, “Comparative Study of Agile Methods
and Their Comparison with Heavyweight Methods in Indian Organi-
zations”, International Journal of Recent Research and Review,Vol.6 ,
2013.
[15] Shelly, “Comparative Analysis of Different Agile Methodologies”, In-
ternational Journal of Computer Science and Information Technology
Research, Vol. 3, Issue 1, pp. 199-203, 2015.
[16] Manvender Singh Rathore and Deepa V. Jose, “Oriental Journal of
Computer Science & Technology”, (2017), Vol. 10 (2), pp. 352-358.
[17] U. Kumari and A. Upadhyaya, “Comparative Study of Agile Methods
and Their Comparison with Heavyweight Methods in Indian Organi-
zations”, International Journal of Recent Research and Review,Vol.6 ,
2013.