The Agile methodologies outlined below share much of the same overarching philosophy, as well as

many of the same characteristics and practices. From an implementation standpoint, however, each

has its own unique mix of practices, terminology, and tactics.

The most widely-used Agile methodologies include:

● Agile Scrum Methodology
● Lean Software Development
● Kanban
● Extreme Programming (XP)
● Crystal
● Dynamic Systems Development Method (DSDM)
● Feature Driven Development (FDD)

Agile Scrum Methodology

Scrum​ is a lightweight Agile project management framework that can be used to manage iterative and

incremental projects of all types. It has gained increasing popularity over the years due to its simplicity,

proven productivity, and ability to incorporate various overarching practices promoted by other Agile

models.

In Scrum, the Product Owner works closely with their team to identify and ​prioritize system

functionality by creating a Product Backlog​. The Product Backlog consists of whatever needs to be

done to successfully deliver a working software system, including features, bug fixes, ​non-functional

requirements​, etc. Once priorities have been established, cross-functional teams will estimate and

sign-up to deliver “potentially shippable increments” of software during successive Sprints, typically

lasting 30 days. Once a Sprint’s Product Backlog is committed, no additional functionality can be

added to the Sprint except by the team. Once a Sprint has been delivered, the Product Backlog is

analyzed and reprioritized, if necessary, and the next set of deliverables is selected for the next Sprint.
Organizations are even looking to ​apply Agile Scrum principles to their RPA (Robotic Process

Automation)​ initiatives to implement automation at scale. Adopting Agile Scrum principles gives RPA

teams or RPA Centers of Excellence the flexibility to design and optimize business processes to be

automated upfront, maintain an efficient backlog of work that promotes innovation, and implement

constant learning to scale end-to-end automation.

Lean Software Development

Lean Software Development ​is an iterative Agile methodology that focuses the team on delivering

value to the customer through effective value stream mapping. It is a highly flexible, evolving

methodology without rigid guidelines, rules, or methods.

The main principles of the Lean methodology include:

● Eliminating Waste
● Amplifying Learning
● Deciding as Late as Possible
● Delivering as Fast as Possible
● Empowering the Team
● Building Integrity In
● Seeing the Whole

Lean development eliminates waste by asking users to ​select only the truly valuable features for a

system​, prioritize those features, and then work to deliver them in small batches. It relies on rapid and

reliable feedback between programmers and customers, emphasizing the speed and efficiency of

development workflows. Lean uses the idea of a work product being “pulled” via customer request. It

gives decision-making authority to individuals and small teams since this has been proven to be a

faster and more efficient method than a hierarchical flow of control. Lean also concentrates on the

efficient use of team resources, trying to ensure that everyone is as productive as possible for the

maximum amount of time. It strongly recommends that automated unit tests be written at the same

time the code is written.

Kanban
Kanban​ is a ​highly visual workflow management method​ that is popular among Lean teams. In fact,

83% of teams practicing Lean use Kanban to visualize and actively manage the creation of products

with an emphasis on continuous delivery, while not adding more stress to the software development

life cycle. Like Scrum, Kanban is a process designed to help teams work together more effectively.

Kanban is based on 3 basic principles:

● Visualize what you’ll do today (workflow automation):​ Seeing all the items within the
context of each other can be very informative
● Limit the amount of work in progress (WIP):​ This helps balance the flow-based approach so
teams don‘t start and commit to too much work at once
● Enhance flow:​ When something is finished, the next highest priority item from the backlog is
pulled into play

Kanban promotes continuous collaboration and encourages active, ongoing learning and improvement

by defining the best possible team workflow.

Extreme Programming (XP)

Extreme Programming​ (XP), originally described by Kent Beck, has emerged as one of the most

popular and controversial Agile models. XP is a disciplined approach for high-quality agile software

development, focused on speed and continuous delivery. It is intended to improve software quality and

responsiveness in the face of changing customer requirements​. It promotes high customer

involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to

deliver working software at very frequent intervals, typically every 1-3 weeks.

The methodology takes its name from the idea that the beneficial elements of traditional software

engineering practices are taken to “extreme” levels. As an example, code reviews are considered a
beneficial practice. Taken to the extreme, code can be reviewed continuously through the practice of

pair programming.

The original XP method is based on four simple values: simplicity, communication, feedback, and

courage.

It also has twelve supporting practices:

● Planning Game
● Small Releases
● Customer Acceptance Tests
● Simple Design
● Pair Programming
● Test-Driven Development
● Refactoring
● Continuous Integration
● Collective Code Ownership
● Coding Standards
● Metaphor
● Sustainable Pace

Don Wells has depicted the XP process in this ​popular diagram:

In XP, the

customer works closely with the development team to define and prioritize user stories. The

development team estimates, plans, and ​delivers the highest priority user stories​ in the form of
working, tested software on an iteration-by-iteration basis. In order to maximize productivity, the

practices provide a supportive, lightweight framework to guide a team and ensure high-quality

enterprise software.

