You are on page 1of 33

Agile - SCRUM

16th April 2009


Mohan Ramanujan
Contents

• Issues With Traditional Approach for SW Development


• Where Will Agile Fit
• What is Agile
• History Of Agile
• Agile Methodologies
• Agile Manifesto
• Key Concepts Of Agile
• Agile – SCRUM
• SCRUM Development Model / Process
• Characteristics of SCRUM
• SCRUM Hierarchy
• SCRUM Roles
• SCRUM Artifacts
• SCRUM Usage In Industry
• Further Reading
Traditional Approach

• Some of the disadvantages of traditional software development approach


• Huge effort during the planning phase
• Poor requirements conversion in a rapid changing environment
• Too many things are done that are not directly related to software product being
produced
• Higher cost of defect fix
• Shunt effect
Traditional Approach

Months
1 2 3 4 5 6 7 8 9 10 11 12

Analysis Design Code Test


Deploy

Software Development

Waterfall - We will always be at our most vulnerable just when we


least want to be and that defects will be found when they are the
most expensive to fix.
Traditional Approach

4 weeks 4 weeks 40 weeks 4 weeks

analysis design code test

Construction
4 weeks 5 weeks 42 weeks 1week

analysis design code test

As each phase of the project is delayed, the remaining phases get moved back
but the deadline remains the same, causing compression in the last stages.
Delays are often caused by individuals who are reticent to sign-off the preceding
stage.

6
Where Will Agile Fit

unknown

chaotic

CO
M
requirements

difficult PL
EX

simple difficult

known unknown
technology
What is Agile
Agile Methodology
• An iterative and incremental (evolutionary) approach to software development which is performed in a
highly collaborative manner by self-organizing teams within an effective governance framework with
"just enough" ceremony that produces high quality software in a cost effective and timely manner which
meets the changing needs of its stakeholders

Principles / Characteristics of Agile


• Continuous attention to technical excellence and good design
• Self-organizing teams
• Customer satisfaction by rapid, continuous delivery of useful software
• Working software is the principal measure of progress
• Delivered frequently
• Late changes in requirements
• Close, daily cooperation between business people and developers
• Face-to-face conversation is the best form of communication
• Time boxed approach
• Lightweight processes
• People focused
• Multiple agile methods
History Of Agile
• February 2001 at Snowbird Snow Resort, Utah, USA

• 17 people including Kent Beck, Ken Schwaber (Agile Alliance)

• Coined the term Agile

• Manifesto for Agile Software Development


Agile Methodologies

• eXtreme Programming (XP)


• Feature-Driven Development (FDD)
• Crystal
• SCRUM
• Adaptive Software Development (ASM)
• Dynamic Systems Development Model (DSDM)
• Lean Development (LD)

10
Agile Manifesto

Individuals & Interactions over Process & Tools


Working Software over Comprehensive Documents
Customer Collaboration over Contract Negotiation
Responding to Change over Following a Plan

Things on the right are important.

Things on the left are more important!!


Key Concepts

Onsite customer

Acceptance User Stories


tests
Open Workspace

Collective Ownership Test First Design Coding standard

One Team Pair Retrospectives


Programming Refactoring

Continuous Simple design


Integration Sustainable pace

Metaphor
Sprints Release plan

Small releases
Continuous Integration
Errors

Weekly Build

Daily Build

Time

• Latest sources are checked out


• Every file is compiled from scratch
• Suite of tests is run (Automated tests)
• Daily builds (Automated builds)
Most Important Features

• Why pay for features that are


either never used or don’t
provide a sufficient return-on-
investment?
A lw a y s
O fte n • Even if you produce the same
7% number of features, an Agile
13%
process ensures that they are
N ever the most valuable features
45% • Make sure that product
managers are active
S o m e tim e s participants. Their ability to
16% prioritize may be the most
valuable Agile practice
R a re ly
19%
Pair Programming

• NOT – One person writing and other watching or a tutoring


session
• One partner thinks about making it work other thinks how can
it be made simple or will any test fail
• Pairing is dynamic
• Start with an hour
• Skill to be acquired over a period of time
Spirit Instead of Just Ritual

Adhoc Non Value added


Processes
Processes

Value added
Processes
Cost Of Change

Cost of change

New cost of change

Requirements Analyse Code Test Integrate

Project stage
Agile - SCRUM

• SCRUM is an iterative incremental process of software development


commonly used with agile software development. Though SCRUM is not an
acronym, it is general practice to capitalize it
• Wrapping existing engineering practices, SCRUM generates the benefits of
agile development with the advantages of a simple implementation
• The name SCRUM comes from a strategy used in rugby for getting an out-of-
play ball back into play
• Adaptive, quick & self-organizing
Key Originators

