Transitioning to Agile

Methods
Customer Value through Speed, Quality & Waste Reduction
 Before We Begin…
Learning Backlog
Let’s take a moment to introduce ourselves Lorum
ipsum How will agile

and stock our “Learning Backlog.”

impact me as a
developer?

Lorum
ipsum I want to learn how to
Ipsumlogn build great software
addeum while being fast.

1) What’s your name & role in your I think Agile is

just another
fad, am I right?

organization?
2) What is your level of experience with Agile?
3) What do you hope to learn in this session?
Write your questions on Sticky notes and I
will affix them to our Learning Backlog.

2
 Humor

3
Laying the Foundation
 A Case for Change
 Scrum Process Overview
 Planning Overview
 Execution Overview
 Monitoring Overview
 Adapting Overview
A Case for Change
 Are We Really Building Value?

Rates of Feature Usage in Software Projects:

Sometimes Rarely
16% 19%

Often Never
13% 45%

Always
7%

Always or Often Used Never or Rarely Used

20% 64%

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

7
 Project Success Rates & Costs
Results from a 40,000 project survey (The Standish Group’s CHAOS report):

Top 5 reasons for success

1994 1. User involvement
15% project success rate 2. Executive management support
3. Clear business objectives
4. Optimizing scope
≈170% average cost & time overrun
5. Agile process

“Doing projects with iterative

2004 processes as opposed to the waterfall
method, which called for all project
34% project success rate requirements to be defined up front,
is a major step forward.”
≈70% average cost & time overrun Jim Johnson, Chairman of Standish
Group

Source: http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS

8
 The Agile Umbrella

“Agile” describes a series of related methodologies.

Agile Management Frameworks Agile Methodologies

• Agile Project Management • eXtreme Programming
Jim Highsmith, Sanjiv Augustine Kent Beck, Ward Cunningham, Ron Jeffries
• Agile Management, KanBan • Scrum
David Anderson Ken Schwaber and Jeff Sutherland
• eXtreme Project Management • Crystal Methods
Rob Thomsett, Doug DeCarlo Alistair Cockburn
• Feature Driven Development
Jeff DeLuca
• Dynamic Systems Development Method
DSDM Consortium

10
 Agile Software Development Manifesto

We are uncovering better ways of developing software by doing it and

helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools

over Comprehensive
Working software
documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.
http://www.agilemanifesto.org

11
 The Agile Landscape

Agile has now been tried: Who’s Adopted Agile?

• In large and small companies
• Across virtually every industry Companies large & small, across industries.
• Accenture • Kronos
• In public and private sectors
• BMC Software • Macquarie Bank
• On life-critical and mission-critical • British Telecom • Microsoft
projects • Business Week • Nationwide
• With collocated and distributed • Capital One • Primavera
teams • Cognizant • ProRail
• CSC • Sapient
• In internal IT departments,
• DTE Energy • Siemens
commercial product companies • Gestalt • Shopzilla
and consultancies • ThoughtWorks
• Google
• On software and non-software • JP Morgan Chase • USAA
projects • Key Bank • US Intelligence Agencies
• Yahoo!

12
 Key Principles of Agility
Key Agile Principles Traditional Principles
Small Batches Large Batches
Functionality is developed in short iterations of 2 weeks or one month, Typical delivery schedule is two or three times a year.
and released into production frequently, as often as weekly.

Responding to Change Baseline and Change Control

Acknowledge uncertainty, and adapt to both external (market) and Typically constrain, or even completely eliminate any significant
internal changes, by modifying plans and approach. Use engineering change other than dropping features. Work to initial plans, even when
principles to make code base easy to modify. they are proven to be invalid.

Iteration & Continuous Improvement Lessons Learned at the End

Retrospectives at the end of each iteration allows teams to reflect, learn Negative feedback is rarely if ever given, and it is only done so when it
and continually improve by continually adapting. is too late.

Small, Integrated Teams Silo Teams with Handoffs

Small team size, and overlap in skills sets, simplifies communications,
allows everyone to see the big picture, creates self discipline and provides Staff works in functional oriented groups, throwing documentation
flexibility. and code over the wall.

Focus on Highest Value First All or nothing

Align project, product and team visions by prioritizing by business needs,
and using well architectured code, to deliver better quality products faster Tight coupling, and a bias toward building out the internals in a
and cheaper. breadth first fashion, means that nothing can be delivered in isolation,
even it’s valuable.

13
 Key Principles of Agility
Key Agile principles are:
Focus on Customer Value --
Delivering Customer Value with
Align project, product and team visions to deliver Agile Project Management
better product quality – faster and cheaper.
Small Batches -- The right product, at the right time,
for the right price:
Create a flow of value to customers by
“chunking” feature delivery into small •Higher Quality: “Designed-to-fit”
increments. product with flexibility to change.
Rather than doing all of one thing at a time. We
•Increased Throughput: Iterative
do a little of everything all the time
and incremental project and
Small, Integrated Teams -- product “chunks” with earlier value
delivery.
Intense collaboration via face-to-face
communication, collocation, etc; diversified roles •Reduced Waste: Lean, efficient
on integrated, self-organizing, self-disciplined
teams. processes with lower costs and
higher productivity.
Small, Continuous Improvements --
Teams reflect, learn and adapt to change; work
informs the plan.
 Agile Myths & Misconceptions

Agile is not:
• New
• A silver bullet
• A solution to resource issues
• Without planning, documentation, architecture…
• A license to hack
• An excuse for poor quality
• Undisciplined
• About throwing away areas of expertise
• Unproven
• Used only on the lunatic fringe

15
Scrum Process Overview
 What is “Scrum?”

According to Wikipedia:
“Scrum (formerly scrummage), in the sports of rugby union
and rugby league, is a way of restarting the game, either
after an accidental infringement or when the ball has gone
out of play.”

Scrum, in our case, is

an iterative and
incremental project
delivery framework.

17
 The Origin of “Scrum”

“The … ‘relay race’ approach to

product development … may conflict
with the goals of maximum speed and
flexibility. Instead a holistic or ‘rugby’
approach — where a team tries to go
the distance as a unit, passing the ball
back and forth - may better serve
today’s competitive requirements.”

Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development
Game”, Harvard Business Review, January 1986

18
 Exercise – Batch Throughput

Four volunteers, please!

Round 1
• Each person flip all pennies
• When done with entire batch, pass to next person
Round 2
• Each person flip one penny and pass to next person
• Keep flipping and passing until done
Round 3
• The team creates their own rules to maximize penny flow/throughput in
least amount of time

Total time: 10 minutes

19
 What is “Scrum?” What is “XP?”
Scrum is a lightweight process for managing and controlling software and product development in rapidly changing
environments. XP is a set of engineering practices that leads to a development process that is more responsive to
customer needs and increases quality. Both embrace change as a natural aspect of software development.

Scrum
• Self-organizing teams
• Emphasizes communication and cooperation
• Product progresses in a series of 2-4 week long
“sprints”
• Requirements are captured as items in a list of
“product backlog”

XP
• Small releases • Team Code Ownership
• The Planning Game • Coding Standards
• Refactoring • Simple Design
• Testing • Metaphor
• Pair Programming • Continuous Integration
• Sustainable Pace • On-site Customer

20
 Some Basic Terminology
Extreme
Scrum Programming Nationwide Term Definition
(XP)
Fixed-length period of time. CT will
Sprint Iteration Iteration
leverage a 4 week iteration cycle.

Release Small Release Release Release to production

Sprint/Release Iteration/Release
Planning Game Agile planning meetings
Planning Planning

Product Owner Customer Product Owner Business representative to project

“Lessons learned”-style meeting that

Retrospective Reflection Retrospective
occurs within each iteration

ScrumMaster Project Manager Iteration Manager Agile Scrum Master

Daily Scrum Daily Standup Daily Standup Brief daily status meeting
 The Scrum Process
Scrum projects make progress in a series of “sprints” (analogous to Extreme Programming iterations). A
Typical duration is 2–4 weeks or a calendar month at most. A constant duration leads to a better rhythm.
Requirements are documented in small User Stories.

Key Difference with Scrum:

