Agile

Software
Development
Methodology

Presented by:
Bayu Hendradjaya
(bayu@informatika.org)
Data & Software Engineering Research Group
Institut Teknologi Bandung

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 2
2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 3
 Agile Deni*on
Agile [Merriam-Webster]
1: marked by ready ability to move with quick
easy grace;
2: having a quick resourceful and adaptable
character.
In agile soEware development,
the ability to respond to change.

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 4

What is Agile SoEware Development?
An itera*ve and incremental (evolu*onary) approach
performed in a highly collabora*ve
manner with just the right amount of ceremony to produce
high quality soEware in a cost eec*ve and *mely manner
which meets the changing needs of its stakeholders.
Core principles
Fits just right process
Con*nuous tes*ng and valida*on
Consistent team collabora*on
Rapid response to change
Ongoing customer involvement
Frequent delivery of working soEware

5
IF3250-Proyek Perangkat Lunak 5
 Characteris*cs of Agility(1)
Empowered, self-organizing teams
Mul*-discipline, cross-func*onal teams (whole
team culture)
Project- and product-centric focus, minimal
organiza*onal focus
Shared responsibility, role-based accountability
Shared vision of standards of excellence
Close, con*nuous collabora*on, direct
communica*on

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 6

 Characteris*cs of Agility(2)
Early, frequent, and con7nuous demonstra7on of progress
through concrete deliverables
Rapid feedback, reec7on, learning, adjustment
Small work batch sizes, minimal specializa*on, reduced queuing
delays
Just in 7me produc7on, minimize produc*on of ar*facts not
immediately (or ever) consumed
Low fric7on simplicity, minimalism, pragma*sm
Avoidance of debt, focus on forward movement
Parallelism and opportunis7c control
Sustainable, constant, predictable pace

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 7

 Goals & Poten*al Benets of Agility
Delivering the most value to the business,
ecient use of resources, maximize ROI and
*me-to-ROI
Faster development, higher produc*vity
Flexibility to respond to change and leverage
learning
Be^er quality solu*ons, more enduring
systems
More fullling development culture
2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 8
 Agile SoEware Development
Methodology
Agile Methodology is develop based on itera*ve and incremental
development
It is based on feedback from the clients.
In this methodology the requirements and solu*ons evolve through
collabora*on between self-organizing, cross-func*onal teams who
work in close liaison with the clients.
It promotes evolu*onary development, adap*ve planning and
encourages rapid and exible response to change.
It is suitable for
Product (and less for services)
Smaller to medium sized products
Development teams for such products is ranging from 5 to 20-20
members
A team of 100 members was also noted to be a success

2-Feb-17 SW Dev Methodologies/Bayu Hendradjaya 9

 Agile Manifesto
Individuals and interac7ons over processes and tools
Working soGware over comprehensive documentaQon
Customer collabora7on over contract negoQaQon
Responding to change over following a plan

That is, while there value in the
items on the right, we value the
items on the leG more.

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 10

 12 Principles
Highest priority: user sa*sfac*on
Welcome changing requirement
Deliver working soEware frequently
Business people and developers work together daily
Build around mo*vated individuals
Face-to-face conversa*on
Working soEware: primary measure of progress
Promote sustainable development
Con*nuous a^en*on to technical excellence and good design
Simplicity is essen*al
Self-organizing team
Tune and adjust team behavior at regular intervals

11
IF3250-Proyek Perangkat Lunak 11
12
 An Agile View of Process
Compromise between Conven*onal SoEware Development to a
SoEware Project
Represents a reasonable compromise between conven*onal soEware
engineering for certain classes of soEware and certain types of soEware
projects
Deliver a successful system quickly
Stresses on Con7nuous Communica7on and Collabora7on among
developers and customers
Embraces a philosophy that encourages:
customer sa*sfac*on,
incremental soEware delivery,
small project teams (composed of soEware engineers and stakeholders),
informal methods, and
minimal soEware engineering work products
Stress on-*me delivery of an opera*onal soEware increment over
analysis and design

13
IF3250-Proyek Perangkat Lunak 13
 How Agile is Dierent
