Let's discuss about Agile manifesto and one the it's famous and most popular framework 'SCRUM'

1. LET’S PLAY
AGILE !
Atulya Krishna Mishra

2. ESSENCE OF AGILE ?
In the struggle for survival, the fittest win out at the
expense of their rivals because they succeed in adapting
themselves best to their environment.
—Charles Darwin

3. WHAT IS AGILE ?
Agile software development is a group of software
development methods based on iterative and
incremental development, where requirements
and solutions evolve through collaboration
between self-organizing, cross-functional teams.
It promotes adaptive planning, evolutionary
development and delivery, a time-boxed iterative
approach, and encourages rapid and flexible
response to change. It is a conceptual framework
that promotes foreseen interactions throughout
the development cycle
Source : Wikipedia

4. WHAT IS AGILE ?
 “Agility is the ability to both create and
respond to change in order to profit in a
turbulent business environment. Agility is
the ability to balance flexibility and
stability”
(Highsmith 2002).

5. AGILE UMBRELLA

6. AGILE MANIFESTO
In 2001, a group of 17 “lightweight" methodologists
met.
The meeting also included the representatives of
eXtreme Programming (XP)
Scrum
DSDM
Adaptive Software Development
ThE AGILE MAnIfESTo wAS
wrITTEn

7. AGILE MANIFESTO
 Facilitating change is more effective than attempting to prevent
it. Learn to trust in you ability to respond to unpredictable events;
its more important than trusting in your ability to plan for
disaster – Martin Fowler & Jim Highsmith
 As a result of the formation of the Agile Alliance in Feb 2001, 17
individuals came up with this manifesto
• Individuals and Interactions over processes and tools
• Working Software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
While we value the items on the right, we value the items on the
left more

8. AGILE PRINCIPLES
 Satisfying customer is top priority
 Welcome changing requirements, even late
in development
 Deliver working software frequently, from a
couple of weeks to a couple of months
 Development teams and business work together
 Build projects around motivated people
 The most efficient and effective method
of conveying information to and within a
development team is face-to-face conversation

9. AGILE PRINCIPLES
 The primary measure of success is working
software
 Agile processes promote sustainable
development – The sponsors, developers and
users should be able to maintain a constant pace
in definitively.
 Continuous attention to technical excellence and
good design
 Simplicity – the art of maximizing the amount of
work not done—is essential
 The best architectures, requirements and
designs emerge from self-organizing teams
 The Team regularly reflects on work

10. DOES AGILE REALLY WORKS ?

11. MYTHS ABOUT AGILE
 Myth#1 – Agile Development is undisciplined
 Myth#2 – Agile Teams do not plan
 Myth#3 – No Documentation, No Metrics
 Myth#4 – Compromise in Quality
 Myth#5 – Senior most people will lose their jobs
 Myth#6 – Self Organized Teams can do anything they
want
 Myth#7 – Design and Architecture can be ignored

12. Scrum
An Agile Perspective

13. SCRUM OVERVIEW
A play in Rugby in which the two sets of forwards mass together around
the ball and, with their heads down, struggle to gain possession of the ball.

14. EMPIRICAL PROCESS
The empirical model of process control provides
and exercises control through frequent inspection
and adaptation for processes that are imperfectly
defined and generate unpredictable and
unrepeatable outputs

15. DEFINED PROCESS
Laying out a process
that repeatable will
produce acceptable
quality output is
called defined
process control.

16. EMPIRICAL PROCESS CONTROL
3 Legs of Empirical Process Control:
Transparency - outcome must be visible to those
controlling
Inspection - various aspects must be inspected
frequently
Adaptation - must be adjusted if one or more aspects
of the process are outside acceptable limits

17. •Scrum is an agile process that allows us to focus on delivering the
highest business value in the shortest time.
•It allows us to rapidly and repeatedly inspect actual working
software.
•The business sets the priorities. Teams self-organize to determine
the best way to deliver the highest priority features.
•Every two weeks to a month anyone can see real working software
and decide to release it as is or continue to enhance it for another
sprint.
Scrum in 100 words

18. CHARACTERISTICS
Self-organizing teams
Product progresses in a series of month-long “sprints”
Requirements are captured as items in a list of “product
backlog”
No specific engineering practices prescribed
One of the “agile processes”

19. SCRUM OVERVIEW

20. SPRINTS
 Scrum projects make progress in a
series of “sprints”
o Analogous to Extreme Programming
iterations
 Typical duration is a calendar
month at most
 A constant duration leads to a
better rhythm
 Product is designed, coded, and
tested during the sprint

21. SCRUM FRAMEWORK
 3 Roles
o Product Owner (PO)
o Scrum Master (SM)
o Team
 4 Ceremonies
o Daily Scrum Meeting
o Sprint Review
o Sprint Planning
o Sprint Retrospective
 3 Artifacts
o Product Backlog
o Sprint Backlog
o Increment

22. SCRUM ROLES

23. PRODUCT OWNER
 Define the features of the product
 Decide on release date and content
 Be responsible for the profitability of the product (ROI)
 Prioritize features according to market value
 Adjust features and priority every iteration, as needed
 Accept or reject work results.

