7 FLAVOURS OF AGILE

METHODOLOGY PRESENTED
BY THE CBC GUARDIAN GROUP
1. Scrum
2. Kanban
3. Lean
4. Extreme Programming (XP)
5. Crystal
6. Feature-Driven Development (FDD)
7. Dynamic Systems Development Method (DSDM)

• Each flavors has its own unique strengths and focus areas
• Organizations can adopt or combine different flavors based on needs and requirements
INTRODUCTION TO AGILE

• Agile is an iterative approach to project management and

software development
• Agile is a mindset and a collection of values, principles, and practices
• It's a way of thinking, being, and working that focuses on delivering
value early and often
• Agile emphasizes flexibility, collaboration, and continuous improvement
• Agile mindset focuses on collaboration, transparency, and a focus on
delivering value
• Agile methodologies are designed to deliver value to customers faster and
with higher quality
AGILE MANISFESTO
• In 2001, a group of software developers came together and created the
"Manifesto for Agile Software Development"
• This manifesto outlines the core values and principles of Agile
"The Agile Manifesto was created by software developers who recognized the
need for a more flexible, customer-centric approach to software development. It
formalized values and principles that challenged traditional, plan-driven methods
and promoted adaptive, collaborative practices to deliver value faster".

The Four Values of the Agile Manifesto

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
SCRUM
WHAT IS SCRUM?
• Scrum is a lightweight framework that helps people, teams and
organizations generate value through adaptive solutions for complex
problems.

• In lay terms, Scrum is a way to get work done as a team in small

pieces at a time, with continuous experimentation and feedback along
the way to learn and improve as you go. Scrum is an empirical
process, where decisions are built on transparency, inspection and
adaptation.
The Scrum Team:
The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within
a Scrum Team, there are no sub-teams or hierarchies. The Scrum Team is responsible for all
product-related activities from stakeholder collaboration, verification, maintenance,
operation, experimentation, research and development, and anything else that might be
required.
Developers are the people in the Scrum Team that are committed to creating any aspect of a
usable Increment each Sprint. They create a plan for the Sprint and the Sprint Backlog. They
maintain quality by adhering to a definition of Done.
The Product Owner is accountable for maximizing the value of the product resulting from the
work of the Scrum Team and is also in charge of effective Product Backlog management,
• The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.
They do this by helping everyone understand Scrum theory and practice, both within the
Scrum Team and the organization.
Scrum Events
Events are used in Scrum to create regularity and to minimize the need for meetings not defined in
Scrum.
Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events
of one month or less to create consistency. A new Sprint starts immediately after the conclusion of
the previous Sprint.
The Daily Scrum inspects progress made toward the Sprint Goal and adapts the Sprint Backlog as
necessary. It is a 15-minute event and it is held at the same time and place every working day of
the Sprint.
The Sprint Review inspects the outcome of the Sprint and determine future adaptations. The
Scrum Team presents the results of theVir work to key stakeholders and progress toward the
Product Goal is discussed.
• Sprint Retrospective aims to plan ways to increase quality and effectiveness. The Scrum Team
discusses what went well during the Sprint, what problems were encountered, and how those
problems were (or were not) solved.
Scrum Artifacts
Scrum artifacts represent work or value. They are designed to maximize transparency of key
information.
Each artifact contains a commitment to ensure it provides information that enhances transparency
and focus against which progress can be measured:
• For the Product Backlog, it is the Product Goal.
• For the Sprint Backlog, it is the Sprint Goal.
• For the Increment, it is the definition of Done.
•
• - The Product Backlog is an emergent, ordered list of what is needed to improve the product.
• -The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items
selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
- An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to
all prior Increments and thoroughly verified, ensuring that all Increments work together.
Did you know?
Some of our everyday brands use Scrum!
• Google
• Apple
• Facebook
• Yahoo
• Spotify
• Adobe
• AirBnB
• Amazon
• HSBC
• Netflix
• Lego
• Ryanair
• Siemens
 • XP = Extreme Programming
• Extreme Programming (XP) is one of the 7 agile software development
methodologies emphasizing customer satisfaction, teamwork, and
continuous improvement. XP aims to deliver high-quality software

What is XP quickly and efficiently by fostering communication, collaboration, and

adaptability.
• It is called extreme because it promotes productivity and assures
efficient implementation of concepts and values.
History of XP

• Kent Beck introduced XP in the 1990s, intending to

discover methods to write high-quality software quickly
and to be able to adapt to changing customer requirements.
• Beck was a software developer frustrated with the
waterfall methodology. He believed that the waterfall
methodology needed to be more flexible and inflexible and
did not allow for the rapid changes often required in
software development.
• Kent Becks Definition “XP is a lightweight methodology
for small- to medium-sized teams developing software in
the face of vague or rapidly changing requirements,”
Key Principles
• Communication: Clear and constant communication between team
members and stakeholders to ensure everyone is aligned and informed.
• Simplicity: Focus on the simplest solution that works, avoiding
unnecessary complexity.
• Feedback: Continuous feedback from tests, customers, and team
members to improve the product and processes.
• Courage: The ability to make changes and take necessary actions
without fear, such as refactoring code or addressing issues directly.
• Respect: Mutual respect among team members, valuing each other's
contributions and promoting a collaborative environment.
 Core Practices