Focus on collabora7on:
Less paperwork and more conversa*on
Stakeholders ac*vely involved
Focus on working soGware:
Greater feedback makes agile projects easier to manage
Less documenta*on is required
Less bureaucracy
Agilists are generalizing specialists:
Less hand os between people
Less people required
Specialists nd it dicult at rst to t into the team
Agile is based on prac7ce, not theory:
This is a signicant change from tradi*onal
You need to see how agile works in prac*ce to truly understand it
2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 14
 Mythbusters
Myth Reality
1. No Documenta*on 1. Agile Documenta*on
2. Undisciplined 2. Requires great discipline
3. No Planning 3. Just-in-*me (JIT) planning
4. Not Predictable 4. Far more predictable
5. Does Not Scale 5. Eclipse is agile
6. Is a Fad 6. Its quickly becoming the norm
7. Silver Bullet 7. It requires skilled people
8. RUP isnt agile 8. RUP is as agile as you make it
9. Not Fixed Price 9. Agile provides stakeholders control
over the budget, schedule, and
scope

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 15

 Agile Methodologies
Adap*ve SoEware Development
Agile Modeling
Agile Unied Process (AUP)
Crystal
Dynamic Systems Development Method (DSDM)
Essen*al Unied Process (EssUP)
Extreme Programming (XP)
Feature Driven Development (FDD)
Lean Development
Open Unied Process (OpenUP)
Scrum
Velocity tracking

2-Feb-17 16
Adapated from
An Introduc*on to Scrum Mountain Goat SoEware, LLC

Scrum

2-Feb-17 17
Scrum in 100 words

Scrum is an agile process that allows us to focus on

delivering the highest business value in the shortest *me.
It allows us to rapidly and repeatedly inspect actual working
soEware (every two weeks to one month).
The business sets the priori*es. 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
soEware and decide to release it as is or con*nue to
enhance it for another sprint.

18
 About Scrum
Scrum is an agile process that allows us to focus on delivering the highest
business value in the shortest *me.
It allows us to rapidly and repeatedly inspect actual working soEware
(every two weeks to one month).
The business sets the priori*es. Our teams self-manage to determine the
best way to deliver the highest priority features.
Every two weeks to a month anyone can see real working soEware and
decide to release it as is or con*nue to enhance for another itera*on.
Scrum is an agile process that allows us to focus on delivering the highest
business value in the shortest *me.
It allows us to rapidly and repeatedly inspect actual working soEware
(every two weeks to one month).
The business sets the priori*es. Our teams self-manage to determine the
best way to deliver the highest priority features.
Every two weeks to a month anyone can see real working soEware and
decide to release it as is or con*nue to enhance for another itera*on.

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 19

 History of Scrum
1995:
analysis of common soEware development processes not
suitable for empirical, unpredictable and non-repeatable
processes
Design of a new method: Scrum by Je Sutherland & Ken
Schwaber
Enhancement of Scrum by Mike Beedle & combina*on of Scrum
with Extreme Programming

1996:
introduc*on of Scrum at OOPSLA conference

2001:
publica*on Agile SoEware Development with Scrum by Ken
Schwaber & Mike Beedle

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 20

 Characteris*cs
Self-organizing teams
Product progresses in a series of month-long
sprints
Requirements are captured as items in a list of
product backlog
No specic engineering prac*ces prescribed
Uses genera*ve rules to create an agile
environment for delivering projects
One of the agile processes

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 21

The Agile Manifestoa statement of
values

Individuals and
over Process and tools
interactions
Comprehensive
Working software over
documentation
Customer
over Contract negotiation
collaboration

Responding to change over Following a plan

Source: www.agilemanifesto.org
22
 Project noise level

Far from
Agreement
Anarchy
Requirements

Complex

Source: Strategic Management and

OrganizaQonal Dynamics by Ralph Stacey
in Agile SoVware Development with

Close to Simple Scrum by Ken Schwaber and Mike Beedle.

Agreement
Certainty

Certainty
Close to

Far from
Technology

23
 Scrum
24 hours