• Multiple opportunities to inspect and adapt – transparency is key
• Daily Scrum, Sprint Review, Retrospective – inform and shape the work

23
 Agile overview

Note: The above is a representative view of the Scrum Agile process as shown during the kick-off meeting. This does not
represent the details of the iteration process to support Nationwide’s CT implementation of ClaimCenter.

Day 1 Day 2 Days 3 through 27 Day 0

24
 Iteration Timeline
y –
sda y 0)
ay n e Da
y d ay sd ed &
r id a on Tue 7- W 2 8( y
1- F 2- M Iteration 6 -
y2 y a
y y y2 Da Da ursd
Da Da Da Th

Rest Day: Start Iteration Iteration Close: Show & Tell & Day 0 Planning
Planning:
•Review & •Formal •Code Freeze •Prep for

Leads & Stakeholders

Leads & Key Functional personnel •Show & Tell
Leads & Key Functional personnel

Prioritize Communication •Program Standup Iteration Show (product owner)

Leads

Backlog •Backlog •Review what was

All
& Tell: •Retrospective
•Story cards & (product owner) completed phase
Tasking •Define Goals & (subject matter)
Acceptance Criteria
•Perform Capacity •Day 0 Initial

Program Leads
Planning alignment on
next iteration
elements

25
 The Iteration
Necessary coordination of the team rooms; Configuration,
Integration, Conversion, & Infrastructure until defect-free Daily
work is finished and demonstrated
Scrum
Meeting

Jeff Program Leah

Jay Functional Dan

Scrum of Scrums Iteration

Leads Rommel Michelle Requirements Development and
Meeting
Testing
Retrospective
Hector Tim
Unit Test
OCM

4 WEEKS

Task 1 Task 1
Task 2
Task 3 Enhancements Defect
Management Show & Tell

Days 3 through 27 Day 0

26
 The iteration (continued)

Example Product Backlog Iteration Work Products

1. Business requires to search for policy using License
• Provide ability for user to search for Auto
Plate
Policy during FNOL
2. Policy Search screen configured with License Plate
field
• Integrate with Policy System X 3. Interface Mapping confirms License Plate field from
policy system web service and includes it in GW
mapping

Necessary coordination of the team rooms; Configuration,

Integration, Conversion, & Infrastructure until defect-free Daily
work is finished and demonstrated Scrum
Meeting

Lea
Jeff Program h

Scrum of Scrums Jay Functional Dan Iteration Retrospective

Leads Mi Requirements
Meeting Rom ch
mel Testing ell
Hec e Development and
OCM Tim
tor

4 WEEKS Unit Test

Task 1 Task 1
Task 2
Task 3 Enhancements Defect
Management
Show & Tell

27
 The Scrum Process vs. Waterfall
Quality
Design & Development &
Requirements Assurance & Implementation
Architecture Coding
Software Testing

X X
Inspect Inspect Developer System Test
Requirements Design Performs Performance
Documents Documents Unit Testing Test UAT

Working Code
VS.
Inspect Daily Working Code Working Code
(Daily Scrum) (Sprint 1 Review) (Sprint 2 Review)

Sprint 1 Sprint 2 Sprint 3

Business Analysis

User Experience

Architecture & Infrastructure

Coding & Refactoring

Testing
28 28
 Inception phase model
Program

Functional
Jeff Leah
Work Stream Driven
Configuration
Jay Dan

Integration
Niles
Al
h
Conversion
Nikhi
Brian
l
Infrastructur
e
Sand Mart
eep y
OCM
She Sea
khar n
Testing
Hecto
Tim
r
Rom Mich
mel elle

29
 The transition
Inception

Jeff Program Leah

Jay Dan

Iteration 1
Functional

Rommel Testing Michelle

Hector OCM Tim

30
Execution model
Jeff Program Leah

Jay Functional Dan

Rommel Testing Michelle

Hector OCM Tim

31
 The Scrum Process at Nationwide

The Scrum Process at Nationwide includes a

definition of ready prior to brining work to the
team and definition of done prior to release.
ST
Bu R In D /
si e Sprint
Pr
PT
ne o /

ss a o UA

Ca d ce n T/
Rel
se ss e eas
y e

32
 Bringing Work to Standing Teams

Fixed Requirements Cost Date

Value-
Driven
Plan-
Driven $

Estimated Cost Date Features

Source: DSDM

33
 Definition of “Done”

Your Team is “Done” with a User Story when, in a

Sprint:
• Objective Code Quality is met
• Acceptance Criteria are met
• Other jointly specified “Done” criteria are met

You are “Done” with a User Story when, in a

Release:
• The Story is in production and delivering value
• Users & Customers will likely Buy/Use the
37 product, given the User Story’s current state
 Dialogue – Defining “Done”

At your table, discuss answers to the

following questions:
• What does “done” mean to a programmer? Your
team?
• What does “done” mean to your client or
customer?
• What are the consequences of these definitions
being different?
• How will you ensure a common definition?

Total time: 5 minutes

38
 All Together Now…
Initial Planning The Sprint Cycle

Discovery
Session Sprint

Release Sprint Daily Sprint

Planning Planning Scrum Review

Retrospective

Product Backlog Sprint Backlog Production-Ready Features

39
 Small, Integrated Team Structure

Designer Developer Tester

Traditional Silos Customer PM BA

Scrum & XP Team Release

Manager The Extended Team
can contain many
Capacity
Architect
BA / Planner additional
Tester
members, each
The Core Project Designer BA
playing an
Team ideally Core important role, but
consists of 5-9 Risk Developer /
SM Prod.

dedicated members
Assessor BA
Team they are typically
(EXAMPLE) not dedicated to
(7 +/- 2). Developer Tester
the effort.
Product
Tech Owner
Security
Ops

Business
Sponsor

40
 Integrated Team Structure

Designer Developer Tester

Traditional Silos Customer PM BA

Release
Manager
Integrated Agile Team
The Core Project Team Program Program
Architect Manager
ideally consists of 5-9 RA
Extended Team
members (7 +/- 2). Bus SME Arch

Developer
Core Tester
Product
ADL Owner
Team
Developer Tester

IM
Solution Security
Lead

Business
Sponsor
 Scrum Roles & Responsibilities

There are only three roles defined in Scrum:

Product Owner ScrumMaster The Team

●
●Owns Product vision
●
●Responsible for facilitating ●
●Small group containing all
●Defines features, decides on
● process necessary project skills
●Focuses Team and protects
release date and content ●
●Focuses on steady delivery
●
●Responsible for market
●
them from external
of high quality features
success interruption ●Generates options for
●
●Prioritizes features according
● ●Looks for ways to enhance
●

to market value productivity

delivery
●Manages own work within
●
●Can change features and
●
●Assists Product Owner in
●

priorities every Sprint leveraging Scrum Sprints

42
Agile and Corporate Internet Scrum Roles
There are only three roles in Scrum:
Product Owner, ScrumMaster, The Team.

Product owner Iteration Mgr (ScrumMaster) The Team

• Define the features of the • Responsible for enacting • Typically 5-9 people
product Scrum values and practices • Cross-functional:
• Be responsible for the • Removes impediments • Programmers, testers, user
profitability of the product • Ensure that the team is fully experience designers, etc.
(ROI) functional and productive • Members should be full-time
• Prioritize features • Enable close cooperation • May be exceptions (e.g.,
according to market value across all roles and functions database administrator)
• Adjust features and priority • Shield the team from external • Teams are self-organizing
every iteration, as needed  interferences • Ideally, no titles but rarely a
• Accept or reject work • Represents team at scrum of possibility
results (‘DONE’) scrums • Membership should change
• Facilitates Show and Tell only between sprints
 Scrum meetings
• Iteration Manager will facilitate scrum
meetings
• Meeting attendees will report on
• Accomplishments in last 24 hours
Daily
Scrum • Plans for Next 24 hours
Meeting • Roadblocks Scrum of Scrums Leads Meeting
• Iteration Manager will track progress
against each team room’s respective
trackers • Occurs Tuesday’s & Thursday’s
• Leads of each team room will attend. One
designated Iteration Manager will facilitate
this meeting
• Meeting attendees will report on
• Accomplishments of team since last
meeting
• Planned work for team up through
next meeting
Iteration Manager • Roadblocks impacting or dependent
• Will manage roadblocks: on other team rooms
• Resolve or remove them
• Socialize at Scrum of Scrums
• Convert to issue or risk
• Escalate if needed
• Maintain pace of meeting

44
Planning Overview
 Agile Uses Rolling Wave Planning

Rolling Wave Planning, used in Agile processes, embraces the Lean

ideal of making decisions at the last responsible moment, when the
most possible information is available. This maximizes flexibility and
planning accuracy.

Level of Planning Planning Approach

Strategic product line goals Strategic Planning
Strategic product goals Product Planning
Specific problems to solve Lean / Six Sigma
Large functional goals Release Planning
Small, well-defined work items Sprint Planning
Tactical organization & execution Daily Scrum

46
 The Big Picture

Discovery
Planning
Goals
Release
Planning Feature Sets
Feature Sets

Stories
Sprint Tasks

Planning

Daily
Standup

47
 “Incrementing” = A Bit at A Time

Incrementing calls for a

fully formed idea.
On time delivery requires
dead accurate estimation.

1 2 3 4 5

49
 “Iterating” = Rough -> Polished“

Iterating allows you to

move from vague idea
to realization.

1 2 3 4 5

50
 Work is Organized by Value

Work in Agile projects is organized by Units of Value, rather than by Architectural

Layer.

Feature / User Story 1 Feature / User Story 2 Feature / User Story 3

User Interface Layer

Business Logic Layer

Persistence Layer

51
 From Idea to Execution
Product Backlog Sprint Planning Sprint Backlog Sprint
PB Item Priority SB Item Priority
Team pulls and
User Story High User Story High completes Tasks
until each User
User Story High Top priority Task 1 Story is done.
stories are
User Story High discussed and Task 2
decomposed
User Story Medium into Tasks for
Task 3
User Story Medium the Sprint User Story Medium
Backlog.
User Story Medium Task 1
User Story Medium Task 2
User Story Medium Task 3
User Story Medium User Story Low
User Story Low Task 1
User Story Low Task 2

52
 User Stories at a Glance
Product user to create
Allow a Backlog a free
User Story
Key Characteristics account.
• High-level descriptions of desired
functionality and goals Estimate
• Implement “vertical slices” of the Priority
system’s functionality 1 week
• “Contracts for conversation,” not Allow a user to enter
all-inclusive requirements 1 (High) personal information.

• User stories wait in the Product Estimate

Backlog until pulled into the Priority
Sprint Backlog Allow a user to enter
4 hours
billing information.
• Contain Acceptance Criteria to 1 (High)
define “Done” Estimate Sprint Backlog
User Stories
Priority
8 hours

2 (Medium)

User Stories, Pg. 120

53
 Why User Stories?

Words are imprecise

Main Dish comes with soup
or salad and bread.

Does this mean

• (Soup or Salad) and Bread
• (Soup) or (Salad and Bread)

54
 What Makes a Good Story?

Ron Jeffries’ 3 Cs Independent

Card Negotiable

Conversation Valuable

Confirmation Estimable

Small

Bill Wake’s INVEST Testable

55
 User Story Template

As a <type of user>, I can

<immediate goal> so that
<business outcome>.

56
 User Story Template
• Start with a title
• Add a concise description often
using this useful template:
As a [type of user]
I want to [perform some task]
so that I can [reach some goal]
• Add other relevant notes,
specifications, or sketches
• Before building software write
acceptance criteria (how do we
know when we’re done?)

© Jeff Patton, all rights reserved, www.AgileProductDesign.com

57
 User Story Template
The “Spike” User Story
Spike (gridiron football)
From Wikipedia, the free encyclopedia

“In gridiron football, a spike of the ball is a play in which the quarterback
intentionally throws the ball at the ground immediately after the snap. A
spike is technically an incomplete pass, and therefore, it has the effect of
stopping the clock and exhausting a down.”

A “Spike” User Story In Scrum:

• Similar to Football, the team needs to access the situation, mitigate risk,
explore or investigate the unknown, research something
• Usually time boxed (e.g. 3 days,)
• In some cases the “spike” will remove an impediment that is blocking some
other user story.

58
 From User Stories to Tasks
Allow a user toStory
User enter personal Tasks
information. • Design user interface
• Develop CSS/HTML
Estimate • Create database fields
• Develop validation criteria
Priority • Write test cases
4 hours • Code test fixtures
• Unit testing
1 (High) On back… •
Acceptance Criteria Acceptance testing
• Address validated against
• Usability testing
reference • Write online help text
• Phone number contains no alpha
characters, min. 10 digits
• Name and email address
required

59
 User Story Acceptance Criteria

Acceptance Criteria help us determine when

we’re Done.
As a user, I can cancel a reservation.
• Verify that a premium member can cancel the same day
without a fee.
• Verify that a non-premium member is charged 10% for
a same-day cancellation.
• Verify that an email confirmation is sent.
• Verify that the hotel is notified of any cancellation.

60
 Start with Epics then iterate

As a Frequent
Flyer I want to As a Frequent Flyer I want to
check my book a trip using miles.
account.

As a Frequent Flyer I want to

As a Frequent rebook a trip I take often.
Frequent
Flyer I want to
Flyer book a trip.
As a Frequent Flyer I want to
request a upgrade.

As a Frequent
As a Frequent Flyer I want to
Flyer I want
see if my upgrade cleared.
to…

61
 Why User Stories?

1) Stories shift the focus from writing to talking