Crystal
The Crystal methodology​ is one of the most lightweight, adaptable approaches to software

development.

Crystal is actually comprised of a family of Agile process models, including Crystal Clear, Crystal

Yellow, Crystal Orange and others. Each has unique characteristics driven by several factors, such as

team size, system criticality, and project priorities. This Crystal family addresses the realization that

each project may require a slightly tailored set of policies, practices, and processes in order to meet

the product ‘s unique characteristics.

Introduced by Alistair Cockburn, Crystal focuses primarily on people and the interaction among them

while they work on an agile software development project. There is also a focus on business-criticality

and ​business-priority of the system under development​.

Unlike traditional development methods, Crystal doesn’t try to fix the tools and techniques of

development but keeps people and processes at the core of the process. However, it is not only the

people or the processes that are important, rather the interaction between them that is most important.
Several key tenets of Crystal include teamwork, communication, and simplicity, as well as reflection to

frequently adjust and improve the process. Like other Agile frameworks, Crystal promotes early,

frequent delivery of working software, high user involvement, adaptability, and the removal of

bureaucracy or distractions.

Dynamic Systems Development Method (DSDM)

The Dynamic Systems Development Method​ (DSDM) is an Agile approach that grew out of the need

to provide a common industry framework for ​rapid software delivery​. Since 1994, the DSDM

methodology has evolved to provide a comprehensive foundation for planning, managing, executing,

and scaling Agile process and iterative software development projects.

DSDM is based on eight key principles that direct the team and create a mindset to deliver on time

and within budget. These agile principles primarily revolve around business needs/value, active user

involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration.

DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and

acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the

time.

Compromising any of the following principles undermines the philosophy of DSDM and ​introduces risk

to the successful outcome of the project​.

DSDM’s Eight Key Principles:

1. Focus on the business need
2. Deliver on time
3. Collaborate
4. Never compromise quality
5. Build incrementally from firm foundations
6. Develop iteratively
7. Communicate continuously and clearly
8. Demonstrate control

Business Requirements are baselined at a high level early on in the project. Rework is built into the

process, and all development changes must be reversible. System requirements are planned and

delivered in short, fixed-length time-boxes – also known as sprints or iterations – and prioritized using

MoSCoW Rules.

MoSCoW Rules:

M​ – Must have requirements

S​ – Should have if at all possible

C​ – Could have but not critical

W​ – Won‘t have this time, but potentially later

All critical work must be completed in a DSDM project’s defined time-box. It is also important that not

every requirement in a project or time-box is considered critical. Within each time-box, less critical

items are also included so that they can be removed to keep from impacting higher priority

requirements on the schedule.

Feature Driven Development (FDD)

Feature Driven Development ​is a model-driven, short-iteration process that was built around software

engineering best practices such as domain object modeling, developing by feature, and code
ownership. The blending of these practices that resulted in a cohesive whole is the best characteristic

of FDD.

Feature Driven Development consists of five basic activities:

● Development of an overall model
● Building a feature list
● Planning by feature
● Designing by feature
● Building by feature

FDD begins by establishing an overall model shape, which will result in a feature list. It then continues

with a series of two-week “plan by feature, design by feature, build by feature” iterations. The features

are small, “useful in the eyes of the client” results. If they will take more than two weeks to build, then

they will have to be broken down into smaller features.

FDD’s main purpose is to deliver tangible, working software in a timely manner, repeatedly. The

advantage of using FDD is that it is scalable even to large teams due to the concept of ‘just enough

design initially’ (JEDI). Because of its feature-centric process, FDD is a great solution to maintain

control for incremental and inherently complex Agile project management.

Agile development methodologies grew out of the real-life experiences of software professionals who

were tired of the challenges and limitations of the traditional waterfall methodology. The Agile

approach is promoted by a direct response to the issues associated with traditional software

development – both in terms of overall philosophy as well as specific processes.

Although there are many benefits of an Agile model, there are also a number of common challenges

that prevent many teams from successfully scaling Agile processes out to the Enterprise level
Benefits of Agile Development
Agile is a powerful tool for software development. It not only provides process and efficiency benefits

to the development team, but also a number of important business benefits to the organization as a

whole. Agile helps product teams deal with many of the most common project pitfalls (such as cost,

schedule predictability and scope creep) in a more controlled manner. By reorganizing and

re-envisioning the activities involved in custom software development, Agile achieves those same

objectives in a leaner and more business-focused way.

Here are the 9 primary benefits of an Agile methodology:

1. Improved Quality
One of the greatest benefits of an Agile framework is improved product quality. By breaking down the

project into manageable units, the project team can focus on high-quality development, testing, and

collaboration. Also, by producing frequent builds and conducting testing and reviews during each

iteration, quality is improved by finding and fixing defects quickly and identifying expectation

mismatches early.

By adopting Agile software development practices, organizations can deliver solutions on time and

with a higher degree of client and customer satisfaction. By incorporating the ability to change, they

are better able to incorporate feedback from demos, usability testing, and customers into the product.

2. Focus on Business Value

