Presumptions

The audience is well aware of traditional

software development methodologies like
Waterfall Model, Iterative models, etc.
 Agenda
 Introduction
 What is Agile Methodology?
 What is Scrum?
 History of Scrum
 Functionality of Scrum
 Components of Scrum
 Scrum Roles
 The Process
 Scrum Artifacts
 Q & A Session
 Agile Development – What
does it mean?
Agileis a set of practices, values, and
principles for software product development.
In software product development, we think
about “methodologies,” “activities,”
“interactions,” “results, work products or
artifacts;” we think about “processes” that we
use to organize the work:
 documents
 meetings and reviews
 diagrams and models
 coding and user documentation standards
So will Agile Development define a new set
of process activities? Not necessarily.
 Agile vs. Sequential Models or
Frameworks
Many of us are familiar with the Waterfall Model – it is a
“framework” for the software development process
 Waterfall Model talks about “development activities
through time”
 Waterfall Model talks about “teams of people”

Development activities Teams

Divide the work into stages A separate team of

specialists for each stage

At each stage, the work is Some coordination is

passed from one team to required for the handoff
another from team to team – using
“documents”

At the end of all of the As each team finishes,

stages, you have a software they are assigned to a new
product ready to ship product
 What is Agile? (continued)
The core ideas in Agile Development:
 Adaptive
 Iterative/incremental
 People-oriented
Adaptive means that the teams and the
process should be flexible in the presence of
“rapid-fire change”.

Iterativeand incremental means that Agile

Development produces working products in
stages – a growing set of “completed and
working software”.

People-oriented means the team organization

and processes will support good people, who are
the most important ingredient to project success.
 Iterative development
 One way to organize agile development is using short
iterations:
Each iteration
iteration iteration iteration iteration iteration iteration iteration

planning 1 2 3 4 5 6 might be 4
weeks

Today Ship date

Internal Customer Customer
prototype -viewable -viewable
(demo 1) prototype prototype
(demo 2) (demo 3)

Each iteration step:

Question:
• has some analysis, some design, some coding,
some integration and testing
• Could we do a “demo”
every iteration?
• executed by a cross-functional team
Absolutely yes! The
•
• delivers some kind of internally or externally team gets practice at
usable functionality – intermediate demos or doing system integration
deliveries are possible!
 Main characteristics of Agile
Development
Agile Development as a “software development framework” says:
 keep things small
 deliver partially-completed software frequently
 talk to the customer often
 write more code than documentation
 everyone on the team learns together

Every 4 weeks, produce a

new shippable product
Work for the
current
iteration

Work for future

iterations
 Agile Practices
There are many Agile practices:
Check in
 short time boxed iterations changes update
build
 continuous integration Continuous
status

Integration
 daily unit testing Product
Server

Developer Source code

 regular retrospectives workstations repository
(Subversion)
 direct communication between developers
and the customer or a customer surrogate
 a single list of features and tasks
 short-term estimation of development tasks
 information radiators
 refactoring
Will
you use every Agile practice? Maybe
not…. they are not all required. Product Backlog Items
for current Sprint

What is required? Agile values…

 The Agile Manifesto: An Eloquent
Statement of Agile Values or Goals
 Agile principles
1. Our highest priority is to 5. Build projects around motivated 9. Continuous attention to
satisfy the customer through early individuals. Give them the technical excellence and good
and continuous delivery of environment and support they design enhances agility.
valuable software. need, and trust them to get the job
done.

2. Welcome changing 6. The most efficient and effective 10. Simplicity--the art of
requirements, even late in method of conveying information maximizing the amount of work
development. Agile processes to and within a development team not done--is essential.
harness change for the customer's is face-to-face conversation.
competitive advantage.

3. Deliver working software 7. Working software is the primary 11. The best architectures,
frequently, from a couple of measure of progress. requirements, and designs emerge
weeks to a couple of months, from self-organizing teams.
with a preference to the shorter
timescale.