2) Stories are equally understandable by developers
and customers
3) Stories support and encourage iterative
development
4) Stories are the right size for planning
5) Stories support participatory design
6) Stories emphasize the users goals systems
attributes
Mike Cohn, User Stories Applied

62
 Real Life Example

63
 Simulation – Fantastic Food Finder

Vision
The Fantastic Food Finder (FFF) application will
provide mobile phone users with on-demand
information about restaurants in their
physical proximity through a clean, quick
interface.

Business Case
Restaurants would pay a small fee when users
clicked on their links, and could also pay for
marquee placement.

64
 Simulation – Creating User Stories

Write User Stories for the Fantastic Food

Finder project.
• Create at least 5 User Stories
• Write Acceptance Criteria for at least 3 stories
Concept

Things to consider: Fe atu re s

Fe atu re s

 As a <User Role>, I can <Immediate Goal> so that Stories

Stories
Tasks
Tasks

<Business Outcome>.
 Who are the various users?
 What business processes are involved?

Total time: 20 minutes

65
Agile Estimation
 Two Kinds of Estimation

Stories High Level Estimation – At

the User Story level

Tasks

Detailed Estimation – At the

task level

67
 High Level Estimation

Stories

High Level Estimation – At

the User Story level

• Traditional methods are often inaccurate even under the best

circumstances
• We do not have sufficient detail yet to estimate using traditional
methods
• Agile uses another method that is lightweight but fairly accurate
• We’ll call it “empirical estimation”

68
 Agile Estimation Units

Two popular units of estimation:

• Story Points

Estimation Ability
o Purely relative measure of complexity
(2 is half as hard as 4)
o Variability averages out across many
stories
o Don’t decay over time
Project Progress

• Ideal Developer Days Estimation is a necessary

o About 4-5 hours, on average evil for initial scoping, but
should rapidly be replaced
o Direct linkage to absolute time by empirical observation of
Team output capacity.

69
 Agile Estimation Sequences

Scales with increasing gaps between elements

are preferred:
• Fibonacci: 1, 2, 3, 5, 8
• Doubles: 1/2, 1, 2, 4, 8 
• “T-Shirt Sizes:” S, M, L, XL

Avoid false precision to avoid false expectations.

70
 Exercise – Zoo Points

At your table, assign “zoo • Lion

points” to the animals • Kangaroo
based the combination of
their size and weight. • Rhinoceros

Total time: 5 minutes • Bear

• Giraffe
• Gorilla
• Hippopotamus
• Tiger

71
 Using Velocity to Measure Capacity

“Velocity” is the Agile way to measure a team’s capacity.

Initial Velocity is a guess; every subsequent Velocity figure will be
calculated based upon empirical observation

Velocity = Sum of estimates for User Stories completed last Sprint