• Planning Game: Involves customers and developers working together to define and prioritize the features
to be developed in the next iteration.
• Small Releases: Releasing small, functional pieces of software frequently to get early feedback from users.
• Metaphor: Using a simple, shared story or metaphor to guide the overall design and architecture of the
system.
• Simple Design: Creating the simplest possible design that works for the current requirements.
• Testing: Writing automated tests for all code to ensure functionality and enable continuous integration.
• Refactoring: Continuously improving the codebase without changing its functionality to keep it clean and
maintainable.
• Pair Programming: Two developers work together at one workstation, collaborating on the same code to
improve quality and share knowledge.
• Collective Code Ownership: All team members share responsibility for the codebase, encouraging
collaboration and reducing bottlenecks.
• Continuous Integration: Integrating and testing code frequently to detect and address issues early.
• Sustainable Pace: Working at a pace that can be maintained indefinitely without burnout, typically no
more than 40 hours per week.
• Customer On-Site: Having a real customer available full-time to provide feedback and make decisions
about the product.
• Coding Standards: Adhering to consistent coding practices to ensure readability and maintainability of the
codebase.
PROS AND CONS
PROS

• Higher Quality Software: XP aims to produce high-quality software that meets customer needs.

• Flexibility: The iterative approach and continuous feedback allow for rapid response to changing requirements.

• Improved Collaboration: Emphasis on communication and teamwork fosters a collaborative environment.

• Reduced Risk: Frequent releases and continuous integration help identify and mitigate risks early in the development
process.

CONS

• Code overcomes design: The focus of XP is the code rather than the design. The design is what sells the application, so the
customer could be unhappy with the end product if the design is not good enough.

• Location: XP projects are difficult to implement when the customer is away from the developmental team. Typically the
XP interactions are successful when the team members meet face to face which can be a restriction.

• Lack of documentation: The constant changes cannot be documented properly. Thus, there are high risks of unexpected
failures that cannot be tracked. Even when bugs are fixed, without accurate documentation it’s possible that the same errors
can recur.

• Stress: There is a lot of pressure working with tight deadlines. If the developers have high stress levels completing tasks on
time, they are more likely to make mistakes while coding. Subsequently, software quality could be reduced due to the
scheduling.
CRYSTAL
 Crystal is an agile framework that focuses on individuals
and their interactions, as opposed to processes and tools.
Crystal method was developed in 1991 by Alistair
Cockburn for IBM. He set out to create a lighter weight,
CRYSTAL more adaptive approach centred around the idea that each
project and team has unique characteristics that call for
AGILE tailored processes.

FRAMEWOR • Crystal recognizes that each project is unique and team

performance hinges on a number of different factors,
K primarily:
• Team size: How many team members are working on
the project?
• Criticality: How imperative are the results of the
project? Is it life or death?
• Priority: Where does the project rank? Is it a higher
priority than other work?
The Crystal Family
PROPERTIES of CRYSTAL
Frequent Delivery STRENGTHS WEAKNESSES

Reflective Improvement • Flexibility • Complexity

• People-centric • Lack of prescriptive
• Incremental progress guidance
Osmotic Communication • Tailored solutions • Not a one size fits all

Personal Safety

Focus on work

Access to experts and users

Technical tooling
FEATURE-DRIVEN Focuses on developing software with

DEVELOPMENT featuresthat satisfy client needs.

 FDD

PROS CONS
• Focused scope • Complexity
• Early and frequent delivery • Requires investment in Time and
• Improved communication resources
• Creation of Dependencies
LEAN
 • Lean concept originated from the principle of Lean
manufacturing that was made famous by Toyota back in the
1980s.
• Lean is an agile methodology that focuses mainly on
maximizing value to the customer while eliminating waste
along the way.
LEAN • There are five key principles that underpinned the process
• value, value streams, flow, pull, perfection
• Lean is obtained by continuous improvement - KAIZEN
Lean Principles
Eliminate Waste

• Lean focuses on eliminating waste, cutting costs and improving overall efficiency.
• What is Waste: Waste is any activity, product or services that does not add value to the
customer.
•Lean Facts
• Eliminating waste across the value stream.
• Manage the flow of ideas, product and effort.
• Iterative and incremental based on customer feedback
• Function as just -in-time , no need for extensive planning
KANBAN
DSDM
Dynamic Systems Development Methods
(DSDM)
This is an agile method that focuses on the whole project life cycle
and places emphasis on governance. DSDM was born out of need
by businesses to replace rigid and unreliable software
development methods with a framework that would help to
deliver rapid, robust and responsive(3Rs) project that is both
timely and budget friendly. DSDM is adaptable to address projects
of all sizes and suitable for any business sector
The underlined philosophy of DSDM stipulates that any project
must be aligned to clearly defined strategic goals
while focusing on delivering early real values to
businesses through upfront consideration of cost, quality and
time constraints. This is done by adopting the MoSCoW features
(Must have, Should have, Could have and Won’t have) scope
of prioritization.

Principles of DSDM
Eight principles underpinning the DSDM approach