4. Business people and 8. Agile processes promote 12. At regular intervals, the team
developers must work together sustainable development. The reflects on how to become more
daily throughout the project. sponsors, developers, and users effective, then tunes and adjusts
should be able to maintain a its behavior accordingly.
constant pace indefinitely.
 Agile – Questions and Challenges?
 Documentation – it is still important in an Agile project.
 If it is the only kind of communication in your project, it isn’t good
 Real working code is more valuable than documents – less ambiguous
 Documents – easy to leave something out, easy to misinterpret
 Development plans – also important in an Agile project
 the format of an Agile development schedule is a bit different from a conventional
project plan.
 Development plan includes “iterations”
 Each iteration gives the team has a chance to incorporate what they learn, rather
than just following a non-adaptive plan
 Contracts – we expect to have contracts, but we need to talk with the customers as
well.
 Customer collaboration is one way to reduce development costs
 Do you want to deliver “everything” the customer asked for in the original
contract? No – if the customer no longer needs it, the extra code will increase
maintenance costs
 Always ask: Who needs this feature and how does it contribute to the value of
the product?
 Why is Agile Development
important?
The world is a lot different today. A large feature set
might only increase costs for the customer.
 There is a constant introduction of new technology
 New players enter the market,
 New requirements are added
 “Small is Beautiful”
 If we are listening to the customer, we will reduce our chances of
being “blindsided” by a smaller, more flexible competitor
 Anything that helps reduce maintenance costs will contribute to
the bottom line
 How hard is it to be Agile?
 “Don’t do Agile, be Agile”
 Just doing “development in iterations” isn’t enough
 Agile Development is about:
 Keeping the process lightweight
 Making real progress in each iteration
 Communicating – face-to-face when possible
 Actively gathering customer input – early and often
 Being willing to make minor changes to your process
Agile Methods: Scrum
 History of Scrum
 1995:
 analysis of common software development processes  not suitable for empirical,
unpredictable and non-repeatable processes
 Design of a new method: Scrum by Jeff Sutherland & Ken Schwaber
 Enhancement of Scrum by Mike Beedle & combination of Scrum with Extreme
Programming

 1996:
introduction of Scrum at OOPSLA conference

 2001:
publication “Agile Software Development with Scrum” by
Ken Schwaber & Mike Beedle

 Successful appliance of Scrum in over 50 companies

Founders are members in the Agile Alliance
 Agile methodologies
Scrum methodology
 Scrum has been around since the early 1990s
 The structure of Scrum is very simple (3 roles, 3 meetings)
 Scrum is not as “extreme” as some other methodologies
What is a Scrum?
 It is a meeting with attitude – good teamwork is necessary

a software scrum a rugby scrum

Let’s Scrum
 Scrum overview
 The Scrum presentation is short and simple:
 Scrum iteration process
 Product Backlog
 Roles: Team Member, Product Owner, and Scrum
Master
 Project estimation and iteration estimation
 Daily Scrum Meeting
 Management
 Retrospectives
 Scrum iteration process
 Scrum is designed to organize the work of a single cross-functional team
 The team will do software product development this way:
1. Iteration planning – create a plan for one iteration
 Select next features or sub-features to deliver (choose from highest priority
items), define and estimate tasks, negotiate scope of the delivered product
2. Iteration execution – implement the items in the plan
 Fill in missing requirements, design, code, integrate/build, and test the
modules needed in the plan
3. Deliver the results of the iteration – give a demo
 Steps 1 – 3 will be executed many times – based on the Release Plan
 Each cycle is a fixed-length timebox:
 Always end each iteration on schedule, even if it isn’t complete
 (Don’t say – “we can finish everything in this iteration in 2 more days”. Just
deliver and run the next iteration planning meeting.)
 The team learns to make good short-term estimates – so over time, most of the
iterations will deliver as expected
 Scrum Elements
THREE Roles
 Product Owner
 Scrum Master
 Team Member

 THREE Meetings
 Planning (Release & Sprint)
 Daily Scrum
 Sprint Review

 THREE Lists
 Product Backlog
 Spring Backlog
 Impediments List

For details, see

Scrum Guide: http://www.scrum.org/scrumguides
 More on Scrum Introductopn


http://www.youtube.com/watch?v=vmGMpME_phg
 a 2 to 4 week iteration
2 to 4
weeks
 Product Backlog
