1

ADM/Scrum Training
May 2008
Agenda
Introduction
Review Agenda
Determine timing, logistics and breaks
2
Customer Exercise
The Scenario
In this exercise, you and your team need to produce a market
shattering new product
Your product must offer some essential functionality that is
already in the marketplace (straight lines)
e.g. if it were an email application, you would have to offer the ability to send
mail or you would never succeed
Its also very important for you to gain market share by creating
excellent new functionality that the market hasnt seen yet! (curvy
lines)
3
What Were Going To Do
Were going to split into teams
Decide amongst yourselves who will play the role of:
Customer
Product Owner
Delivery
The other teams are your competitors
You must create an exact copy of the vision (minus the
copyright, title, border, and the lines do not need to be the same
thickness)
What You Need To Know
Customer: You have the vision of the product. You are the only
one who can see it.
Product Owner: You must translate what the Customer is looking
for and relay that to the Delivery team. You may make personal
notes but you cannot show them to the Delivery team.
Delivery: You must deliver the product. You will have paper and
pencil. You are the only one who can draw on the paper.
You have ten minutes to deliver the product
4
Introduction
Phased Development Process
(defined, waterfall)
Plan Design Build Test
Surprise!
Documentation,
Signoffs, Handoff
Documentation,
Signoffs, Handoff
Documentation,
Signoffs, Handoff
Great if you know exactly what you want
and wont change your mind
5
Changes with a Phased Process
Plan Design Test
Documentation,
Signoffs, Handoff
Documentation,
Signoffs, Handoff
Documentation,
Signoffs, Handoff
Change
Request
Build Bug Fix
Launch
Change interrupts the flow
start finish anal ysis design code test
The design of the waterfall means that we will always
be at our most vulnerable just when we least want to
be and that defects will be found where they are the
most expensive to fix.
test
One More Thing about Phased Development
start finish
project timeline
this is the place we would
least like to find any defects
6
Agile Development
Incremental releases
Short Iterations of 1-4 weeks
Feedback
Feedback Feedback
v1.0 v1.1 v1.2
Agile Development
Do a little bit of everything every cycle
Feedback
Feedback Feedback
Plan
Design
Test
Build
Fix Bugs
Plan
Design
Test
Build
Fix Bugs
Plan
Design
Test
Build
Fix Bugs
Plan
Design
Test
Build
Fix Bugs
7
Agile Development
Change Change Change
Feedback
Feedback Feedback
Expects change
Change enables learning
Its all in the System
Simple, clear purpose and principles give
rise to complex, intelligent behavior.
Complex rules and regulations give rise
to simple, stupid behavior. Dee Hock, VISA
8
Our Story
The Backstory
Fast
Innovative
Successful
Growing
9
7 years later
35,000+ customers
900,000+ subscribers
100+ Million transactions per day
200+ in Technology!
Butuh oh
10
Its getting harder
to get things done
11
so whats the deal?
Waterfall process
Un-predictable
Delayed releases
Velocity slowdown
No visibility
Late feedback
Technical Debt
Death march
Loss of cred
Over budget
Scope creep
Elegant
and a little messy
12
Core Values
KISS
Listen to your customers
Iterate
What is ADM?
ADM is a modified Scrum/XP style of product development
that is specific to Salesforce.
It employs Scrum project management framework and
adopts certain XP practices.
13
What is ADM?
Re-factoring
Self-organizing
Predictable releases
Transparent
Ftest - Selenium
Continuous integration
Debt free
Just-in-time
Iterative
Always Potentially Releasable
Time-boxed
User stories
Agile
Lean
Early feedback
Code Reviews
Collective Code Ownership
Self-correcting
Agile
14
Agile is a great buzzword.
Who doesnt want to be Agile?
No one says,
Thanks, Id rather be inflexible
and slow to respond.
Agile
Is a flexible framework of common values
The most popular are Scrum, XP, and
Lean
A Common-sense approach
15
Process and tools
Process and tools
Individuals and
interactions
Individuals and
interactions
over
The Agile Manifesto
Comprehensive
documentation
Comprehensive
documentation
Working software
Working software over
Contract negotiation
Contract negotiation
Customer
collaboration
Customer
collaboration
over
Following a plan
Following a plan
Responding to change
Responding to change over
While we value the items on the right, we value the items on the left more.
Agile Mythology.
16
This is NOT Agile
Cowboy coding
No planning
Poor quality
Compressing the schedule
The organization may gain short term speed but at the cost of
long term pain.
Agile Values
Communication
Simplicity
Feedback
Courage
Respect
17
Principles
Humanity
Economics
Mutual Benefit
Improvement
Diversity
Reflection
Flow
Opportunity
Redundancy
Self-Similarity
Failure
Quality
Baby Steps
Accepted Responsibility
Scrum
18
What is Scrum?
An agile project management framework for developing software
Simple
Prioritized work
Time-boxed, 30-day sprints
Often teams work in shorter timeboxes
Self-organized, empowered teams
Daily, verbal communication
Potentially production quality every
30 days
What is Scrum?
19
Eliminates waste
Increases throughput
Provides transparency
Looks very simple but very hard; it causes
change
Makes dysfunction very visible
What is Scrum?
Scrum is NOT
20
Scrum
Product Backlog 1
Scrum 101
7
8
9
10
11
12
1
2
3
4
5
6
13
No Changes
(in Duration or Deliverable)
Commitment
7
8
9
10
11
12
1
2
3
4
5
6
13
Daily Stand-up
3
Team Retrospective
Challenges
Testing
Build breaks
Improvement
5
Sprint Planning 2
Potentially Shippable
4
Sprint Review
Sprint
24 weeks
21
Planning
Prediction
To get predictability we need
to stop predicting
We need to make decisions
based on fact not forecasts.
22
Multi-Level Planning
Product Vision
Roadmap
Release Plan
Sprint Plan
Daily Plan
Q1 Q2 Q3
R1 R2 R3
Multi-Level Planning
Product Vision
Roadmap
Release Plan
Sprint Plan
Daily Plan
Q1 Q2 Q3
R1 R2 R3
23
Product Vision
Vision &
Roadmap
What is your market
Who are your customers
How you will make
money
What is your product
vision.
Multi-Level Planning
Product Vision
Roadmap
Release Plan
Sprint Plan
Daily Plan
Q1 Q2 Q3
R1 R2 R3
24
Minimum Market Feature Set
Always
7%
Often
13%
Sometimes
16%
Rarely
19%
Never
45%
Standish Group study reported at XP2002 by Jim Johnson, Chairman
Often or Always
Used: 20%
Rarely or Never
Used: 64%
Multi-Level Planning
Product Vision
Roadmap
Release Plan
Sprint Plan
Daily Plan
Q1 Q2 Q3
R1 R2 R3
25
Release Planning
Communicate a common
vision for the release
Initial Design
Align team on proposed
functionality
Determine target
functionality for the release
Release Planning
Groom User Stories small enough
to be effective for sprint planning
Determine the relative size of the
user stories in story points
Determine Release Functionality
based on velocity
Identify Dependencies
26
Release Planning in Scrum
Release planning is based on Velocity
Velocity is a measure of how much
Product Backlog the team actually
completes over time.
Product Backlog
Backlog Mapped out in Sprints
Silly features 17
To type 16
Monkeys want 15
Why would 14
Year 13
Webvan 12
Last 11
Areso 10
Cosmo 9
Networks 8
Social 7
Wiki 6
Dolls house 5
Movies for kids 4
Tick-tock feature 3
Clock 2
Feature 1
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Sprint 5
27
P
r
o
d
u
c
t