Example: Team estimated 36 points worth of User Stories, but
completed 28 points; this is their current Velocity.

Average Velocity = Sum of N Previous Sprint Velocities / N

This can be useful in Release Planning; taking an average of multiple
Sprints can balance Velocity fluctuations.

72
 Velocity Calculation

Story Estimate Status at End of Sprint

As a Prospect, I can submit an application. 2.5 Pts* Complete
As a Policy Holder, I can update my account 4 Pts Complete
information.
As an Account Representative, I can view a 4 Pts Complete
Policy Holder’s information.
As an Underwriter, I can approve or reject 5 Pts 1 Pts Remaining
applications.
Total Sprint Velocity 10.5 Pts

* Pts = Story Points

Next Sprint,
10.5 Pts would be our
projected capacity.

73
 Velocity Tracking

Velocity over Last Eight Sprints

16

14 Velocity stabilizes as
12 business & technical
10 domain knowledge
increase and Teams
Velocity

8
move from forming
6
& storming to
4 performing.
2

0
1 2 3 4 5 6 7 8

Sprint Number

74
 Simulation – Estimating User Stories

Using the Planning Poker Cards.

• Estimate your User Stories

Things to consider:
 Focus on Size not Duration
 Estimates should be relative to each other Concept
 It may help to pick a “reference story” – one
story where everyone agrees on the estimate. Fe atu re s

Fe atu re s

Stories
Stories
Tasks
Tasks

Total time: 20 minutes

75
Release Planning
 Release Planning at a Glance

Description
Initial project planning session, Discovery
Session
to review initial Product Backlog Sprint
and set production Release
dates. Release Sprint Daily Sprint
Planning Planning Scrum Review

Duration Retrospective

2-4 hours
Product Backlog Sprint Backlog Production-Ready Features

Attendees Outputs:
Team, Product Owner,  Release Plan
ScrumMaster  Refined Product Backlog

Release Planning, Pg. 119

77
 Planning Releases
Velocity = 14 points per Sprint Sprint 4

Story K 3 Story L 8
Sprint 1

Story A 5 Story B 3 Story M 2

Story C 5 Story G 1
Release 1

Sprint 2
1. Guess a starting velocity (14 in this case)
Story D 2 Story E 5 2. Choose which stories must exist to
Release and see how many Sprints are
Story F 2 Story I 5 needed, or…
Work backwards from the Release date
to fit as many high-value stories as
Sprint 3 possible
Story H 8 Story J 5 3. Adjust the scope within the Release as
true Velocity becomes apparent

78
 Planning Releases with Story Maps

Move User Stories below Access Review Update

record history record
the line to defer them to a
subsequent Release. Workflow Sequence

Provide Provide View Enter

• Choose coherent Nurse ID Patient ID history updates
groups of features that
consider the span of Search Add Notify of
RELEASE 1
business functionality comment

Priority
records updates
and user activities
Sort Search Reference
• Support all necessary RELEASE 2 records history validation
activities with the first
release Filter
records
• Improve activity
support with
subsequent releases

79
 Sample Release Plan

80
Sprint Planning
 Sample Product Backlog

Priority Backlog item Acceptance Criteria Estimate

1 Allow a guest to make a • Confirmation email is sent 3
reservation • Must be made >24 hours in
advance
2 As a guest, I want to cancel a • Confirmation email is sent 5
reservation • Must be canceled 15 days in
advance
3 Guest can change reservation … 3
dates
4 Hotel employee can see … 8
future reservations for her
hotel
5 Improve exception handling … 15
41 … … 50

82
 Sprint Planning at a Glance

Description
Meeting to elaborate, estimate Discovery
Session
and prioritize highest-value User Sprint
Stories, creating Sprint Backlog.
Release Sprint Daily Sprint
Planning Planning Scrum Review
Duration
Retrospective
2-4 hours
Product Backlog Sprint Backlog Production-Ready Features

Attendees
Team, Product Owner, Outputs:
ScrumMaster, SMEs  Estimated & Prioritized User Stories
 Acceptance Criteria for User Stories
 Sprint Backlog with Tasks

Iteration Planning, Pg. 121

83
 Iteration Planning
Task 1
Task 2
Task 3

Product Backlog Iteration Planning Meeting Iteration Backlog

► Prioritized list of requirements; story ► Iteration Manager facilitates meeting ► Reconfirm estimates
cards and epics ► Team selects only those Backlog Items ► Add additional tasks
► Product Backlog Items selected for an that it can commit to deliver by end of ► Update existing tasks
iteration and is the basis to create the Iteration ► Assign Tasks to team resources
Iteration Backlog, Goals, and Objectives

Example Story Card Tasks

• Provide ability for user to search for Auto 1. Determine Business Requirements for
Policy during FNOL Policy Search (Functional)
2. Configure GWCC Policy Search Screen
(Configuration)
• Integrate with Policy System X 3. Map Policy Interface (Integration)

Day 1 Day 2
84
 The Big Picture

Discovery
Planning
Goals
Release
Planning Feature Sets
Feature Sets

Stories
Sprint Tasks

Planning

Daily
Standup

85
 Product Backlog Essentials

Adding User Stories High priority items

• Anyone can suggest new User Stories are better defined
• Product Owner prioritizes them
# Backlog Item Estimate
Estimating & Elaborating
1 Create login screen .5
• High-priority items are estimated and
…
described most precisely, since they will be
20 Allow user to browse 8
worked on first recently viewed items
• Low-priority items are generally estimated …
and described coarsely 60 Add personalization 30 (or so)

Prioritizing
• Prioritization is based on “Business Low priority items are
Value…” often “epics”

86
 Sprint Planning – Sample Agenda

• Review velocity and set Sprint capacity

Identify anything unique about the coming sprint (vacation, holidays, etc.)
• Select Sprint Goal (Optional)
• Select top-priority User Stories from Product Backlog
Select slightly more than capacity, aligned with Sprint goal as appropriate
• Discuss User Stories to create Tasks & Acceptance Criteria
• Estimate User Stories
Base on individual task estimates, sticking to about 1-16 hours/task
• Commit to User Stories
Select until capacity is reached, with some backup stories discussed in case Team
finishes early

87
 Sprint Backlog at a Glance

Description
List of desired functionality for Discovery
development in the current Session
Sprint
Sprint.
Release Sprint Daily Sprint
Planning Planning Scrum Review
Key Characteristics
• Contains User Stories Retrospective

estimated at task level

• Acceptance tests defined Product Backlog Sprint Backlog Production-Ready Features

Managed by Contains:
Team, ScrumMaster  Prioritized User Stories & their constituent tasks
 Task-level estimates
 Other information necessary to understand the
tasks at hand

88
 Physical Task Boards

89
 Electronic Task Boards

Mingle
Thoughtworks

Rally Enterprise
Rally Software
VersionOne
Enterprise
VersionOne GreenHopper (Jira)
GreenPepper Software

90
 Electronic Story Board
RTC: Plan/Feature/Story/Task Management

Rational Team Concert (RTC)

Example Screen Shot

Electronic and physical story

boards need to be kept in sync
Execution Overview
 Sprint at a Glance

Description
When the work gets done!
Discovery
Session Sprint
Duration
1-3 weeks
Release Sprint Daily Sprint
Planning Planning Scrum Review

Key Characteristics
Retrospective
• Isolated from further change
• Requirements elaborated and Product Backlog Sprint Backlog Production-Ready Features
refined
• Work organized adaptively
Outputs:
Involves  Potentially shippable functionality
Team, ScrumMaster, Product
 Other necessary items, as prioritized by
Product Owner
Owner, SMEs

93
 Sequential vs. Overlapping Development

Design Develop Integrate Test

Rather than doing all of one We do a little of everything

thing at a time all the time

Source: “The New New Product Development Game”, Hirotaka Takeuchi and Ikujiro Nonaka, Harvard Business Review, January 1986.

94
 Roles of The Team

The Team ….
• Works cross-functionally on
common problems to reduce
handoffs
• Shares roles when needed to
get the work done (e.g.
“generalizing specialists”)
• A developer may write user documentation
• A business analyst may perform testing
• A tester may create graphics

95
 Roles of The Team