What does a Product Backlog look like?
 It is a simple spreadsheet
 All “Product Backlog Items (PBIs)” are in priority order
 Some PBIs are the names of “customer features”
 Could be a user screen, an interaction scenario or use case, a new report, a
new algorithm
 Much, much smaller than a telecom system feature
 Some PBIs are internal tasks that contribute to the value of the product
 Can a design document be a PBI? Maybe.
 If it is a document that nobody reads, leave it out (because you are Agile)
 Can an early GUI prototype be a PBI? Certainly.

Effort estimates – each PBI should have an “estimated effort” that is assigned
by the team
 Should managers do the estimation of Product Backlog Items? No, never.
 Estimates must come from the team – and they should be realistic
Sample Product Backlog
 Roles on a Scrum team
 Product Owner
 Responsible for the ROI
 Available for the Team during the whole
product development period
 Gets answers to all requirements questions
 Talks with customers and understands their
priorities
 Keeps the Product Backlog current
 Scrum Master
 Scrum rules guardian
 Coach the team
 Removes impediments
 Prevents outside interference during an
iteration
 Scrum Master is both a teacher and a
referee
 Daily Scrum Meeting
The Scrum Team has two kinds of “once-per-iteration” meetings:
 An Iteration Planning meeting at the beginning of each Sprint
 A Sprint Review meeting at the end of each Sprint
In addition, the Scrum Team has one daily meeting: the Daily Scrum
 Daily Scrum is 15 minutes – no longer
 Everyone is supposed to speak:
 “This is what I did yesterday.”
 “Here is what I am planning to do today.”
 “These are the obstacles in my way.”
 No problem solving in the meeting – everything is taken offline later.
What is the purpose of the Daily Scrum? To make sure that
problems and obstacles are visible to the team
 Obstacles are valuable input for managers
 Retrospectives
One important idea in Agile Development: take time to
reflect and learn
 Iteration is good, because you have a natural breakpoint to
apply some of what you have learned

In Scrum (and many other Agile methodologies), the

team runs a Retrospective meeting at the end of each
iteration
 A Retrospective is like a post-mortem, but it isn’t dead yet
 An end-of-iteration retrospective meeting takes an hour or two

The end-of-iteration Retrospective meeting is a chance

to learn what worked well, what should be changed
 don’t use a Retrospective to blame team members or managers
for all of the problems – focus on fixing the process
 Retrospectives

 The Retrospectives Prime Directive:

Regardless of what we
discover, we understand and
truly believe that everyone did
the best job they could, given
what they knew at the time,
their skills and abilities, the
resources available, and the
situation at hand.

(From Norm Kerth’s book on Project Retrospectives

See also http://www.retrospectives.com )
Why this rule? The goal of a retrospective is to improve the process,
not to assign blame for the problems
 Scrum summary
 Scrum is a “team-oriented” Agile
methodology
 Short timeboxed iterations
 Each iteration produces some real software
that has value to the customer
 Each iteration has
 iteration planning
 development work
 iteration review
 All estimation is done by the team

effort remaining
 Within a Sprint, the progress is tracked
100
using a burndown chart
 Product Owner determines the priorities in 80
the Product Backlog (list of things to build) 60
 Scrum Master helps enforce the rules of
40
Scrum
 There is a 15-minute daily meeting to report 20
what was done and identify obstacles 0
Burndown chart #1
time (days)
 Scrum Adoption
This high-level presentation of Scrum has focused
on the simple Scrum structure and rules.
Butrunning Scrum and getting the core benefits
from it is HARD
 Cross-functionality and self-organization
 Transparency, Inspect and Adapt
 Continuous improvement

31 | Agile Intro | June 2010

 Summary
AgileDevelopment – it is a different way of organizing product
development
 Emphasizes iterative development with small cross-functional teams instead
of waterfall development in separate silos
 At the end of each iteration, there is some functionality that is “done”
 Better communication, faster feedback
Why do we need to be Agile?
 Products are different from 20 years ago
 Customers are in a changing environment – and our processes need to be
working at the same pace
 Working in short cycles reduces time to market and time to quality
There are many ways to be Agile
 Scrum is the most popular Agile approach
 Scrum promotes some good Agile practices
 Small cross-functional teams, short timeboxed iterations, adaptive
planning, single product backlog, frequent integration, test automation