Transcript Working on a Scrum Team - Day 1

Working on a
Scrum Team
Making the case for Agile –
What we’ve been doing isn’t working
According to the 2006 report, 35 percent of
software projects started in 2006
completed on time and on budget. "The
primary reason is the projects have gotten
a lot smaller. Doing projects with iterative
processing as opposed to the waterfall
method, which called for all project
requirements to be defined up front, is a
major step forward."
article
Success
Source: Chaos Report from Standish Group
(2001).
2
 On time
 On budget
 With all planned features
And what is delivered isn’t always used
Never
Percent of Software
Features Used
45%
19%
Rarely
7% Always
16%
13%
Frequently
Sometimes
Source: The Standish Group (2002).
3
Best known Agile methodologies
Scrum
 XP – Extreme Programming
 DSDM – Dynamic Systems Development
Method
 Crystal
 FDD – Feature Driven Development

4
Collaborative, whole team
Collaboration on activities
 Communication-centric
 Cross-functional
 Co-location

5
Common shared vision and goals
Vision flows into the team
 Clear focusing goals
 Emphasis on delivering intent
 Allow space for creative problem solving

6
Iterative and incremental
Time boxed development cycles
 Process activities parallel and concurrent
 Activities applied to smaller work units
 Frequent delivery of completed product
 New product increments built on existing
working product
 Product kept continually up to standards

7
Agile and adaptive control
Incremental planning practices
 Heavy emphasis on feedback and visibility
 Frequent adaptation towards iteration
goals
 Continuous reflection and improvement
 Self-organizing, peer teams
 Distributed, local, direct decision making

8
Emphasis on being lean
Traveling light
 Deliverables developed based on concrete
need
 Elimination of hand-off artifacts
 Removal of waste in the process
 Preference towards simplicity
 Emergent development tactics

9
We have come to value:
10
Individuals and
interactions
over
Processes and tools
Working software
over
Comprehensive
documentation
Customer
collaboration
over
Contract negotiation
Responding to
change
over
Following a plan
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.
11
Scrum origins

Wicked Problems, Righteous Solutions
by DeGrace and Stahl, 1990.


First mention of Scrum in a software
context
Jeff Sutherland
 Initial Scrums at Easel Corp in 1993
 IDX and 600 people doing Scrum
 Not just for trivial projects


12
FDA-approved, life-critical software for x-rays
and MRIs
Ken Schwaber
 ADM
 Initial definitions of Scrum at
OOPSLA 96 with Jeff Sutherland
Scrum has been used in…
Independent Software
Vendors (ISVs)
Offshore development
Small to medium-sized
startups
Fortune 100 companies
13
Internal development
Contract development
Characteristics







14
One of the agile processes
Self-organizing teams
Product progresses in a series of month-long
sprints
Requirements are captured as items in a list of
product backlog
No specific engineering practices prescribed
Uses generative rules to create an agile
environment for delivering projects
Proven scalability
The waterfall process
1) What are the problems you see with the
waterfall approach?
2) What are some ways organizations deal with
them?
3) How would you solve them?
15
Overview
24 hours
Daily Scrum
Meeting
Sprint Backlog
Backlog tasks
expanded
by team
2-4 weeks
Product Backlog
As prioritized by Product Owner
16
Potentially Shippable
Product Increment
Why do this?

With Scrum, you can
 Remove risks early
 Cancel projects earlier
that aren’t going to
succeed
 Change priorities without penalty between
sprints
 Realize benefits sooner by releasing earlier
 Increase the ROI of a project
 Increase productivity at least 2x in the first year;
much more thereafter
 Only deliver what’s truly needed
17
Scrum roles
ScrumMaster
Product Owner
The Team
18
Six guiding principles
Employ
iterative
feature
delivery
Deliver
customer
value
Champion
technical
excellence
Product delivery
Leadership-Collaboration
Build
adaptive
teams
Simplify
Encourage
exploration
Source: Agile Project Management by
Jim Highsmith.
19
Product delivery principles 1–2
Employ iterative
feature delivery
 Ensure that a potentially
shippable product is delivered
each sprint
 Keep the focus on delivering
features, not completing tasks
Deliver customer
value
 Support the product owner by
working on the highest-valued
features first
20
Product delivery principle 3
Champion
technical
excellence
21
 Products need to deliver value
today and tomorrow
 So we need to focus on
adaptability and quality
 Don’t become a champion of
just the schedule
Championing technical excellence

You want code you’re so proud of that you
hang it on your mom’s fridge

Keep the emphasis on
writing code well and the
speed will come
When something is done well, it’s
only a matter of time until it is
done quickly.
22
Leadership/collaboration principles
Build adaptive
teams
Encourage
exploration
Simplify
23
 Teams need the mindset and
skills to respond to change
 In an uncertain environment, we
need to explore rather than
conform to a plan
 Do what is barely sufficient
Additional responsibilities






24
Responsible for enforcing the values and
practices of the process and the team
Remove impediments from the team
Remove barriers between team and others
Educate outside groups about how the team
is working
Improve the lives of team members
Improve productivity in any way possible
Keep an eye out for problems
Most organizations release software every
6–12 months
 When we compress this cycle to 2-4
weeks, it puts stress in new places
 The ScrumMaster watches for these
stress points

25
Scrum roles
ScrumMaster
Product Owner
The Team
26
The product owner
Represents (or is) the user or customer for
the project
 One voice, even if not one person
 Typically a Product Manager, someone
from Marketing, or similar
 Main responsibility is knowing what to
build and in what sequence
 Conveys expectations by participating in
test planning

27
Product owner responsibilities


Establish the vision
Calls for releases
 Decides
when to call for an official release of a
potentially shippable product increment
 Can shift a release forward or backward to maximize
ROI based on new knowledge

Manage the return on investment (ROI)
 Establishes
baseline target ROI
 Measures project against this baseline
 Prioritizes product backlog to maximize ROI
28
Establishing a shared vision
Teams do best when they have a “clear,
elevating goal” and “unified commitment”†
 It’s the product owner’s job to focus the
team and find this clear, elevating goal

Sources: †Teamwork by Carl Larson and
Frank LaFasto and ‡Agile Project
Management by Jim Highsmith.
29
A unified vision
 Does everyone on your current project
share a unified vision?
 How can you establish a vision?
30
Scrum roles
ScrumMaster
Product Owner
The Team
31
The Scrum team
Typically 5-10 people
 Cross-functional

 QA,

Members should be full-time
 May

Programmers, UI Designers, etc.
be exceptions (e.g., Sys Admin, etc.)
Teams are self-organizing
 Ideally

32
no titles but rarely possible
Membership can change only between
sprints
Teams are cross-functional


33
This is not a cross-functional team:
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Sprint 5
Analysis
Coding
Testing
Analysis
Coding
Testing
Analysis
Coding
Testing
Sprint 4
Sprint 5
This is
Sprint 1
Sprint 2
Sprint 3
Analysis
Analysis
Analysis
Coding
Coding
Coding
Testing
Testing
Testing
Team commitment

The team picks the work they’ll do in a
sprint
 Which
items
 How many

The team commits to completing what
they select
 It’s
a team commitment, not a set of
individual commitments

34
Has authority to do whatever is needed to
meet this commitment
Developing the right software
Improves return on
investment
 Solves problems with
product owner
involvement
 Reduces project
politics

35