B
a
c
k
l
o
g
What will I have done by April?
S
i
l
l
y

f
e
a
t
u
r
e
s
1
7
T
o

t
y
p
e
1
6
M
o
n
k
e
y
s

w
a
n
t
1
5
W
h
y

w
o
u
l
d
1
4
Y
e
a
r
1
3
W
e
b
v
a
n
1
2
L
a
s
t
1
1
A
r
e
s
o
1
0
C
o
s
m
o
9
N
e
t
w
o
r
k
s
8
S
o
c
i
a
l
7
W
i
k
i
6
D
o
l
l
s

h
o
u
s
e
5
M
o
v
i
e
s

f
o
r

k
i
d
s
4
T
i
c
k
-
t
o
c
k

f
e
a
t
u
r
e
3
C
l
o
c
k
2
F
e
a
t
u
r
e
1
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6
Jan February March April May
Sprint Plan
Product Vision
Roadmap
Release Plan
Sprint Plan
Daily Plan
Q1 Q2 Q3
R1 R2 R3
28
Sprint Planning
Determine the Sprint Goal
Determine work necessary
to complete the goal (with
time estimates)
Make commitments for the
Sprint
Sprint Planning Meeting
Team dog piles on user
stories
Team figures out how to deliver
Sprint Goal even without a
resource on the team who
normally does a particular type
of work
Product Owner may negotiate
but Team always determines
what they can complete during
the sprint
29
Sprint Planning Step 1
Product Owner and team discuss the
latest product backlog and the
goals of the Sprint.
7
8
9
10
11
12
1
2
3
4
5
6
13
Sprint Planning Step 2
Team works out available hours for the Sprint
30
Sprint Planning Step 3
The team goes through the items in the
backlog
and breaks them into tasks
Each task is estimated
Team members volunteer for tasks
Stop when you are full.
Task: Configure database
and SpaceIDs for Trac
7
Sprint Backlog
Tasks necessary to
complete user stories
Many-to-one relationship
with user stories
Coding, testing, automation,
specs, doc, design, etc.
31
Sprint Backlog
Team expands items on the
Sprint Backlog into specific
tasks, time estimates in hours,
signs up for ownership
Critical that The Team
selects items and size for
Sprint Backlog
Managed through Scrumforce
Commitment Driven Planning
Take highest priority item
Decompose into tasks
Estimate each task (whole team)
Can we commit to this?
If yes, try another backlog item
If not, remove it but try a smaller one
No one signs up for tasks yet
32
Abnormal Terminations
In extreme circumstances the
Sprint may be terminated
Cost:
Everything reverts back to the
original state prior to the Sprint
planning meeting.
STOP
Estimation
33
Story points
Ideal days
Team days
T-Shirt Sizes
Hours
Common Product Backlog Estimating Units
High Level Estimates
Story Points
A measure of the relative size
of a feature
Based on how much and how
hard to do
Agreed-upon unit
Helps compare costs.
50 As a user I can create a profile to
display information about myself
8
As a guest, I can add one photo to my
profile page
Backlog item
Estimate
As a premium member I can add up to
ten photos to my profile page
5
As a premium member, I can add video
to my profile page
40
As a guest, I can add photos to my
profile page
30
As a user I can add people I like to a
hot list
30
34
Tracking
Tracking Progress
Track the work remaining
Do not track actual time worked
Update daily.
35
Task board tracking
70
Another sample task board
36
Burndown Charts
0.0
5.0
10.0
15.0
20.0
25.0
30.0
35.0
40.0
45.0
50.0
2
/
1
2
/
2
2
/
3
2
/
4
2
/
5
2
/
6
2
/
7
2
/
8
2
/
9
2
/
1
0
2
/
1
1
2
/
1
2
2
/
1
3
2
/
1
4
2
/
1
5
2
/
1
6
2
/
1
7
2
/
1
8
2
/
1
9
2
/
2
0
2
/
2
1
2
/
2
2
2
/
2
3
2
/
2
4
2
/
2
5
2
/
2
6
2
/
2
7
2
/
2
8
I
d
e
a
l