The Team ….
• Is not just an order-taking entity; it gives ideas and constructive
feedback to the ScrumMaster and Product Owner
• Develops the detailed task list and the estimates
• Agrees to and then makes sprint commitments
• Self organizes to get the work done (not tasked)
• Raises issues to the ScrumMaster
• Reviews burndowns and suggests solutions
• Assesses performance and makes process recommendations

96
 Sequential vs. Overlapping Development

Effective Agile teams organize their work so that it flows:

• Critical path activities are never stalled by work on lower-priority
activities (which may or may not arise in a future Sprint)
• Decisions are made at the last responsible moment
• Hand-offs are minimized in favor of synchronized collaboration

Sprint 1 Sprint 2 Sprint 3

Business Analysis

User Experience

Architecture “Spikes”

Coding & Refactoring

Testing

97
 Sequential vs. Overlapping Development

Product and UE should be working 2 Sprints ahead of Development:

• User Stories, detailed requirements, wireframes, visual design specs,
information architecture etc.. .should be completed just in time for the next
Sprint.
Sprint 1 Sprint 2 Sprint 3
Business Analysis

User Experience

Architecture “Spikes”

Coding & Refactoring

Testing

If Development is Coding Sprint #1

Product and UE need to be Done with Sprint #2 and Working on #3

98
 Daily Scrum/Standup Meeting

Each participant answers 3 questions:

1 What did you do yesterday?

2 What will you do today?

3 What’s in your way?

• Reference specific tasks (at the task board if possible)

• Record & Review Risks and Issues
• Team members should speak to one another; this is an alignment tool,
not a reporting exercise

99
 Collaboration through Collocation

• Information transfer
maximized through
collocation

• Constant face-to-face
communication and
collaboration

• Self-organization and
management
facilitated by
information radiators
– charts, posters,
whiteboards, etc.

100
 Collaborative Work Spaces
Information Radiator
• Model floor workspace for
open communication
• Create collaborative
workspaces for each team
• Collocate team members
• Provide space for whiteboards,
charts and other “information
radiators”
• Ensure separate private spaces
and meeting spaces
Information Radiator

101
 Team Room Example

1. Portable easel
2. Smart board
3. Risks & Issues noted
4. Magnetic whiteboard
5. Plant needs water
6. Task board
7. Pair programming station
8. Status tracking by color
9. Nice chairs

102
Agile Engineering
 Agile Engineering Practices

Agile Engineering Practices allow teams to move fast

and be flexible.
• Simple Design & Refactoring keep incremental
development from leading to poor architectures
• Automated Testing & Test-Driven Development
reduce testing time and effort and allow developers
to make changes with confidence
• Continuous Integration & Automated Builds reduce
time and effort associated with manual builds, and
risk from big-bang integrations

104 Agile Engineering, Pg. 124

 Agile Engineering Practices (cont.)

Basic Agile Engineering practices include:

• Continuous Integration
o Tight build-and-test cycle control
o Ant, CruiseControl
• Test Driven Development
o Evolutionary design
o Unit, system and acceptance tests
o N-Unit
o HttpUnit, FitNesse
• Simple Design
• Refactoring

105
 Test Driven Development Basics

The basic cycle of Test Driven Development is:

• Describe a User story
• Define Acceptance criteria
• Write executable tests, watch them fail
• Write working, unit-tested software
• Watch the executable tests pass
• Refactor working, unit-tested software to the
appropriate level of quality

106
 Continuous Integration & Automated Builds

In order to minimize waste associated with big-bang integrations

, Agile teams aim to integrate as often and with as little
manual intervention as possible.

Screens from CruiseControl, a

popular automated build and
continuous integration tool.

107
Monitoring Overview
 Daily Scrum/Standup Meeting

Each participant answers 3 questions:

1 What did you do yesterday?

2 What will you do today?

3 What’s in your way?

• Reference specific tasks (at the task board if possible)

• Record & Review Risks and Issues
• Team members should speak to one another; this is an alignment tool,
not a reporting exercise

109
 Physical Task Boards

110
 Physical Iteration Story Board
Done
1. BSD/IDD/Requirements complete
Feature Backlog Ready for Pickup In Progress Ready For Signoff 2. Production Ow ner 'Accepted'
Requirements

Done
1. Development complete
2. Unit Test complete
3. Test scripts w ritten
4. Test scripts run w ith no errors
5. Acceptance criteria met
Backlog (Requirements Done) Ready for Pickup In Dev Ready for Test In Test Ready for Sign Off 6. Product Ow ner ‘Accepted’

Config
Dev/Test

Conversion

Integration

111
 Scrum of Scrums Meeting

“Scrum of Scrums”
Frequent meeting to manage cross-project dependencies.
Participants
• One or two representatives from each team
• Selected based on subject matter expertise in current focus area
• Rotate over time
Four questions answered by each participant
• What has your team done since we last met?
• What will your team do before we meet again?
• Is anything slowing your team down or getting in their way?
• Are you about to put something in another team’s way?
Differences from Daily Scrum
• Not always daily; may be 2-3 times/week
• Problems can be discussed in meeting

112
 Burndown Chart – Tracking Work Remaining

Description 900 843

813
772 777
Simple tool for Team to track 800 752 751
733
701 694
progress during a Sprint. 700 656 641
608
583
600

500
Key Characteristics
360
400
• Shows work remaining, not 321

300
work completed 180
200
• Allows analysis of true Team 123
55
100
capacity 22
0
0

12-Mar

14-Mar
6-Mar

8-Mar

10-Mar

16-Mar

18-Mar

20-Mar

22-Mar

24-Mar

26-Mar

28-Mar

30-Mar
Managed by
Team, ScrumMaster

113
 Example: Integrated Backlog & Burndown

Current progress
Likely finish (Average velocity over last 8-12 Sprints)
Pessimistic finish (Average worst 3 velocities)
Optimistic finish (Average best 3 velocities)
Thanks to Mike Cohn for this visualization

114
Adapting Overview
 Small, Continuous Improvements

The initial plan.

• Agile processes assume that baselines will change

significantly during the project.
• In such an unpredictable environment, empirical methods
should be used to monitor progress and direct change,
rather than using definitive methods to try and predict
progress and stop change.
The best plan.

Reality is messy. Inspect & Adapt.

116
 Sprint Review at a Glance

Description
Team demonstrates completed Discovery
Session
functionality to interested Sprint
stakeholders, gathering
feedback. Release Sprint Daily Sprint
Planning Planning Scrum Review

Duration Retrospective

2-4 hours
Product Backlog Sprint Backlog Production-Ready Features

Attendees Outputs:
Team, Product Owner,  New Features on Product Backlog
ScrumMaster, optionally Users  Reprioritized Product Backlog
& Interested Stakeholders  Revised Team or Project Structure

117
 Sprint Review Agenda

• Describe Sprint context

Briefly outline Sprint goals and other contextual info

• Present Completed User Stories

Demo live functionality completed in prior Sprint

• Record Customer & User Feedback

• Adjust Product Backlog

oRemove completed functionality
oReprioritize unfinished functionality
oAdjust priorities based on feedback

118
 Tuning the Process - Retrospective

Description
Team continuous improvement Discovery
Session
session to reflect on project & Sprint
process issues and take action
as appropriate. Release Sprint Daily Sprint
Planning Planning Scrum Review

Retrospective
Duration
30 minutes – 1 hour
Product Backlog Sprint Backlog Production-Ready Features

Attendees Outputs:
Team, ScrumMaster, optionally  Process revisions
Product Owner  Project or Team structure revisions
 Other improvement action items

119
 Sprint Retrospective Essentials

The useful way to do “Lessons Working Well Not Working Well

Learned:” Automated unit 6am Daily Standup

testing
• Periodically take a look at Customers highly Testing team
satisfied availability
what is and is not working in
Retrospectives have Build cycle time
your process improved process
• Typically 15–30 minutes Estimates are Product Owner
stabilizing availability
• Done after every sprint Action Items
• Whole team participates Set SLA with QA PO delegates to
team proxy during Sprints
• Generates action items to 8am standup
continuously improve
project execution

120
 Quantitative Sprint Retrospective

Simple scorecards (applied carefully!) can be