Sprint
2-4 weeks
Sprint goal
Return
Sprint Poten*ally shippable
Return
Cancel backlog product increment
GiE wrap
Coupons
GiE wrap
Cancel Coupons
Product
backlog
 Putting it all together

Image available at
www.mountaingoatsoEware.com/scrum
 Sprints
Scrum projects make progress in a series of
sprints
Analogous to Extreme Programming iterations
Typical duration is 24 weeks or a calendar
month at most
A constant duration leads to a better rhythm
Product is designed, coded, and tested during
the sprint

26
 Sequential vs. overlapping
development

Requirements Design Code Test

Rather than doing all of

one thing at a *me...
...Scrum teams do a li^le
of everything all the *me

Source: The New New Product Development Game by Takeuchi

and Nonaka. Harvard Business Review, January 1986.
27
 No changes during the sprint

Change

Inputs Sprint Tested Code

Plan sprint dura*ons around how long you can

commit to keeping change out of the sprint

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 28

 Scrum framework
Roles

Product owner
ScrumMaster
Team Ceremonies

Sprint planning
Sprint review
Sprint retrospec*ve
Daily scrum mee*ng
Ar*facts

Product backlog
Sprint backlog
Burndown charts 29
 Scrum Framework
Roles :
Product Owner,
ScrumMaster,
Team
Ceremonies : Sprint Planning, Sprint Review,
Sprint Retrospec*ve, & Daily Scrum Mee*ng
Ar7facts : Product Backlog, Sprint Backlog,
and Burndown Chart

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 30

 Product Owner
Dene the features of the product
Decide on release date and content
Be responsible for the protability of the
product (ROI)
Priori*ze features according to market value
Adjust features and priority every itera*on, as
needed
Accept or reject work results.
2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 31
 The Scrum Master
Represents management to the project
Responsible for enac*ng Scrum values and
prac*ces
Removes impediments
Ensure that the team is fully func*onal and
produc*ve
Enable close coopera*on across all roles and
func*ons
Shield the team from external interferences

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 32

 Scrum Team
Typically 5-9 people
Cross-func*onal
QA, Programmers, UX Designers, etc.
Members should be full-*me
May be excep*ons (e.g., System Admin, etc.)
Teams are self-organizing
What to do if a team self-organizes someone o the
team??
Ideally, no *tles but rarely a possibility
Membership can change only between sprints

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 33

 Ceremonies
Sprint Planning Mee*ng
Sprint
Daily Scrum
Sprint Review Mee*ng

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 34

 Spring Planning Mee*ng

Product Backlog

Team Capabilities
Sprint Goal
Sprint Planning
Business Conditions
Meeting Sprint Backlog
Technology

Current Product

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 35

Team
Sprint planning mee*ng
capacity
Sprint priori*za*on
Product Analyze and evaluate product Sprint
backlog backlog goal
Select sprint goal
Business
conditions Sprint planning
Decide how to achieve sprint goal
Current (design)
Sprint
product Create sprint backlog (tasks) from backlog
product backlog items (user
stories / features)
Technology Es*mate sprint backlog in hours

36
 Sprint planning
Team selects items from the product backlog they
can commit to completing
Sprint backlog is created
Tasks are identified and each is estimated (1-16 hours)
Collaboratively, not done alone by the ScrumMaster
High-level design is considered
As a vacation Code the middle *er (8 hours)
planner, I want to Code the user interface (4)
see photos of the Write test xtures (4)
Code the foo class (6)
hotels. Update performance tests (4)

37
 Parts of Sprint Planning Mee*ng
1st Part:
Crea*ng Product Backlog
Determining the Sprint Goal.
Par*cipants: Product Owner, Scrum Master,
Scrum Team
2nd Part:
Par*cipants: Scrum Master, Scrum Team
Crea*ng Sprint Backlog

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 38

 Pre-Project/Kicko Mee*ng
A special form of Sprint Planning Mee*ng
Mee*ng before the begin of the Project

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 39

 Daily Scrum