• Jeff Sutherland – One of the originators of Scrum and was one of the first
people to apply Scrum to a real project
• Ken Schwaber – One of the originators of Scrum
• Mike Beedle – Successfully used Scrum in numerous large-scale projects and
authored the book “Agile Software Development with Scrum” along with Ken
Schwaber
Waterfall vs. SCRUM

Analysis
Design
Code

Waterfall Test

A A A A

D C D C D C D C

T T T T

Agile
Scrum
SCRUM Dev Model
QMS With SCRUM

• CMMI-
descriptive
and not
prescriptive
• QMS can
include agile
methods
and achieve
CMMI
Characteristics Of SCRUM

• Self-organizing teams
• Product progresses in a series of month-long “sprints”
• Requirements are captured in a list of “product backlog”
• No specific engineering practices prescribed
• Impediments to releasing finished software become visible sooner
• Time-boxed
• Values delivering software over documentation
• No software can be demonstrated to the Product Owner that is not “done
Involvement Vs Commitment

Chicken and a Pig are together when the chicken says “ Lets start a restaurant!”
The pig thinks it over and says’ “ What would we call this restaurant?”
The chicken says, “Ham n’ Eggs!”
The pig says,” No thanks, I’d be committed, but you’d be only involved!”

• Scrum Members – Pigs


• Other Stakeholders - Chicken
SCRUM Hierarchy

S3 (Release Scrum
of Scrums)

S2 (Cross- Module /
Component Scrum of
Scrums)

S1 (Scrum Teams)
Roles

• Product Owner (Product Manager)


• Create and prioritize the product backlog
• Define Sprint Goal(s)
• Participate in Sprint Planning, Sprint Review, S1, S2 and S3 meetings
• Own the product and are responsible for profitability (ROI)
• SCRUM Master
• Manage the scrum process
• Host Sprint Planning, Daily Scrum & Sprint Review meetings
• Create the Sprint Backlog & update it everyday
• Resolve Scrum Team issues / risks
• Escalate unresolved issues / risks to S2
• SCRUM Team
• Self-organizing cross functional groups (7+-2)
• Participate in Sprint Planning, Daily Scrum & Sprint Review meetings
• Execute Sprint Activities & Demonstrate Sprint Output
• Communicate issues / risks to Scrum Master
Meetings

• Sprint Planning Meetings


• Hosted by respective Scrum Masters At Start Of Sprint
• Scrum Teams Select High Priority Items From Product/Release Backlog
• Scrum Team accept Sprint Goal(s) Defined By Product Owner
• Sprint Backlog Along With Sprint Goals Will Result From Meeting
• Daily SCRUM Meetings (S1)
• Hosted by Scrum Masters & Attended By SCRUM Team & Other Stakeholders
• Scrum Team answers three questions
• What did you do yesterday?
• What will you do today?
• What issues block your way?
• Scrum Master Updates Sprint Backlog
• SCRUM Of SCRUM Meetings (S2)
• Hosted by Development Manager Once / Twice A Week
• Attended By Scrum Masters & Other Stakeholders
• Issues Not Solved At S1 Level Are Resolved
• Steel Thread Management Issues Resolved
Meetings

• SCRUM Of SCRUM Of SCRUM (S3)


• Hosted Weekly By Release Manager
• Occurs Separately & Jointly For Each Development Site
• Attended By Project Managers, Development Managers, Product Managers &
Release Manager
• Issues Not Solved At S2 Level Are Resolved
• Sprint Review Meeting
• Hosted By Scrum Master At Sprint Closure
• Scrum Team Demonstrates Sprint Output
• Product Owner / Product Manager Accepts / Rejects Output
• Scrum Master Creates Sprint Review Record
• Scrum Master Documents Lessons Learnt
• Sprint Retrospective Meeting
• Honest and systematic look back at a recently completed sprint
• Identify lessons in a sprint and identify actions that can be taken to make the next
project more successful
Artifacts

• Product Backlog
• Requirement List Pertaining To The Product
• The Product Owner / Product Manager Owns This Artifact
• Priority on requirements can be set only by the Product owner / Product Manager
• Product Owner / Product Manager Can Add Requirement To This List
• Release Backlog
• Requirements Selected For A Specific Release
• Product Owner / Product Manager Owns This Artifact
• Sprint Backlog
• Sprint Goals, Selected Features, Tasks, Work Effort, Team Details, Issues & Risks
• Scrum Owns This Artifact
• Product Increment
• The Most Weighted Artifact & This Is The Output Of The Sprints
• This Is A Version Of The Product
• It Contains Shippable Functionality Adequately Tested & Documented
SCRUM Usage In Industry

• FDA-approved, life-critical software for x-rays and MRIs


• Healthcare - Hospital Information Systems
• Enterprise workflow systems
• Financial payment applications
• Application development environments
• Multi-terabyte database applications
• Media-neutral magazine products
• Web news products
Further Reading On SCRUM

• Ken Schwaber
• Mike Beedle
Thank you

You might also like