useful ways to track team progress.
Metrics Tracked Sprint 1 Sprint 2 Sprint 3
Stories completed 7 8 6
Acceptance rate 100% 87.5% 100%
Deferral rate 0% 12.5% 0%
Defects at Sprint start 2 0 1
Defects at Sprint end 0 1 0
Total Tests 52 92 150
% Test Coverage 100% 98% 99%

121
 Iteration retrospective

• Iteration Manager will facilitate the

Integration iteration retrospective to obtain a list Conversion Infrastructure
Configuration
of opportunity areas for future
iterations

• These compiled lists of opportunity

areas will be presented to the
Program during their Iteration
Retrospective for action on those
items

Program
Functional Testing
OCM

122
 Session Two:
Project Simulation
Discovery
Simulation
Reflection
 Project Simulation
Simulation Agenda
– Discovery 20 Minutes
– Release Planning 15 Minutes

– Sprint 1 Planning 15 Minutes

– Sprint 1 15 Minutes
– Sprint 1 Review 15 Minutes
– Sprint 1 Retrospective20 Minutes

– Sprint 2 Planning 15 Minutes

– Sprint 2 15 Minutes
– Sprint 2 Review 15 Minutes
– Sprint 2 Retrospective15 Minutes

124
 Reminder - The Big Picture

Discovery
Planning
Goals
Release
Planning Feature Sets
Feature Sets

Stories
Sprint Tasks

Planning

Daily
Standup

125
 Simulation – Fantastic Food Finder

Teams
Everyone should select a role on the team. Remember
at minimum you need:
• One Iteration Manager (ScrumMaster)
• One Business Analyst (Product Owner)
• One Technical Lead
• One QA Lead

Business Case
Product Owners – join me at the front to introduce the
business case.

126
 Simulation – Fantastic Food Finder

Vision
The Fantastic Food Finder (FFF) application will provide
mobile phone users with on-demand information about
restaurants in their physical proximity through a clean,
quick interface.

Business Case
Restaurants would pay a small fee when users clicked on
their links, and could also pay for marquee placement.

127
 Project Simulation

Simulation Agenda Concept

– Discovery 15 Minutes
• Clarify the objectives & vision Fe atu re s

Fe atu re s

• Understand the business drivers & expectations Stories

Stories
Tasks
Tasks

• Identify key stakeholders and stakeholder need

• Determine the critical success factors
• Identify the high level features
• Identify the high level IT architecture
• Identify & Prioritize Core Scope
• Generate the Initial Backlog – High Level Epics

128
 Project Simulation

Simulation Agenda Concept

– Release Planning 15 Minutes
• Identify & Prioritize Core Scope Fe atu re s

Fe atu re s

• Generate the Initial Backlog – High Level User

Stories
Stories
Tasks
Tasks

Stories
• Estimate the High Level User Stories
• Build the Initial Release Plan

Things to consider:
 As a <User Role>, I can <Immediate Goal> so that <Business Outcome>.
 Who are the various users?
 What business processes are involved?

129
 Project Simulation

Simulation Agenda Concept

– Sprint Planning 15 Minutes
• Review velocity and set Sprint capacity Fe atu re s

Fe atu re s

• Select Sprint Goal (Optional)

Stories
Stories
Tasks
Tasks

• Select top-priority User Stories from

Product Backlog
• Discuss User Stories to create Tasks &
Acceptance Criteria
• Estimate User Stories
• Commit to User Stories Things to consider:
 Focus on Size not Duration
 Estimates should be relative to each other
 It may help to pick a “reference story” – one story
where everyone agrees on the estimate.

130
 Project Simulation

Simulation Agenda Concept

– Sprint 10 Minutes
• Create a paper prototype of your User Fe atu re s

Fe atu re s

Stories Stories
Stories
Tasks
Tasks

– Sprint Review 10 Minutes

• Review your Sprint goals
• Demonstrate your accomplishments
during the Sprint to the class

Things to consider:
 Did you uncover the need for new Stories?
 Did you learn anything in the Sprint that makes you
want to re-estimate items in the Backlog?
 Where your Stories “Ready”?

131
 Session Three:

Making the Transition

Roadmap for the Perplexed
 Roadmap for the Perplexed
• Understand the basics – “small is beautiful”
– Small batches
– Small, integrated teams
– Small, continuous improvements
• Adjust the focus, sharply on customer value
• Exchange the model - swap the plan-driven
model for the adaptive model
• Adapt the tools, don’t jettison them
• Managers focus on context, teams on content
• Change is gradual and costly, not immediate
and free

133
 Understand the Basics – “Small is Beautiful”

Key Agile principles are:

• Small Batches - Create a flow of value to customers by
“chunking” feature delivery into small increments.

• Small, Integrated Teams - Intense collaboration via face-to-face

communication, collocation, etc; diversified roles on integrated,
self-organizing, self-disciplined teams.

• Small, Continuous Improvements – Teams reflect, learn and

adapt to change; work informs the plan.

134
 Small Batches, as seen in the Scrum Process

Initial Planning The Sprint Cycle

Discovery
Session
Sprint

Release Sprint
Daily Scrum Sprint Review
Planning Planning

Retrospective

Product Backlog Sprint Backlog Production-Ready Features

Identify
Identify top-priority
top-priority items
items and
and deliver
deliver them
them rapidly
rapidly using:
using:
•• Small
Small batches
batches
•• Small
Small integrated
integrated teams
teams
•• Small,
Small, continuous
continuous improvements
improvements

135
 Translation of PM Process Groups to Agile Processes

Initiating Perform project discovery and visioning.

Perform Product Backlog feature development and

Planning prioritization, and release and sprint planning.

Employ iterative and incremental development to create

Executing potentially shippable work products every sprint. Deliver
multiple small releases.

Monitoring & Inspect and adapt via daily stand-up, sprint demo, information
Controlling radiators and sprint retrospectives.

Deliver final release and perform final sprint/iteration

Closing
retrospective.

136
 Small, Integrated Teams

Product Developer Tester

Designer
Traditional Silos Owner
PM BA

Release
Integrated Agile Team Manager
The Core Project Team ideally consists
of 5-9 members (7 +/- 2). Capacity
Architect
Planner
BA
Extended
Designer BA Project Team

Risk Developer
Core Project Prod.
PM
Assessor Team

Developer Tester
Product
Tech Owner
Security
Ops

Business
Sponsor

137
 Small, Continuous Improvements

• Agile processes assume that baselines will change

significantly during the project. The initial plan.
• In such an unpredictable environment, empirical
methods should be used to monitor progress and
direct change, rather than using definitive
methods to try and predict progress and stop
change.
• The linear “plan-driven” mindset needs to be
replaced with a “adaptive” mindset that embraces The best plan.
change.

Reality is messy. Inspect & Adapt.

138
 Adjust the Focus, Sharply on Customer Value

• Business customers directly drive product Delivering Customer Value with Agile Project
Management
development
• End-user feedback is obtainable early The right product, at the right time, for the
right price.
• Quality is “built in” at every step of the •Higher Quality: “Designed-to-fit” product
process with flexibility to change.
• High throughput and low waste are the •Increased Throughput: Iterative and
primary process organizing goals incremental project and product “chunks”
with earlier value delivery.

•Reduced Waste: Lean, efficient processes

with lower costs and higher productivity.
We need this… Not this.
Value
Product Value

Expectations
Expectations
Business
Business

Product
Product
Value
Value

s
eesss nnss
Product

i
si n
n oo
BBuus ccttaatiti
pee
EExxp

139
 Exchange the Model - Swap Plan-Driven for Adaptive

Aspect Plan-Driven Model Adaptive Model

Planning • Fine-grained, monumental • Coarse and fine grained,
up-front continuous

• Collaborative workspaces
Execution • Batch operation with late, • Iterative and incremental
intermittent feedback and late operation with constant
value delivery feedback and early value
delivery
• Silo-ed specialty teams
with handoffs • Integrated, cross-functional
teams with continuous flow
• 1-way task dispatch – task
assignment • 2-way commitment – task
self-selection
Control •Sacrosanct baselines • Value adjusted baselines
•Corrective Action (Plan the •Adaptive Action (Inspect and
Work, Work the Plan) Adapt)

140
 Adapt the Tools, Don’t Jettison Them