Parameters
15-minutes
Stand-up
Not for problem solving
Whole world is invited
Only team members, ScrumMaster, product owner, can
talk
Helps avoid other unnecessary mee*ngs
Three ques*ons:
1. What did you do yesterday
2. What will you do today?
3. What obstacles are in your way?

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 40

 Daily Scrum
Is NOT a problem solving session
Is NOT a way to collect informa*on about
WHO is behind the schedule
These are not status for the ScrumMaster
Is a mee*ng in which team members make
commitments to each other and to the Scrum
Master
Is a good way for a Scrum Master to track the
progress of the Team
2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 41
 Scrum Mee*ng FAQs
Why daily?
How does a project get to be a year late?
One day at a *me.
Fred Brooks, The Mythical Man-Month.
Can Scrum mee*ngs be replaced by emailed
status reports?
No
En*re team sees the whole picture every day
Create peer pressure to do what you say youll do

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 42

 Sprint Review Mee*ng
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 *me rule
Par*cipants
Whole team par*cipates
Customers
Management
Product Owner
Other engineers

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 43

 Sprint Retrospec*ve Mee*ng
Periodically take a look at what is and is not
working
Typically 1530 minutes
Done aEer every sprint
Feedback mee*ng
Three ques*ons
Start Stop Con*nue
Whole team par*cipates
ScrumMaster
Product owner
Team
Possibly customers and others
44
 Start / Stop / Continue
Whole team gathers and discusses what
they d like to:
Start doing

Stop doing
This is just one
of many ways to Continue doing
do a sprint
retrospective.

45
 Split your organiza*on to small-cross
func*onal, self-organizing teams

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 46

 Split your work into a list of small,
concrete deliverables.
Sort the list by priority
and es*mate the
rela*ve eort of each
item.

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 47

 Product backlog
The requirements
A list of all desired work on
the project
Ideally expressed such that
each item has value to the
users or customers of the
product
Priori*zed by the product
owner
Repriori*zed at the start of
This is the each sprint
product backlog
48
 Product Backlog
A list of all desired work on the project
Usually a combina*on of
story-based work (let user search and replace)
task-based work (improve excep*on handling)
List is priori*zed by the Product Owner
Typically a Product Manager, Marke*ng, Internal
Customer, etc.

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 49

 Product Backlog
Requirements for a system, expressed as a
priori*zed list of Backlog Items
Is managed and owned by a Product Owner
Spreadsheet (typically)
Usually is created during the Sprint Planning
Mee*ng
Can be changed and re-priori*zed before each
PM
2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 50
 A sample product backlog
Backlog item Es*mate
Allow a guest to make a reserva*on 3

As a guest, I want to cancel a reserva*on. 5

As a guest, I want to change the dates of a

3
reserva*on.
As a hotel employee, I can run RevPAR
8
reports (revenue-per-available-room)
Improve excep*on handling 8
... 30
... 50 51
 An example of Product Backlog

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya

52
 Kanban Chart

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 53

 The sprint goal
A short statement of what the work will be
focused on during the sprint
Life Sciences
Support features necessary for
Database Applica*on popula*on gene*cs studies.

Make the applica*on run on SQL

Server in addi*on to Oracle.
Financial services
Support more technical indicators
than company ABC with real-*me,
streaming data.

54
 From Sprint Goal to Sprint Backlog
Scrum team takes the Sprint Goal and decides
what tasks are necessary
Team self-organizes around how theyll meet
the Sprint Goal
Manager doesnt assign tasks to individuals
Managers dont make decisions for the team
Sprint Backlog is created

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 55

 Sprint Backlog during the Sprint
Changes
Team adds new tasks whenever they need to in
order to meet the Sprint Goal
Team can remove unnecessary tasks
But: Sprint Backlog can only be updated by the
team
Es*mates are updated whenever theres new
informa*on

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 56

 Sprint Backlog
A subset of Product Backlog Items, which dene
the work for a Sprint
Is created ONLY by Team members
Each Item has its own status
Should be updated every day
No more than 300 tasks in the list
If a task requires more than 16 hours, it should
be broken down
Team can add or subtract items from the list.
Product Owner is not allowed to do it

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 57

 Managing the sprint backlog
