AGILE PROCESS
INTRODUCTION
Author: Nguyen Phuc Hai
Created date: 1/7/2008

Agenda
Introduction
Software Development Process
Software Development Life Cycle
Waterfall model
Iterative model
Rational Unified Process (RUP)
Agile Development Process (ADP)
Scrum process

Software Development Process
Software Development Life Cycle
Waterfall model
Iterative model
Rational Unified Process (RUP)
Agile Development Process (ADP)

Why we need process

Software Development Life Cycle

Software Development Process
Software Development Life Cycle
Waterfall model
Iterative model
Rational Unified Process (RUP)
Agile Development Process (ADP)

Introduction

Definitions
The waterfall model is a sequential software
development model (a process for the creation of
software) in which development is seen as flowing
steadily downwards through the phases of
requirements, analysis, design, implementation,
testing and maintenance.

Waterfall usage
Advantages
High reliable product
Reduce risk
Clear scope and contract
Disadvantages
Much over cost, resource and schedule
Lack of product can apply Waterfall (except small and
short-duration projects)
Specific skill sets are required for each phase

Software Development Process
Software Development Life Cycle
Waterfall Model
Iterative Model
Rational Unified Process (RUP)
Agile Development Process (ADP)

Introduction

Definitions
Iterative and Incremental development is a cyclical
software development process developed in
response to the weaknesses of the waterfall model.
Iterative development slices the deliverable
business value (system functionality) into
iterations. In each iteration a slice of functionality is
delivered through cross-discipline work, starting
from the model/requirements through to the
testing/deployment

Usage
Advantages:
Optimize cost, schedule and resource than waterfall
model
Incrementally delivery business value
Continuously improve product quality (requirements,
design, code, test) via regularly feedback and learning
knowledge

Software Development Process
Software Development Life Cycle
Waterfall Model
Iterative Model
Rational Unified Process (RUP)
Agile Development Process (ADP)

Iterative Model Graph

Phases and Iterations
RUP life cycle organizes the tasks via phases and
iterations.
RUP has four phases:
Inception
Elaboration
Construction
Transition

Static Structure of the Process
The process describes who is doing what, when and
how. RUP uses the 4 modeling elements:
Workers, the ‘who’
Artifacts, the ‘what’
Activities, the ‘how’
Workflows, the ‘when’

Software Development Process
Software Development Life Cycle
Waterfall Model
Iterative Model
Rational Unified Process (RUP)
Agile Development Process (ADP)
Agile Manifesto
Agile Principles

Manifesto of ADP
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
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even
late in development. Agile processes harness
change for the customer's competitive advantage.
Deliver working software frequently,
from a couple of weeks to a couple of months, with
a preference to the shorter timescale.

Principles of Agile (continue)
Business people and developers must
work together daily throughout the project.
Build projects around motivated
individuals. Give them the environment and
support they need, and trust them to get the job
done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Principles of Agile
Working software is the primary measure of
progress.
Agile processes promote sustainable
development. The sponsors, developers, and users
should be able to maintain a constant pace
indefinitely.
Continuous attention to technical excellence
and good design enhances agility.

Principles of Agile
Simplicity--the art of maximizing the amount
of work not done--is essential.
The best architectures, requirements, and
designs emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Sequence of iterations

Scrum Process
What is Scrum
Introduction
Applying Scrum
Preconditions to Scrum
Scrum roles
How to scrum

What is Scrum

Applying Scrum
Scrum is not silver bullet

Applying Scrum
Adopt all Scrum practices

Applying Scrum
Top-Bottom or Bottom-Up? Combine both
approaches properly

Scrum Process
What is Scrum
Preconditions to Scrum
Scrum roles
Scrum ceremonies

Transparency

Ethics

Team work

Freedom

Open communication

Stakeholder engagement

Maturity

Scrum Process
What is Scrum
Preconditions to Scrum
Scrum roles
Product Owner
Scrum Master
Team
Scrum ceremonies
Scrum artifacts

Product Owner
Product owner has the following responsibilities:
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 30 days, as needed;
Accept or reject work results.

Scrum Master
The Scrum Master is a facilitative team leader
working closing with the Product Owner. He must:
Ensure that the team is fully functional and productive;
Enable close cooperation across all roles and functions;
Remove barriers;
Shield the team from external interferences; and
Ensure that the process is followed, including issuing
invitations to Daily Scrum, Sprint Review and Sprint
Planning meetings.

Scrum Master (continue)
The Scrum Master has three primary responsibilities
in addition to leading the Daily Scrum meeting:
Needs to know what tasks have been completed, what
tasks have started, any new tasks that have been
discovered, and any estimates that may have changed.
The Scrum Master must also look carefully at the
number of open tasks in progress.
Needs to surface dependencies and blocks which are
impediments to the Scrum. They need to be prioritized
and tracked.