D
a
y
s
Actual Baseline
Production support
Resolution of dev
assumptions
Added Tasks
Added March Tasks!
37
38
Will this sprint finish on time?
M
o
n
d
a
y
0
50
100
150
200
250
300
T
u
e
s
d
a
y
W
e
d
n
e
s
d
a
y
T
h
u
r
s
d
a
y
F
r
i
d
a
y
M
o
n
d
a
y
T
u
e
s
d
a
y
W
e
d
n
e
s
d
a
y
F
r
i
d
a
y
T
h
u
r
s
d
a
y
350
Putting it into Practice
39
XP Game
This game is called the XP Game
Developers - estimate
Product owners - prioritize based on business value and estimate
Developers execute
Find easiest one and give number 2
There might be something easier in the future
Estimate other stories relative to 2
Think about complexity and time as it may be simple yet take a long time
There will be one release with three iterations, each of 3 minutes
YOU ONLY DO ONE STORY AT A TIME (together)
XP Game Iteration 1
40
Sprint Review
Sprint Review
A demo by the team of:
Complete
Fully tested
Potentially shippable features
Only functionality that meets
Done criteria is demoed
Team declares what they
committed to doing in the Sprint
and did not get done
Feedback from customers and
stakeholders drives design
changes for future sprints
This is the
Sprint Review
This is the
Sprint Review
Review
41
Sprint Review
User Story Doneness Checklist
User documentation complete and checked in.
All UI labels ready for localization vendors.
Usability testing scheduled when necessary, and feedback incorporated into
backlog.
UE has reviewed any new features; P1 and P2 UI bugs fixed.
Performance/scalability impact ascertained and sys testing scheduled if
required.
All resolved bugs verified and closed.
100% of test cases logged in QA Tracker and executed in a QA environment,
and all P1/P2 cases passing.
Code Coverage of 70% (or as agreed with team)
No open P1 & P2 bugs
No open regressions. Automated tests written and reviewed for all regressions.
Code checked in and follows department standards.
BT & Profile
Perm
Setup
Page
Handshake
POC
Done Criteria
User Stories
All defined Acceptance Criteria for a user story have been met.
Code
Code implementing the user story functionality is checked in and follows department standards.
No open regressions (you break it, you own it), with automated tests written for all regressions.
No open P1 & P2 bugs for the implemented functionality in the sprint.
Quality
Code Coverage of 70%
Test plan, cases and execution for sprint functionality, regression and cross functional test
cases related to sprint functionality, need to be 100% executed, and all P1/P2 cases passing.
All resolved bugs have been verified and closed for the sprint functionality.
Definition of Done
42
Performance/Scalability
Performance/Scalability impact of sprint functionality understood and quantified, and systesting
scheduled, if required, with the sys test team.
User Experience
UE reviewed new features or significant changes in the UI, feedback incorporated, all resulting
P1 and P2 UI bugs fixed.
Usability testing completed, feedback has been incorporated into the backlog.
Localization
All UI components have labels ready for localization vendors.
Documentation
User doc describing all aspects of sprint functionality complete / checked in.
Definition of Done
Retrospective
43
Sprint Retrospective
What is it?
A meeting at the end of
each Sprint so the team can
Inspect and Adapt the
process
Challenges
Testing
Build breaks
Improvement
Sprint Retrospective
How do you do it?
Team, Scrum Master and Product
Owner have a ~1-2 hr meeting
3 questions are asked:
Whats working
Improvements
Things to try in the next
Sprint
Challenges
Testing
Build breaks
Improvement
44
What a Retrospective is NOT
Retrospectives are NOT about blame
Problems arise. The focus is on what we can learn from what
happened
Retrospectives are NOT a witch hunt
Retrospectives are NOT about gathering specific
information
They are a free-flowing brainstorm on opportunities and ways
to resolve them
45
Iteration 2
Iteration 3
46
Getting Started
47
Determine your Team
Agile teams are cross-functional and persistent
Determine your Scrum Master
Determine your Product Owner
Assemble all cross functional members that can fully
perform all of the required functions
Get a coach (if you want one)
Roles
48
The Scrum Master
A facilitator and coach
Removes impediments
Protects team from external
influences
Improves productivity of team so
each user story is potentially
releasable
Keeps progress information up-
to-date and visible to all
Product Owner
Product visionary
Maximizes business value
Prioritizes the Product
Backlog
Fully engaged
49
The Scrum Team
Cross-functional
Shared Commitment
Self organizing, Self
correcting. Teams decide
best way to deliver
Members are dedicated
resources (as much as
possible)
Optimally 6-10 people
Managers
Remove impediments
Provide vision and
leadership
Provide resources
Less micro-management
and more enablement
50
Discuss: Roles
Does the ScrumMaster have to be a Project Manager?
Can one person serve as both ScrumMaster and
Product Owner?
Who manages the team members?
Who assigns tasks to the team?
Environment
51
Environment
Everyone in same location
Open space without barriers
Resources available; phone, whiteboards, meeting
space etc.
52
53
Not this
! ? !
Kicking Off
54
Kicking off
Product
Vision
Share understanding on:
The Product Vision
Your customers
The market
Why you are doing this and
what you hope to achieve.
Write a One-Pager
Elevator statement / Problem to sol ve
ForwhothatUnlikeHow do you know?
Who are our customers? Benefits
People who work in
Those who need a

