AGILE

SOFTWARE
DEVELOPMENT
Submitted By:
SHASHVAT
GUPTA
1302710151
WATERFALL MODEL
AGILE MODEL
AGILE MODEL
AGILE MODEL
INTRODUCTION TO AGILE
Agile software development refers to a group
of software development methodologies that
are based on similar principles. Agile
methodologies generally promote:
A project management process that encourages
frequent inspection and adaptation.
A leadership philosophy that encourages team
work, self-organization and accountability.
A set of engineering best practices that allow
for rapid delivery of high-quality software and a
business approach that aligns development
with customer needs and company goals.
WHY THEY MOVE TO AGILE MODEL
Projects too long to estimate accurately
Increase short-term predictability
Transparency
Flexibility
Agile builds empowered, motivated and self
organizing teams
Clear expectations are set and communicated
Customers communicate directly with the team
and provide timely feedback
Teams feels a sense of accomplishment and
recognition
MANIFESTO FOR AGILE SOFTWARE
DEVELOPMENT
Individuals and interactions over processes
and tools

Working software over comprehensive

documentation

Customer collaboration over contract

negotiation

Responding to change over following a plan

PRINCIPLES OF AGILE
Customer satisfaction by rapid,
continuous delivery of useful software
Working software is delivered frequently
(weeks rather than months)
Working software is the principal
measure of progress
Even late changes in requirements are
welcomed
Close, daily cooperation between business
people and developers
 Face-to-face conversation is the best form of
communication (Co-location)
Projects are built around motivated
individuals, who should be trusted
Continuous attention to technical excellence
and good design
Simplicity
Self-organizing teams
Regular adaptation to changing circumstances
INTRODUCTION TO AGILE
METHODOLOGIES
SCRUM(most popular)
It is an iterative process of development used
with agile software development. The roles in
Scrum are the Scrum Master, the Product
Owner and the Team.
During each sprint the team creates an
increment of potential shippable software. The
set of features that go into each sprint come from
the product backlog.
Which backlog items go into the sprint is
determined during the sprint planning meeting.
The team then determines how much of this they
can commit to complete during the next sprint.
THE PEOPLE INVOLVED
PRODUCT OWNER
Single person responsible for maximizing the
return on investment (ROI) of the development
effort
Final arbiter of the requirement questions
Focused more on what than how
Decides whether to release
Decides whether to continue development
SCRUM DEVELOPMENT TEAM
Cross-functional group(e.g., includes members
with testing skills, and others not traditionally
called developers: business analysts, designers,
domain experts, etc.)
Attempts to build a potentially shippable
product increment every Sprint
Self-organizing / self-managing, without
externally assigned roles
Most successful when located in one team room,
particularly for the first few Sprints
6 3 members
SCRUM MASTER
Has no management authority
Doesnt have a project manager role
Facilitator: Ensures Scrum is understood and
enacted
Creates an environment conducive to team self-
organization
Shields the team from external interference and
distractions to keep it in group flow
Promotes improved engineering practices
WHAT IS A BACKLOG?
A backlog is the master list of all functionality
Features
Epics
Stories
Requirements
Bugs

Item Attributes:
Description
Cost estimate (story points or size)
Business Value
Priority
PRODUCT BACKLOGS VS. SPRINT
BACKLOGS
A Product Backlog is the master list of all
customer-centric features prioritized by the product
owner.
Epics
Stories
Use-case scenarios
The Sprint Backlog is the list of functionality that
the team is committing that they will complete in
the current iteration. It has an end date.
Consists of selected PBIs negotiated between the team
and the Product Owner during the Sprint Planning
Meeting.
No changes are made during the Sprint that would
endanger the Sprint Goal.
Initial tasks are identified by the team during Sprint
Planning Meeting.
MEETINGS IN SCRUM
SPRINT PLANNING MEETING
At the beginning of each Sprint, the Product
Owner and team hold a Sprint Planning Meeting
to negotiate which Product Backlog Items they
will attempt to convert to working product during
the Sprint.
The Product Owner is responsible for declaring
which items are the most important to the
business.
The Development Team is responsible for
selecting the amount of work they feel they can
implement without accruing technical debt.
The team pulls work from the Product Backlog
to the Sprint Backlog.
DAILY SCRUM
Every day at the same time and place, the Scrum
Development Team members spend a total of 15
minutes inspecting their progress towards the
Sprint goal, and creating a plan for the day.
Team members share with each other what they
did the previous day to help meet the Sprint goal,
what theyll do today.
The Daily Scrum is intended to disrupt old habits
of working separately.
Members should remain vigilant for signs of the
old approach which means they have to learn to
operate as a self-organizing entity.
SPRINT REVIEW MEETING
At the end of the Sprint, the Scrum Team holds a
Sprint Review Meeting to demonstrate a working
product increment to outside stakeholders.
The meeting should feature a live demonstration, not
a report.
The Product Owner reviews the items selected during
the Sprint Planning Meeting and explains which
items are considered done.
For example, a software item that is merely code
complete is considered not done, because untested
software isnt shippable.
The Scrum Master helps the Product Owner and
stakeholders convert their feedback to new Product
Backlog Items for prioritization by the Product
Owner.
SPRINT RETROSPECTIVE MEETING
The team reflects on its own process.
They inspect their behavior and take action to
adapt it for future Sprints.
CONCLUSION
o The Scrum method is an agile method that
provides a project management framework. It is
centred round a set of sprints, which are fixed
time periods when a system increment is
developed.
o Scaling agile methods for large systems is
difficult.
o Only senior programmers are capable of taking
the kind of decisions required during the
development process. Hence it has no place for
newbie programmers, unless combined with
experienced resources.
RESOURCES
CollabNET(https://www.collab.net/)
Introduction to scrum videos
Scrum Reference card checklist
Agile Advice (http://www.agileadvice.com/)
Implementing Scrum
(http://www.implementingscrum.com/)
Mike Cohn's Blog Succeeding With Agile
(http://blog.mountaingoatsoftware.com/)
THANK YOU