Another one of the primary benefits of Agile is an increased focus on delivering strategic business

value by involving business stakeholders in the development process. By doing so, the team
understands what’s most important and can deliver the features that provide the most business value

to their organization.

3. Focus on Users
Agile development uses user stories with business-focused acceptance criteria to define product

features. By focusing features on the needs of real users, each feature incrementally delivers value,

not just an IT component. This also provides the opportunity to beta test software after each Sprint,

gaining valuable feedback early in the project and providing the ability to make changes as needed.

4. Stakeholder Engagement
An Agile process provides multiple opportunities for stakeholder and team engagement – before,

during, and after each Sprint. By involving the different types of stakeholders in every step of the

project, there is a high degree of collaboration between teams. This provides more opportunities for

the team to truly understand the business’ vision, deliver working software early, and frequently

increases stakeholders’ trust. Stakeholders are encouraged to be more deeply engaged in a project

since trust has been established in the team’s ability to deliver high-quality working software.

5. Transparency
Another benefit of Agile software development is that it provides a unique opportunity for clients or

customers to be involved throughout the project. This can include prioritizing features, iteration

planning and review sessions, or frequent software builds containing new features. However, this also

requires customers to understand that they are seeing a work in progress in exchange for this added

benefit of transparency.
6. Early and Predictable Delivery
By using time-boxed, fixed schedule Sprints of 1-4 weeks, new features are delivered quickly and

frequently, with a high level of predictability. This also provides the opportunity to release or beta test

the software earlier than planned if there is sufficient business value.

7. Predictable Costs and Schedule

Because each Sprint is a fixed duration, the cost is predictable and limited to the amount of work that

can be performed by the team in the fixed-schedule time box. Combined with the estimates provided

prior to each Sprint, the ​company can more readily understand the approximate cost of each feature​,

which improves decision making about the priority of features and the need for additional iterations.

8. Allows for Change

Another key benefit of an Agile methodology is that, unlike a Waterfall model, it allows for change.

While the team needs to stay focused on delivering an agreed-to subset of the product’s features

during each iteration, there is an opportunity to constantly refine and reprioritize the overall product

backlog. New or changed backlog items can be planned for the next iteration, providing the

opportunity to introduce changes within a few weeks.

9. Promotes RPA at Scale

Lastly, a key benefit of ​applying an Agile methodology to RPA (Robotic Process Automation) initiatives

is that it facilitates automation at scale​. Agile principles like dedicated teams, upfront design,

maintaining a backlog, and sprint planning and retrospectives, give automation teams the flexibility

and control to govern and develop complex, end-to-end processes at scale, at a much more efficient

and effective rate than a traditional waterfall approach does.

 Challenges of Agile Development
Although there are many benefits of Agile software development, there are also a number of

common challenges that prevent many teams from successfully scaling Agile processes out to

the enterprise level. In ​Forrester’s State of Agile 2017: Agile at Scale​ development study, both

large and small firms cited the following as the top 3 barriers to Agile adoption:

1. People’s behavioral change:

Changing the way people work is difficult — the habits and culture of a large development

organization are typically deeply ingrained. People naturally resist change, and when

confronted with an Agile transformation, you may often hear people say things like, “that’s the

way we’ve always done it around here,” or “that won’t work here.” Accepting change means

accepting the possibility that you might not currently be doing things the best way, or even

worse, it may challenge a person’s long-held values. It’s easy for people to keep their old

behaviors and processes—​unless there is an exceptionally good reason to make a change​.

2. Lack of skilled product owners from the business side:

The Business Requirements Document (BRD) has been used for decades. Yes, it has its

shortcomings, but it’s familiar. Most of the people involved in requirements – primarily business

stakeholders and Business Analysts (BAs) – ​are new to Agile​. They don’t understand user

stories and hesitate to give up the BRD for something different because they view it as a

contract between them and IT. How will they be able to control the direction of development

without that contract?

Additionally, most Agile software development teams use an ALM tool, which is where user

stories need to end up for decomposition into development tasks. Most business stakeholders
 and BAs, on the other hand, still use Microsoft Word and Excel to author requirements. This

tool mismatch stifles the cross-departmental collaboration teams ​need to realize the full benefits

of Agile​.

3. Lack of dedicated cross-functional teams:

The language used in the principles behind the ​Agile Manifesto​—which refer to the technical

members of the Agile team as “developers”—has led many to think that only developers, or

what many people think of as ‘coders,’ are needed within an Agile team. However, the

Manifesto’s guidelines use the word developer to mean “product developer”—any

cross-functional role that helps the team deliver the product.

According to the ​Scrum Guide​, a cross-functional team is a team that is organized around

customer value stream mapping and must include all competencies needed to accomplish their

work without depending on others that are not part of the team. These teams deliver products

iteratively and incrementally, maximizing opportunities for feedback and ensuring a potentially

useful version of working product is always available.

Although cross-functional teams are certainly not a new idea, ​they’re still an idea that many

organizations are still struggling to absorb

https://www.blueprintsys.com/agile-planning