How will we create business value?

Share content with
Personalized ads on

Risks?
Technology unknowns
Dependencies

Performance attributes
3000 hits/hour
3 clicks to get to core content
Scale to 100,000,000 users
Scope
Resources
Schedule
Quality
Fixed Firm Flexible
Sign-ups xxx

Milestones: dates or features to hit

Xyz features xxx
Abc features xxx
How do we know we succeeded? (metrics)
More
Flexible
Tradeoff Matrix

55
Brainstorming
Brainstorms are a good
way to gather
requirements for the
Backlog
Best when generated by
the whole team.
Hot list
Share photos
Share video
Mobile personals
Virtual
Speed dating
Create a Product Backlog
High Priority items at the top
Get less detailed as you go
down
Estimates high-level to help
compare items in relation to
each other.
50 As a user I can create a profile to
display information about myself
8
As a guest, I can add one photo
to my profile page
Backlog item
Estimate
As a premium member I can add
up to ten photos to my profile
page
5
As a premium member, I can add
video to my profile page
40
As a guest, I can add photos to
my profile page
30
As a user I can add people I like
to a hot list
30
56
Product Backlog
Key to success of Scrum
Master list of functional and non-
functional items desired in the
product (features, bugs, re-factoring)
Anyone can add to Product Backlog
Product Owner is the only person
that prioritizes Product Backlog
Includes relative estimate of size of
features (design, code, test,
automate, refactor, doc, fix bugs)
Product Backlog Sample
57
User Stories
Whats a User Story?
Basic unit of scope for an agile project
Describes a WHO, WHAT and WHY scenario
Describes real business value
A promise for a conversation
Very different from traditional requirements documentation which seek to
ensure all details are present in order to form a contract
Has acceptance criteria to assert its behavior.
58
A user story template
Backlog items can be written as User Stories
Express user needs in terms of what the user wants to
achieve
Example template for this:
As a <type of user>, I want to
<goal> so that <reason>
Acceptance Criteria
The product owners acceptance criteria should be added to a story
These are essentially tests
As a guest, I want to add
one photo to my profile
page so that my friends
can identify me
As a guest, I want to add
one photo to my profile
page so that my friends
can identify me
Verify user can upload
photo
Verify user can only upload
one photo
Verify confirmation message
displayed when photo is
uploaded
Verify premium upsell
appears on confirmation page
Verify user can upload
photo
Verify user can only upload
one photo
Verify confirmation message
displayed when photo is
uploaded
Verify premium upsell
appears on confirmation page
59
If in doubtINVEST!
Independent
Negotiable
Valuable
Estimable
Sized Appropriately
Testable
INVEST
A good user story:
I Independent
N Negotiable
V Valuable
E Estimable
S Small
T Testable
Hows this Story?
As: User
I want: a flexible extensible
framework that allows me to provide
web services access to my LDAP
database
So that: ???
60
What About this One?
As a Student
I want to receive email notification with appropriate detail when I submit a
pending registration request, whether I am confirmed or waitlisted, if a
class is cancelled, or if I self-withdraw from a class
So that I know my registration status, know where my class is located (if
confirmed), and know who to contact if I have questions.
A good user story:
I Independent
N Negotiable
V Valuable
E Estimable
S Small
T Testable
It could be re-written as:
As a student
I want to receive email notification when I submit a registration
request which informs me of my status
So that I know my registration status, know where my class is
located and know who to contact if I have questions
Acceptance criteria:
If student submits registration request and it is confirmed, ensure
email X is sent (with confirmation, class info and contact person)
[note: you may actually just include the email template here]
If student submits registration request and they are waited listed,
ensure email Y is sent
61
And
As an administrator
I want to be able to cancel a class and inform confirmed registered
students of the cancellation
so everyone is aware of the schedule change
Acceptance criteria:
Ensure a class can be cancelled by X action
Ensure cancellation email Z is sent to all registered students
Ensure cancellation email A is sent to waitlisted students
And
As a student
I want to be able to withdraw from a class
so that others can take the spot if I am unable to attend
Acceptance criteria:
Ensure student can withdraw by doing ABC
Ensure student receives confirmation email X
Ensure student is removed from class registration and if waitlisted
students are listed, the next one on the list is now emailed and
asked to register (or registered automatically etc)this one could
become its own story depending on the discussion with the dev
team as to complexity
62
Lets Write a Story
Exercise :
In 5 mins either alone or with a pair, write a user story for:
Making yourself a coffee
in terms of AS I WANT TO SO THAT
With two examples of acceptance criteria
Use the index cards provided, writing the acceptance criteria on the back
Questions
Who can contribute to the product backlog?
Who prioritizes the product backlog?
Do you have to use user stories?
How often is the product backlog reviewed and revisited?
63
Daily Scrum
Daily Scrum
> 15 minute meeting
What I did yesterday
What I plan on doing today
What is blocking me
64
Daily Scrum
Scrum Master facilitates stand up:
Side conversations are put on the parking lot
Blocks and issues are identified, and action plans are created
Follow-up on resolutions
Scrum Exercise
65
Scenarios
Exercise: Great Scrum Teams
Read the scenario
Take a few minutes to discuss with your team what a great
Scrum Master would do in this situation
Be ready to share your thoughts with the group
66
Scenario 1
The VP of the group appears in the middle of the Sprint,
and says to you: one of our clients has a special
request which if we can complete it, we will win $1
million in business.
Scenario 2
The product owner says that he's not going to be
available to attend the Sprint planning meeting, but he
doesn't mind if the team goes ahead and does it without
him.
67
Scenario 3
In the middle of the Sprint, one of the team members
manager comes and says she needs to pull him off the
project for a couple days, to work on something else.
Scenario 4
It's halfway through the Sprint, and the team is way
behind on progress. It looks like there's no way it's
going to finish what it committed to during the Sprint.
68
Scenario 5
One member of the team looks really unhappy. He
seems very distracted, and he's way behind on the
tasks that he committed to complete.
Scenario 6
One member of the team speaks up and says he thinks
the retrospective is a waste of time; several other
members of the team murmur in agreement, and
someone else suggests that the team stop doing the
retrospective.
69
Scenario 7
The team appears to be very stressed out. They are
having to work late most nights of the week, and they
even have to work Saturdays every now and again, in
order to meet their Sprint goals. You hear comments
like scrum is awful it forces us to work so hard.
Scenario 8
A team member has recently moved. He mentions that
he is trying to find daycare for his daughter and its
blocking him from doing his work.
70
Agile Practices
Some Agile Practices to Think About
Technical
Test first development
Continuous integration
Pair programming
Automated functional testing
Code Reviews
Coding Standards
Design
Simple design
Thin vertical slices
Architecture spikes
Team
Whole team
Cross functional
Self-organized
Retrospectives
Continuous improvement
Office Hours
Product Management
Minimum market feature set
Product Vision
Product Backlog
One Pager
User Stories
Project
Iterative delivery
Information radiators
Burndown charts
Scrumforce
Planning
Daily stand-ups
Release Planning
Sprint Planning
Sprint review meetings
71
What is ADM?
Re-factoring
Self-organizing
Predictable releases
Transparent
Ftest - Selenium
Continuous integration
Debt free
Just-in-time
Iterative
Always Potentially Releasable
Time-boxed
User stories
Agile
Lean
Early feedback
Code Reviews
Collective Code Ownership
Self-correcting
Scaling Agile
72
Large Projects are Hard
Generally more technically complex
Many people causing communication breakdowns
Lots of dependency management
Difficult to maintain transparency of overall progress
Scaling Top 4
Focus on communication!
Create ONE team
Get your team structures in line
Do continuous integration on the whole system
73
Building Teams
Avoid splitting across functional lines
QA in one location, Product owners in another, Engineering in a third
Integrations after completion of development
Delivery of business value at the end
Rather structure along features for a cross functional workstream
For ensuring business value and the customers advantage
Features shouldnt be split across teams
The feature provides a joint goal and thus enforces team spirit
Comprehends all necessary roles
Product Owner, Engineering, QA
Comprehends all necessary expertise
UED, database, configuration management
Some coordination roles must work across all workstreams
Chief Architect
Chief Product Owner
Scrum of Scrum Master
Scaling the Product Owner
Product
Owners
Product Line
Owners
Chief Product
Owner
74
Communication & Dependency Management
Scale Communication
Each workstream has their daily scrum
Use Scrum of Scrums to cross-communicate
Not limited to Scrum Masters, any functional role may
find this useful
75
The Four Questions
1. What has your team done since we last met?
2. What will your team do before we meet next?
3. Whats in your teams way?
4. What are you about to put in another teams way?
Scrum of Scrums
76
Scrum of Scrums of Scrums
Share Start and End Dates
Team 1
Team 1 Team 1
Team 1
Team 1 Team 1
Team 2
Team 2 Team 2
Team 2
Team 2 Team 2
Team 3
Team 3 Team 3
Team 3
Team 3 Team 3
Finish Finish Start Start
Team 1
Team 1 Team 1
Team 1
Team 1 Team 1
Team 2
Team 2 Team 2
Team 2
Team 2 Team 2
Team 3
Team 3 Team 3
Team 3
Team 3 Team 3
Dont stagger sprints like this:
Synchronize sprint starts instead
77
Build Some Infrastructure Initially
Architecture
Development environment
Standards
Interfaces
Some tangible piece of business value
Share the Product Backlog
Its usually best to share a common product backlog
among all of the teams
Think of one product backlog with multiple views into it
78
More Items For the Product Backlog
1. Devise and implement coding standards
2. Establish an approach to having customers develop
acceptance tests
3. Set standards for frequency of checking in code
4. Investigate and implement code review (or pair programming)
5. Upgrade working environment and tools for teams
Integrate the Builds
Midnight
2 a.m.
3 a.m.
79
Tracking, Transparency and Tools
With Size Comes Process
Provide a framework for cohesion but dont stop teams from
making their own decisions
Remember good project management--record risks and critical
path
Avoid the temptation to start with lots of complex process
If it works at one level, looks for ways to scale it up
Only add process when its needed
80
Release Tracking Work Remaining
I
t
e
r
a
t
i
o
n
1
0
50
100
150
200
250
300
420
(Story Points)
I
t
e
r
a
t
i
o
n