Individuals sign up for work of their own choosing
Work is never assigned
Es*mated work remaining is updated daily
Any team member can add, delete or change the
sprint backlog
Work for the sprint emerges
If work is unclear, define a sprint backlog item with a
larger amount of time and break it down later
Update work remaining as more becomes known

58
 Product Backlog to Sprint Backlog

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 59

 A sprint backlog
Tasks Mon Tues Wed Thur Fri
Code the user interface 8 4 8
Code the middle *er 16 12 10 4
Test the middle *er 8 16 16 11 8
Write online help 12
Write the foo class 8 8 8 8 8
Add error logging 8 4

60
 A sprint burndown chart
Hours

61
Tasks Mon Tues Wed Thur Fri
Code the user interface 8 4 8
Code the middle *er 16 12 10 7
Test the middle *er 8 16 16 11 8
Write online help 12

50
40
30
20
10
Hours

0
Mon Tue Wed Thu Fri

62
 Split 7me
Op*mize the release plan and update
Split *me into short xed- priori*es in collabora*on with the
length itera*ons (usually 1 4 customer, based on insights gained
weeks), with poten*ally by inspec*ng the release aEer each
itera*on.
shippable code demonstrated
aEer each itera*on. Op*mize the process by having a
retrospec*ve aEer each itera*on.

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 63

 Scalability of Scrum
Typical individual team is 7 2 people
Scalability comes from teams of teams
Factors in scaling
Type of application
Team size
Team dispersion
Project duration
Scrum has been used on multiple 500+ person projects
Je Sutherland - up to over 800 people
"Scrum of Scrums" or what called "Meta-Scrum
Frequency of mee*ngs is based on the degree of coupling
between packets

64
Scaling through the Scrum of scrums

65
Scrum of scrums of scrums

66
 Where to go next
www.mountaingoatsoftware.com/scrum
www.scrumalliance.org
www.controlchaos.com
scrumdevelopment@yahoogroups.com

67
 A Scrum reading list
Agile and Iterative Development: A Manager s Guide by Craig
Larman
Agile Estimating and Planning by Mike Cohn
Agile Project Management with Scrum by Ken Schwaber
Agile Retrospectives by Esther Derby and Diana Larsen

68
 A Scrum reading list
Agile Software Development Ecosystems by Jim Highsmith
Agile Software Development with Scrum by Ken Schwaber and
Mike Beedle
Scrum and The Enterprise by Ken Schwaber
Succeeding with Agile by Mike Cohn
User Stories Applied for Agile Software Development by Mike
Cohn

69
 Execu*on of Scrum

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 70

 Advantages/Disadvantages
Advantages Drawbacks
Completely developed and Undisciplined
tested features in short hacking (no written
iterations documentation)
Simplicity of the process Violation of
Clearly defined rules responsibility
Increasing productivity Current mainly carried
Self-organizing by the inventors
each team member carries
a lot of responsibility
Improved communication
Combination with Extreme
Programming

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 71

 Challenges in Agile
Compliance requirement

Low risk Critical,

Audited
Geographical distribution Entrenched process,
people, and policy
Co-located Global
Minimal Significant

Agile Development

Organization distribution
Application complexity (outsourcing, partnerships)
Simple, Complex,
single multi-platform In-house Third party
platform

Team size Degree of Governance

Under 10 100s of
developers developers Informal Formal

72
IF3250-Proyek Perangkat Lunak 72
 Finally,

Scrum is a soEware management process,

NOT a soEware engineering process.

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 73

 Acknowledgement
Presenta*on slide of Agile Logic, Extreme
Programming,
h^p://www.agilelogic.com/ resources.html
http://www.mountaingoatsoftware.com/scrum
Presenta*on Slides of Daniel Baranowski, Extreme
Programming.
Presenta*on Slides of Sco^ W. Ambler, Agile SoEware
Development: Whats Really Going On, IBM SoEware
group,
Presenta*on slide of Yogi Bera, SoEware Development
Life Cycle (SDLC)

2-Feb-17 Agile SW Dev. Methodologies/Bayu Hendradjaya 74