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