• Project charter
• Rolling wave planning
• Feature breakdown
structures
• Design documentation
• Design reviews
• Test automation
• Usability engineering Source: Managing Agile Projects, Sanjiv Augustine, Prentice-Hall 2005

While tools and documents need to be “sufficient-to-purpose”… Agile does

not preclude the use of existing tools.

141
 Managers Focus on Context, Teams on Content

• Managers need to look upward and outward

toward stakeholders and sponsor
• What are the project’s end goals or desirable
outcomes?
• What are its objectives?
• What is its scope?
• How does it relate to other projects?
• On what other projects/factors does it depend?
• What value will it add to the organization?
• How will it contribute towards achieving the
organization’s strategic goals?
• What is the strategy to deal with external changes?

• Team members are responsible for technical

content

Source: The Thomsett Company. Used with permission.

142
 Change is Gradual and Costly

• Change is hard and takes time

• The team needs to take ownership
• Team members must self-discipline

When defining quality, knowledge workers

need to first define:
• What is our business?
• Who is our customer?
• What does our customer consider valuable?

Controls must flow from the above.

143
 Group Discussion – Changing Responsibilities

Do you think your responsibilities will

change with Scrum? If so, how?
• How will my day-to-day work change?
• How will I work more closely with
other team members?
• Do I foresee any issues?

Total time: 5 minutes

144
 Session Four:
Advanced Topics
Metrics and Reporting
Risk Management
Distributed Delivery
Resource and Portfolio Management
Metrics & Reporting
 Transparent Reporting

Agile reporting is grounded in transparency.

Some tips for effective reporting:
• Use Sprint Reviews as a primary means of
reporting progress
• Use what you never had with Waterfall; the
product!
• Report in the language of the business
• Fit metrics and reports to specific needs; don’t
simply do them pro forma if you have an option

147
 Measuring Value

Goal Unit Measurement Approach Current Tolerance Limits

State LSL USL Target

Fast account Minutes Start time: User selects to 15 min - 10 5 min

registration open an account min
process Stop time: Welcome email
sent (after processing)
Approach: Take difference
between timestamp of web
server request for
newAccount.jsp and time
when welcome email is sent.

• Value is fully realized when Goals are met

• Progress towards Goals (%) represents earned value

148
 Tracking “Earned Value”
• Goal represents 40% of business case
• “User account registration” Feature represents
Goal

70% of Goal value

• “Enter billing information” User Story realizes
Fast account registration
60% process value
of Feature
.4
• % Value Realized = .4 x .7 x .6 = 16.8%
Feature

User account registration Account processing

.7 .3
User account registration Account processing
.7 .3

As
As aa User,
User, II can
can enter
enter personal
personal information.
information. As
As aa User,
User, II can
can enter
enter billing
billing information.
information.
.4
.4 .6
.6 As an Accou nt Processor, I can activate a User accou nt.
1
As an Accou nt Processor, I can activate a User accou nt.
1
User Story

149
 Example: Budget Burn

Budget Burn

$180,000
$160,000 $153,580
$137,760
$140,000
$121,310
$120,000 $105,070
Dollars

$100,000 $89,040
$80,000 $70,770

$60,000 $52,920
$38,500
$40,000
$21,000
$20,000
$2,520
$0
1 2 3 4 5 6 7 8 9 10
Weekly Burn $2,520 $18,480 $17,500 $14,420 $17,850 $18,270 $16,030 $16,240 $16,450 $15,820
Total $ Used $2,520 $21,000 $38,500 $52,920 $70,770 $89,040 $105,070 $121,310 $137,760 $153,580
Estimate $150,000 $150,000 $150,000 $150,000 $150,000 $150,000 $150,000 $150,000 $150,000 $150,000
Weeks

Weekly Burn Total $ Used Estimate

150
 Example: Team Diagnostics

Quality Metrics Productivity Metrics

Metric Name Planned Worked
Sprint Bug Report Days Days
Total bugs opened during 1
Bill 15 8
Sprint
Mike 15 15
Bugs currently open 0
Bugs fixed and verified 1
Kevin 15 13
Bugs fixed 0 Sherry 5 5
Susan 15 15
Tom 15 12
Eric 10 6
Vijay 15 15
Total 195 138

151
 Example: Tracking Scope Changes

Stories Removed
Story Points
System Infrastructure (Bulkload, 4
Archive Retrieval, Promotion)
As an analyst, I no longer have any 6
manual involvement in the
suppression process.
Total 10
Stories Added
Story Points
As a customer service rep, I can offer 4
customers cross-sell items.

Total 4

152
 Summary: Tracking & Reporting Value

To effectively track & report Value:

• Align project outputs directly with Value
• Report in a manner that recipients will
understand
• Use Diagnostic metrics to adapt project
approach and improve Team performance
• Use Business Value metrics to report progress to
stakeholders and manage the Product Backlog

153
 Dialogue – Your Reporting & Metrics

At your table, take 5 minutes to discuss

answers to the following questions:
• What sorts of reports and metrics do
you currently utilize?
• Are they effective tools for decision
making?
• Can you think of ways that they could
be improved?

154
Risk Management
 Risk Management Techniques

Risk Management on Agile Projects happens at

several levels:
• Implicit risk management via user story
prioritization and technical discipline
• Explicit risk management via integrated risk
mitigation stories
• Scenario planning for risk-driven “fire-drills”

156
 Implicit Risk Management

Implicitly managing Risk:

• User stories are prioritized by the Product Owner
o Highest value items are attacked first
o Highest risk items are also attacked early

• Iterative delivery ensures that integration and rollout risks are

attacked very early in the project lifecycle

• Technical discipline helps keep a tight rein on development risk

o Automated builds and continuous integration keep code integration
and code quality risk to a minimum

157
 Explicit Risk Management

Explicitly managing Risk:

•Review the Product Backlog
Risk Impact Probability Mitigation Plan
•Identify and list risks by impact
(High/Medium/Low) and probability Key
employee
HIGH MEDIUM Process Implementation
• Pair Programming
(High/Medium/Low) dependency (Jones)
• Rotation (Augustine)
•Provide a mitigation plan with clear
responsibility
•Create task cards for risk mitigation
items Agency HIGH HIGH Agency Liaisons
dependencies • Agency 1: Smith
•Insert into Product Backlog and/or • Agency 2: Patel

Sprint Backlogs

158
 Scenario Planning
SCENARIOS
Scenario Planning: 1. Bleak Week - Client Down, Agency Down
- Documentation

• ‘Memory’ of the future 2. Client Up, Agency 1 Down

- Integration/Release

• Don’t try to predict

- Data Map
- Screen Layouts
- Load Testing

outcome 3. Client Down, Agency Up

- Polling Request

• Instead, use “fire-drills” - Loan Transfer

4. Client Down, Agency Sort of Up

to prepare the team for - Polling Request

different possible 5. Great Week - Client Up, Agency Up

- Everything!

outcomes 6. Client Sort of Up, Agency Sort of Up

- Polling Request
- Integration/Release

159
 Dialogue – Risk Management

At your table, take 5 minutes to discuss answers to the

following questions:
• How do you identify and mitigate project risk today?
• Are your current tools and techniques effective?
• Can you think of ways by which they could be
improved?

160
 Dialogue – Agile Engineering

At your table, take 5 minutes to discuss answers to the

following questions:
• Are you currently utilizing Agile Engineering
practices on your projects?
• What are some “next steps” you might take to
improve your engineering practices and processes?

161
Distributed Delivery
 Distributed Daily Scrum Models
New York Hyderabad

Isolated Scrum Teams

Independent Daily Scrums.
Daily Scrum Daily Scrum

Distributed Scrum of Scrums

Regular Scrum of Scrums. Scrum of
Daily Scrum Scrums Daily Scrum

Integrated Scrum Team

Team members split across locations. Daily Scrum

Source: http://jeffsutherland.com/scrum/2006/06/distributed-scrum-agile-project.html

163
 A Distributed Scrum Case Study

We will examine a distributed Scrum joint project

led by Xebia, a Dutch Agile consultancy, with
teams split between India and the Netherlands.
The Project: ProRail, the IT arm of the Dutch railways, needs a
system to distribute real-time information about train arrivals &
departures to all stations throughout the Netherlands.