Scrum Master (continue)
Last but not least, the Scrum Master may notice
personal problems or conflicts within the Scrum that
need resolution. These need to be clarified by the Scrum
Master and be resolved by dialogue within the team, or
the Scrum Master may need help from management or
the Human Resources.

Team
Is cross-functional, with seven (plus/minus two)
members;
Selects the Sprint goal and specifies work results;
Has the right to do everything within the
boundaries of the project guidelines to reach the
Sprint goal; Organizes itself and its work; and
Demos work results to the Product Owner

Scrum Process
What is Scrum
Preconditions to Scrum
Scrum roles
Scrum ceremonies
Sprint Planning Meeting
Daily Scrum Meeting
Sprint Review Meeting
Scrum artifacts

Sprint Planning Meeting
Preparation for a Scrum sprint begins when the
Product Owner develops a plan for a product or a
project.
The team reviews the estimates for features on the
Product Backlog and confirms that they are as
accurate as possible
Be used to develop a detailed plan for the iteration
Be time-boxed to a maximum of four hours.

Daily Scrum Meeting
Be the fifteen-minute meeting designed to clarify the
state of the Scrum.
Each team member speaks to three questions:
What did I do yesterday
What did I do today, and
What impediments got in my way?
Only team members who have committed to deliver
work to the Scrum are allowed to speak. The goal is
to get a global snapshot of the project, discover any
new dependencies, address any personal needs of
committed individuals, and adjust the work plan in real
time to the needs of the day.

Daily Scrum Meeting
Pig and chicken issue in Scrum

Sprint Review Meeting
Be held at the end of each Sprint.
Product Owner determines which items on the
Product Backlog have been completed in the Sprint,
and discusses with the Scrum team and stakeholders
how best to reprioritize the Product Backlog for the
next sprint
Be time-boxed to a maximum of four hours.

Scrum Process
What is Scrum
Preconditions to Scrum
Scrum roles
Scrum ceremonies
Scrum artifacts
Product Backlog
Sprint Backlog
Burn-down Chart

Product Backlog
A single list of features prioritized by value
delivered to the customer.
The Product Backlog includes business and
technical requirements needed to build the
product. The highest priority items in the Product
Backlog need to be broken down into small enough
chunks to be estimable and testable. Features that
will be implemented further out in time can be less
detailed.

Product Backlog
Sprint Backlog may change for several reasons:
The development team gains a better understanding of
work to be done as time progresses and may find that
they need to add new tasks to the Sprint Backlog.
Defects may be identified and logged as additional
tasks.
The Product Owner may work with the team during the
Sprint to help refine team understanding of the Sprint
goal. The Scrum Master and Team may decide that
minor adjustments that do not lengthen the Sprint are
appropriate to optimize customer value.

Product Backlog
Example

Sprint Backlog
The list of tasks that the Scrum team is
committing that they will complete in the current
sprint. Items on the sprint backlog are drawn from
the Product Backlog, by the team based on the
priorities set by the Product Owner and the team's
perception of the time it will take to complete the
various features.

Sprint Backlog
Example

Burn-down Chart
The Burn-down Chart is used as a tool to guide the
development team to successful completion of a Sprint
on time.
Shows the cumulative work remaining in a Sprint, day-
by-day.
The total of all Sprint Backlog estimates of work
remaining to be completed is the cumulative backlog.
When tasks are completed as the Sprint proceeds, the
Scrum Master recalculates the remaining work to be
done and the Sprint Backlog decreases, or burns down
over time. It the cumulative Sprint Backlog is zero at the
end of the Sprint, the Sprint is successful.

Burn-down Chart
Example

References

References
Software Development Process,
http://en.wikipedia.org/wiki/Software_developme
nt_process
Waterfall Model,
http://en.wikipedia.org/wiki/Waterfall_model
RUP, Best Practices for Software Development Team,
http://www.ibm.com/developerworks/rational/libr
ary/content/03July/1000/1251/1251_bestpracti
ces_TP026B.pdf
Agile Manifesto, http://agilemanifesto.org/

References
Darrel Norton, Scrum overview
http://codebetter.com/blogs/darrell.norton/pages
/50339.aspx
ScrumAlliance, http://www.scrumalliance.org/
Implementing Scrum,
http://www.implementingscrum.com

References
Pictures are gotten from:
http://www.agileadvice.com/archives/2006/09/yet_
another_big.html
http://www.agilemodeling.com/essays/agileModeling
RUP.htm
http://www.notetech.com/images/software_lifecycle.jp
g