24. SCRUM MASTER
 Represents management to the project
 Responsible for enacting Scrum values and practices
 Removes impediments
 Ensure that the team is fully functional and productive
 Enable close cooperation across all roles and functions
 Shield the team from external interferences

25. SCRUM TEAM
 Typically 5-9 people
 Cross-functional
 QA, Programmers , UI Designers, etc.
 Members should be full-time
 May be exceptions (e.g., System Admin, etc.)
 Teams are self-organizing
 What to do if a team self-organizes someone
off the team??
 Ideally, no titles but rarely a possibility
 Membership can change only between sprints

26. SCRUM CEREMONIES

27. SPRINT PLANNING
 The Team and the Product Owner collaborate to help
the Team determine how much Product Backlog it can
turn into functionality during the upcoming Sprint.
 The Team create plans (Sprint Backlog) by identifying
tasks for converting selected Product Backlog into
functionality

28. SPRINT PLANNING
 Team selects items from the product backlog they can
commit to completing
 Sprint backlog is created
o Tasks are identified and each is estimated (1-16 hours)
o Collaboratively, not done alone by the Scrum Master
 High-level design is considered

29. DAILY SCRUM MEETING
 Goal
• Enable to team to share progress with each other
• Make visible blocks (impediments) daily for whole team to see
 Everyone stands in a circle and reports 3 things
• What did I do since the last Daily Scrum Meeting?
• What will I try to do by the next Daily Scrum meeting?
• What are my blockades?
 15 minutes maximum
 No discussion or debate: listening only
• After meeting ends, discuss and problem-solving can start
 Team and ScrumMaster only
• Team can invite PO or others if they wish, but it‘s up to the team
 After the meeting, ScrumMaster leads the removal of blocks

30. SPRINT REVIEW
Team presents what it accomplished during the sprint
Typically takes the form of a demo of new features or
underlying architecture
Informal
• 2-hour prep time rule
• No slides
Whole team participates
Invite the world

31. SPRINT RETROSPECTIVE
 Periodically take a look at what is and is not working
 Done after every sprint
 Participants
•Scrum Master
•Team
•Product owner (Optional)

32. SCRUM ARTIFACTS

33. PRODUCT BACKLOG
 The requirements
 A list of all desired work (Product Backlog Item) on the
project
 Ideally expressed such that each item has value to the
users or customers of the product
 Prioritized by the product owner
 Reprioritized at the start of each sprint

34. SPRINT BACKLOG
The Sprint Backlog defines the work the Team will
perform to turn Selected Product Backlog items into
a “Done” Increment.
The list emerges during the Sprint.
Each on going task identifies those responsible for
doing the work
Each Tasks has information about estimated
amount of work remaining on the task on any given
day during the Sprint.

35. INCREMENT
The Increment is the sum of all the Product
Backlog items completed during a Sprint and all
previous Sprints.
At the end of a Sprint, the new Increment must be
“Done,”
It must be in useable condition (Potentially
shippable product)

36. AGILE VS. TRADITIONAL
PROCESS

37. More Rigid and Directions coming Top
to Down
Team may conduct dozens of
experiments to see which works best
More Commanding and Controlling
style of Leadership
Communication flowing freely
between all the team members
Spoon Feeding; Management tell
everyone “What to Do”
Self-Organizing; work is distributed
with consensus by the Team itself
Planning Centric and Plan Driven
Plan could be very fluid in Agile
world as Agile projects are more
fluid then waterfall projects
Document Oriented and Document
Driven
Cross functional, Self-Contained
and Agile is ultimately pragmatic
Resistant to Change
Agile Projects are welcoming to
change; true even changes are
introduced late in the project
Traditional Framework Agile Framework

38. Customer get involved early in the
processes but tended to keep at
arm’s length once the project begins
Customer involvement is the key
here as more closely involved at the
time of work being performed
Escalation to managers when
problem arise
When problems occur, team works
together resolve them internally
Heavy upfront analysis and design
Daily stand-up meetings are held to
discuss work done yesterday, plan of
today and impediments if any
More serious about processes than
the product
Agile methods less focus on formal
and directive processes
Product is planned extensively and
then executed and tested
Work is delivered to client in small
and frequent releases to get rapid
feedback loops
Traditional models favors
“Anticipation”
Agile model favors “Adaption”
Traditional Framework Agile Framework

39. Team Commits so early in the project
before they can put their hands on
Daily Stand-Up meetings are held to
discuss work done yesterday, plan of
today and impediments if any
Heavy documentation before
executing the work packages
Agile Projects are highly democratic
and implement a series of short and
repeatable practices
Slow and structured development
process usually focus on one time
release
Agile is built on the concept of
frequent and small releases known as
“Incremental Delivery” in small
chunks
More focus on How than Why
Agile more focus on Why and
retrospective is held at the end of
each Iteration or Release
Ownership belongs only to the
Project Manager
Shared ownership
Traditional Framework Agile Framework