Unlock the power of Agile methodologies with this concise overview. Delve into the core principles and practices of Agile, Scrum, Kanban, Extreme Programming (XP), and the Scaled Agile Framework (SAFe) in just a few slides.
Discover how Agile methodologies revolutionize project management, emphasizing adaptability, collaboration, and customer-centricity. Learn about Scrum's structured framework, Kanban's visualized workflow, XP's engineering practices, and SAFe's scalable enterprise implementation.
Explore the benefits and challenges each methodology brings, and gain insights into selecting the right approach for your projects. Real-world case studies offer a glimpse into successful Agile transformations. Join us to uncover the essentials of Agile methodologies in today's fast-paced business landscape
2. What is Agile?
• Agile is a mindset that allows a team to
more efficiently manage a project by
breaking it down into several stages, each
of which allows for consistent
collaboration with stakeholders to
promote steady improvements at every
stage.
• In software development, agile practices
involve discovering requirements and
developing solutions through the
collaborative effort of self-organizing and
cross-functional teams and their
customer/end user.
3. Agile 4 values
INDIVIDUALS AND
INTERACTIONS OVER
PROCESSES AND TOOLS
WORKING SOFTWARE OVER
COMPREHENSIVE
DOCUMENTATION
CUSTOMER
COLLABORATION OVER
CONTRACT NEGOTIATION
RESPONDING TO
CHANGE OVER FOLLOWING
A PLAN
4. What are the 12
principles of Agile?
Customer satisfaction
Early and continuous delivery
Embrace change
Frequent delivery
Collaboration of businesses and developers
Motivated individuals
Face-to-face conversation
Functional products
Technical excellence
Simplicity
Self-organized teams
Regulation, reflection and adjustment
6. Introduction to Scrum
Scrum is a lightweight framework that
helps people, teams and organizations
generate value through adaptive solutions
for complex problems.
Scrum is founded on empiricism and lean
thinking. Empiricism asserts that
knowledge comes from experience and
making decisions based on what is
observed. Lean thinking reduces waste and
focuses on the essentials.
Scrum employs an iterative, incremental
approach to optimize predictability and to
control risk. Scrum engages groups of
people who collectively have all the skills
and expertise to do the work and share or
acquire such skills as needed.
Scrum combines four formal events for
inspection and adaptation within a
containing event, the Sprint. These events
work because they implement the
empirical Scrum pillars of transparency,
inspection, and adaptation.
8. Pillars of
Scrum
• Transparency
The emergent process and work must be visible to those performing the
work as well as those receiving the work. With Scrum, important
decisions are based on the perceived state of its three formal artifacts.
Artifacts that have low transparency can lead to decisions that diminish
value and increase risk. Transparency enables inspection. Inspection
without transparency is misleading and wasteful.
Inspection
The Scrum artifacts and the progress toward agreed goals must be
inspected frequently and diligently to detect potentially undesirable
variances or problems. To help with inspection, Scrum provides cadence
in the form of its five events. Inspection enables adaptation. Inspection
without adaptation is considered pointless. Scrum events are designed
to provoke change.
Adaptation
If any aspects of a process deviate outside acceptable limits or if the
resulting product is unacceptable, the process being applied or the
materials being produced must be adjusted. The adjustment must be
made as soon as possible to minimize further deviation. Adaptation
becomes more difficult when the people involved are not empowered
or self-managing. A Scrum Team is expected to adapt the moment it
learns anything new through inspection.
9. Scrum Team
• Product owner: The Product Owner is accountable for maximizing the value of the product
resulting from the work of the Scrum Team. How this is done may vary widely across
organizations, Scrum Teams, and individuals. 6 The Product Owner is also accountable for
effective Product Backlog management, which includes:
● Developing and explicitly communicating the Product Goal;
● Creating and clearly communicating Product Backlog items;
● Ordering Product Backlog items;
● Ensuring that the Product Backlog is transparent, visible and understood.
• Scrum Master: 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. The Scrum Master is accountable for the Scrum Team’s
effectiveness. They do this by enabling the Scrum Team to improve its practices, within the
Scrum framework. Scrum Masters are true leaders who serve the Scrum Team and the larger
organization. The Scrum Master serves the Scrum Team in several ways, including:
● Coaching the team members in self-management and cross-functionality;
● Helping the Scrum Team focus on creating high-value Increments that meet the Definition of
Done;
● Causing the removal of impediments to the Scrum Team’s progress;
● Ensuring that all Scrum events take place and are positive, productive, and kept within the
timebox.
• Developers: Developers are the people in the Scrum Team that are committed to creating any
aspect of a usable Increment each Sprint. The specific skills needed by the Developers are often
broad and will vary with the domain of work. However, the Developers are always accountable
for:
● Creating a plan for the Sprint, the Sprint Backlog;
● Instilling quality by adhering to a Definition of Done;
● Adapting their plan each day toward the Sprint Goal;
● Holding each other accountable as professionals.
12. Scrum Artifacts
• Product Backlog
• The product backlog is an ordered list of everything that
is known to be needed in a product based on the product
goal. It is constantly evolving and is never complete.
• Sprint Backlog
• The sprint backlog is a list of everything that the team
commits to achieve in a given sprint. Once created, no one
can add to the sprint backlog except the development team.
• Potentially Releasable Product Increment
• At the end of every sprint, the team delivers a product
increment that is potentially releasable, meaning that it
meets their agreed-upon definition of done. (An example
might be fully tested and fully approved.)
14. Scrum Best Practices
• Define requirements just in time to keep product features as relevant
as possible.
• Test and incorporate product owner feedback daily.
• Sprint reviews with stakeholders need to be regular.
• The scrum team needs to use the sprint retrospectives to improve
how they work.
• Conduct face-to-face conversations to reduce miscommunications.
• Trust the teams to do the best job possible.
• Allow the teams to self-organize around people’s skills, work styles
and personalities.
• Don’t burn out the team members. Respect the balance between
their personal and professional lives to ease stress.
15. Introduction to Kanban
Kanban is a visual system used to manage and keep track of work as it moves through a
process. The word kanban is Japanese and roughly translated means “card you can see.”
What Are the Kanban Practices?
For a successful Kanban implementation, the method relies on six essential practices:
1.Visualizing the workflow: Creating a visual representation of the workflow helps to identify bottlenecks,
visualize the flow of work, and make the work more transparent.
2.Limiting work in progress: Limiting the amount of work in progress helps to prevent multitasking and
improve focus on completing one task at a time, thereby improving efficiency and reducing lead time.
3.Managing flow: Kanban aims to help in optimizing flow which can be achieved by monitoring flow metrics,
identifying and addressing bottlenecks, and continuously improving the workflow.
4.Making process policies explicit: Defining and communicating process policies clearly helps to ensure
that everyone understands how work is supposed to be done, which reduces misunderstandings and
promotes consistency.
5.Implementing feedback loops: Kanban emphasizes the importance of getting feedback from customers,
stakeholders, and team members as a way to identify areas for improvement.
6.Improving collaboratively: Kanban is a continuous improvement process that encourages collaboration
and experimentation to identify and solve problems, improve continuously, and evolve their processes to
better meet the needs of their customers.
16. Kanban board examples
You can configure the
board as per your
Project agreed
requirements. You can
combine multiple boards
as you like
17. Kanban vs.
Scrum
• Scrum and Kanban are
both iterative work systems
that rely on process flows and
aim to reduce waste.
However, there are a few
main differences between the
two.
Link: (for more info)
https://www.planview.com/r
esources/guide/introduction-
to-kanban/kanban-vs-scrum/
No. Attribute Scrum Kanban
1 Work cycle Iterations. Scrum has sprints within which the team follows the plan-do-check-act
(PCDA) cycle.
Complex, iterative work, like new product or feature development, may be better
done with scrum.
Continuous flow. In a kanban work cycle, as soon as one thing finishes, the team
takes another thing up.
Kanban is better for continuous flow work like support and services.
2 WIP - Work In Progress WIP limits are set by the scrum team for every sprint, and new work is picked up
only after all the work is completed.
If teams need a sense of accomplishment/completion/closure, use scrum.
WIP limit is ongoing. As soon as some work finishes, pickup new work.
If teams keep working on one thing after another, use kanban.
3 Inspect-Adapt (Empiricism) Every sprint is an opportunity to inspect and adapt. Work cycles through multiple
sprints for improvisation, if needed.
If the work continuously evolves and needs improvisation, use scrum.
No specific mechanism to inspect and adapt. Work flows in one direction.
If the work is a one-time effort, and doesn't require inspection and adaptation, use
kanban.
4 Transparency (Empiricism) Artifacts in scrum include the product backlog, sprint backlog, an increment.
Respectively provide requirements, implementation, and deliverables transparency.
If requirements need to be tracked separately from tracking the work in progress,
use scrum.
No specific artifacts for transparency. Kanban board provides some transparency.
Many teams use product backlog (from scrum) in combination with kanban
boards.
If only implementation needs to be tracked, use kanban.
5 Planning Specific events for planning the sprint and the day — sprint planning and daily
scrum.
Use scrum if disciplined planning at regular intervals is required.
No provision for planning the work. Teams adopt their own cadence and approach
to planning.
User kanban planning can be intermittent or on an as-needed basis.
6 Responsibility Accountabilities in scrum develop responsibility focus e.g. product owner for
business, developers for domain, and scrum master for impediments.
If teams need individuals focused on these responsibilities, use scrum.
There are no accountabilities like product owner, developers, etc. in kanban. It
assumes a group of individuals working on tasks.
If the team is simply a group of individuals with some expertise, use kanban.
7 Stakeholder/Customer Scrum has active stakeholder and customer involvement — at least once a sprint
during a sprint review event.
If the work is innovative, creative, or new and requires stakeholder and customer
feedback/engagement, use scrum.
Kanban does not provide a way to engage stakeholders or customers. Many teams
adopt a once-a-month “sprint review” approach.
If the work is mostly daily routine and does not require frequent stakeholder
engagement use kanban.
18. More
differences
SCRUM
KANBAN
Cadence
Regular fixed length
sprints (ie, 2 weeks)
Continuous flow
Release methodology
At the end of each sprint
if approved by the
product owner
Continuous delivery or at
the team's discretion
Roles
Product owner, scrum
master, development
team
No existing roles. Some
teams enlist the help of
an agile coach.
Key metrics Velocity Cycle time
Change philosophy
Teams should strive to
not make changes to the
sprint forecast during the
sprint. Doing so
compromises learnings
around estimation.
Change can happen at
any time
19. Introduction to XP
• Extreme programming is a software
development methodology that’s part of what’s
collectively known as agile methodologies. XP is
built upon values, principles, and practices, and its
goal is to allow small to mid-sized teams to produce
high-quality software and adapt to evolving and
changing requirements.
20. Scrum Vs.
XP
S. No. Scrum Extreme Programming (XP)
1.
In the Scrum framework, teamwork in iterations is called Sprint which is 2
weeks to 1 month long.
In Extreme Programming(XP), teamwork for 1-2 weeks only.
2. Scrum models do not allow changes in their timeline or their guidelines. Extreme Programming allows changes in their set timelines.
3. Scrum emphasizes self-organization. Extreme Programming emphasizes strong engineering practices
4.
In the Scrum framework, the team determines the sequence in which the
product will be developed.
In Extreme Programming, the team has to follow a strict priority order or
pre-determined priority order.
5.
The Scrum framework is not fully described. If you want to adopt it then
you need to fill the framework with your frameworks methods like
XP, DSDM, or Kanban.
Extreme Programming(XP) can be directly applied to a team. Extreme
Programming is also known for its Ready-to-apply features.
6.
Scrum does not put emphasis on software engineering practices that
developers should use.
Extreme Programming (XP) emphasizes programming techniques that
developers should use to ensure a better outcome.
7.
It requires developers to be conscious of adopting engineering methods to
ensure better progress or quality.
It is very strict in adopting engineering methods such as pair programming,
simple design, restructuring to ensure better progress or quality.
8.
In the preference of features, demand and priority do not have to be in line
with one another.
In the preference of features, the demand corresponds to the priority.
9.
In scrum, the scrum master asks the owner of the product to prioritize the
tasks according to their requirements.
In XP, customer decides the job priorities being the owner of the product
and then analyses the releases.
10.
The tasks are prioritized by the owner of the product but with the flexibility
that the priorities can be changed later on by the development team if
required.
The tasks are prioritized by the customer and the task priorities cannot be
changed by the development team.
11.
Values-
Openness
Focus
Commitment
Values-
Communication
Simplicity
Feedback
12. Customer involvement is less in the project. Customer involvement is more in the project.
21. Introduction to LeSS (Large Scale Scrum)
LeSS is a framework for scaling scrum to multiple teams who work together on a single product. It starts with a foundation of one scrum
team, as defined by Ken Schwaber and Jeff Sutherland in the Scrum Guide, and applies to multiple teams who work together on one
product.
Principles
LeSS defines 10 principles for applying the value, elements, and overall
purpose of scrum across an enterprise. They help create more responsible
teams with greater customer focus and collaboration. Teams focus on
learning, transparency, and delivering customer-centric values that product
organizations need to remain competitive and responsive. Here’s the
complete list:
•Large-Scale Scrum is scrum
•Empirical process control
•Transparency
•More with less
•Whole product focus
•Customer-centric
•Continuous improvement towards perfection
•Systems thinking
•Lean thinking
•Queuing theory
22. Introduction to
SAFe (Scaled Agile
Framework)
• SAFe Scrum is an Agile
methodology used by teams
within an ART to deliver
customer value in a short time
box. SAFe Scrum teams use
iterations, Kanban systems, and
Scrum events to plan, execute,
demonstrate, and retrospect
their work.
• SAFe Vs. LeSS: https://pm-
training.net/safe-vs-
less/#google_vignette
23.
24. Definitions
• Bottleneck: A bottleneck is any work stage within a project that stalls and holds up subsequent tasks and dependencies. Bottlenecks in project
management reduce the pace and capacity of the project or workflow
• Product Increment: a software product increment is what gets produced at the end of a development period or timebox.
• Technical Debt: it’s the result of prioritizing speedy delivery over perfect code.
• Cycle Time: amount of time taken to complete one task from start to finish
• Lead Time: Total time required to complete one unit of task
• Iteration: The amount of time set for development
• Swimlane: a horizontal categorization of issues in the Active sprints of a Scrum board, or on a Kanban board.
• Program Management: Program management is the process of managing programs mapped to business objectives that improve organizational
performance. Program managers oversee and coordinate the various projects and other strategic initiatives throughout an organization.
• Portfolio Management: enables organizations to align their strategy and investments with agile execution
• Burndown chart: A burndown chart or burn down chart is a graphical representation of work left to do versus time.
• System Demo: is a significant event that provides an integrated view of new Features for the most recent Iteration delivered by all the teams in the
Agile Release Train (ART).
25. Definitions
• Velocity: Velocity is the average amount of work a scrum team completes during a sprint. In team-managed Jira Software projects, this can be
measured in either story points or number of issues.
• Story Point: units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other
piece of work.
• Business Objective: the results you are aiming to achieve in order to accomplish your longer-term company vision
• PI Objective: summarize the business and technical goals that teams and trains intend to achieve in the upcoming PI and are either
committed or uncommitted
• Cadence: Cadence is a measure of work that is gauged across the whole project.
• PI Planning: Program increment planning is a face-to-face meeting of all the teams working in an Agile release train. The PI planning
event is used to discuss the product roadmap, decide on features, and identify dependencies within the teams.
• TDD: Test Driven Development (TDD) is a software development practice that focuses on creating unit test cases before developing the
actual code. It is an iterative approach combining programming, unit test creation, and refactoring.
• FDD: is a customer-centric software development methodology known for short iterations and frequent releases
• WIP limit: It is a cap on the number of tasks your team is actively working on
• Story Points: units of measurement used to determine how much effort is required to complete a product backlog item or any other piece
of work