2
I
t
e
r
a
t
i
o
n

3
I
t
e
r
a
t
i
o
n

4
I
t
e
r
a
t
i
o
n

5
I
t
e
r
a
t
i
o
n

6
I
t
e
r
a
t
i
o
n

7
I
t
e
r
a
t
i
o
n

8
I
t
e
r
a
t
i
o
n

9
I
t
e
r
a
t
i
o
n

1
0
I
t
e
r
a
t
i
o
n

1
1
Ideal
Actual
Tools
Electronic tools still need to be easy
Focus of a tool is to provide transparency to whole team
Should roll-up all teams progress towards end goal
Should allow for teams to take on others work if one team is at risk
Recognize the need for redundancy
Using electronic tools should not stop teams for using physical cards
and burndowns
81
Resources
External Resources
Scrum
http://www.scrumalliance.com
http://www.controlchaos.com
http://www.mountaingoatsoftware.com
Yahoo Groups:
scrumdevelopment@yahoogroups.com
extremeprogramming@yahoogroups.com
agileprojectmanagement@yahoogroups.com
agileusability@yahoogroups.com
agile-testing@yahoogroups.com
82
Further Reading
Agile Project Management with Scrum
by Ken Schwaber
User Stories Applied by Mike Cohn
Agile Estimating and Planning by Mike Cohn
Agile Retrospectives: Making Good Teams Great by Esther
Derby and Diana Larsen
Lean Software Development:
Mary Poppendieck
Congratulations!
Any questions?
ndourambeis@salesforce.com
83