The Approach: Xebia creates distributed Scrum teams in the

Netherlands and India, and finishes in under a year.

Fully Distributed Scrum: The Secret Sauce for Hyperproductive Offshored Development Teams by
Sutherland, Schoonheim et al

164
 Bootstrapping & Scaling Distribution
Netherlands India

3 week Discovery + 2 Sprints

Netherlands team kicks off.

Sprints 3-6
India team joins and integrates.

Sprints 7-21
India team members return home, and both
locations scale up (3 distributed teams, 1
local).

165
 Distributed Scrum Results

The project nearly matched the productivity and

collaborative efficiency of a collocated Scrum team.
• Sprint Planning
averaged 4 hrs
• Daily Scrums were
15 minutes or less
• Retrospectives
averaged 2 hours

Fully Distributed Scrum: The Secret Sauce for Hyperproductive Offshored Development Teams by
Sutherland, Schoonheim et al

166
 More Suggestions for Virtual Teams

• Use continuous integration

• Send ambassadors
• Use wikis for common project info
• Use test scripts to understand requirements
• Short iterations
• Regular builds
• Separate teams by functionality, not activity
• Expect more documents
Check out Martin Fowler’s article http://martinfowler.com/articles/agileOffshore.html#
UseContinuousIntegrationToAvoidIntegrationHeadaches

167
 Dialogue – Distributed Delivery and You

At your table, take 5 minutes to discuss answers to the

following questions:
• Roughly what percentage of your projects utilize
distributed teams?
• How do you currently communicate and plan work in
these projects?
• What are some of your key challenges?
• What have you tried to address these challenges?

168
Resource & Portfolio
Management
 Exercise – Theory of Constraints

Four volunteers, please!

Round 1
• Complete your task as quickly as possible; you’ll be
judged by the size of your outbox.

Round 2
• Wait until your outbox is empty before starting
work on another plane.

Total time: 5 minutes

170
 Traditional Portfolio Management

Projects & Resources

• Run many projects concurrently,
with similar priorities
• Split resources between multiple
projects ROI

• Stress maximum resource

utilization
• ROI only after projects are done

Time

171
 Costs of Task-Switching

100

80
Value-Adding Tasks
Percent of Time on

60

40

20

0
1 2 3 4 5

Number of Assigned Tasks

Source: Managing New Product and Process Development, Clark and Wheelwright, p. 242, 1992

172
 Costs of Over-Utilization

Source: The Lean-Agile PMO, Sanjiv Augustine and Roland Cuellar (Cutter Consortium 2006)

173
 Lean Portfolio Management

Lean project portfolios:

• Dedicate core resources to Projects & Resources

each project team

• Ensure that each team has all
resources needed to ROI
complete projects
• Stress maximum project
throughput
• ROI delivered incrementally Time
with each project release

174
 Lean-Agile PMO Structure

• Encourage face-to-face dialogue across levels

• Overlapping management with “linking pins”
• Lean-Agile PMO run as an Agile project team

Source: The Lean-Agile PMO, Sanjiv Augustine and Roland Cuellar (Cutter Consortium 2006)

175
 Lean Scheduling
• Avoid too many
simultaneous projects
• Exercise leadership:
prioritize your projects and
focus your teams
• Delay commitment; delay
expenditure
• Deliver continuously in
small batches versus
delivering infrequently in
huge batches

Source: The Lean-Agile PMO, Sanjiv Augustine and Roland Cuellar (Cutter Consortium 2006)

176
 Manage the Flow

• Track project flow

• Manage the on-ramp
• Terminate sick projects
• Break large projects into small ones

Source: The Lean-Agile PMO, Sanjiv Augustine and Roland Cuellar (Cutter Consortium 2006)

177
 Dialogue – Analyzing Your Portfolio

At your table, take 10 minutes to discuss

answers to the following questions:
• How are projects in your organization currently prioritized?
• Do the prioritization mechanisms above align with your
organization’s strategic imperatives? Do they tend to result in
measurable business value?
• What is your current project-to-performer ratio?
• How long (on average) does it take to deliver small, medium
and large projects in your organization?

178
 Agile Methods: A Warning

Change is tough.
• Staff turnover may occur
• Management turnover may occur
• Conflict will occur
• Product Management’s job will
change and be harder
• Development is responsible for retaining quality
• Compensation policies will change
• Management’s activities will shift from command to leadership
• Adding more people will no longer be the answer
• Change will occur throughout the enterprise

179
Thank You!
 Resources − Groups & Articles
Online Discussion Groups
• Agile Project Management, http://finance.groups.yahoo.com/group/agileprojectmanagement/
• Scrum Development, http://groups.yahoo.com/group/scrumdevelopment/
• Extreme Programming, http://groups.yahoo.com/group/extremeprogramming/
User Groups
• APLN DC Chapter, http://www.aplndc.org
• APLN NYC Chapter, http://www.aplnnyc.org
• Agile Philly, http://wiki.agilephilly.com/index.php?title=Main_Page
• Agile Atlanta, http://agileatlanta.org/
• Agile Alliance User Group Listing, http://www.agilealliance.org/show/1641
Articles
• One-Page Introduction to Agile, http://www.lithespeed.com/resources/1-Page-Intro-to-Agile.pdf
• The New Methodology, http://www.martinfowler.com/articles/newMethodology.html
• Getting Started with Agile Delivery, http://www.gantthead.com/article.cfm?ID=230943&authenticated=1
• So, How’s that Agile Initiative Doing?,
http://www.gantthead.com/article.cfm?ID=230943&authenticated=1
• Agile Project Management: Emergent Order through Visionary Leadership,
http://www.ccpace.com/Resources/documents/AgileProjectManagement.pdf
• The Lean-Agile PMO: Using Lean-Thinking to Accelerate Agile Delivery,
http://www.cutter.com/project/fulltext/summaries/2006/10/index.html

181
 Resources − Blogs, Web sites, Books
Blogs
• http://lithespeed.blogspot.com
• http://www.leadinganswers.com
• http://www.agileadvice.com

Web Sites
• http://www.scrumalliance.org
• http://www.agilealliance.org
• http://www.apln.org

Books
• Agile and Iterative Development: A Manager’s Guide, Craig Larman
• Managing Agile Projects, Sanjiv Augustine
• Lean Software Development – An Agile Toolkit, Mary and Tom Poppendieck
• Agile Adoption Patterns, Amr Elssamadisy
• Lean Software Development – Concept to Cash, Mary and Tom Poppendieck
• Agile Software Development, Alistair Cockburn
• Agile Project Management, Jim Highsmith
• Agile Software Development with Scrum, Ken Schwaber and Mike Beedle
• Agile Estimating and Planning, Mike Cohn
• User Stories Applied, Mike Cohn
• Fearless Change, Linda Rising and Mary Lynn Manns

182
 Resources − Case Studies
Case Study Title Company Link
Scrum at the BBC BBC http://www.infoq.com/news/2006/12/Scrum-bbc-newmedia
Agile Excels at BMC, Programming BMC Software http://biz.yahoo.com/bw/070910/20070910005634.html?.v=1
Technique Provides Customers Higher
Quality Products in Record Time
Capital Ideas (Interview with CIO) Capital One http://www.busmanagement.com/pastissue/article.asp?
art=268776&issue=222
Agile 06 Interview with Bud Phillips, VP Capital One http://agiletoolkit.libsyn.com/index.php?post_id=116686
Decisioning Services
HMV delivers a fresh and vibrant HMV Digital http://www.conchango.com/Web/Public/Content/Clients/CaseStudyD
service to digital music fans etails.aspx?PageID=76
Empirical Evaluation of Agile Software Microsoft http://www.researchchannel.org/prog/displayevent.aspx?
Development Processes: Industrial Research rID=4316&fID=922
Case Studies (various)
Agile Secret Sauce SalesForce.com http://blogs.salesforce.com/adwords/2006/04/agile_secret_sa.html
Shopzilla Scales Software Agility With Shopzilla http://www.agilejournal.com/articles/case-study/case-study%3a-
Agile Tools shopzilla-scales-software-agility-with-agile-tools.html

183