Scrum: An Experiential Workshop

MJ
Half‐day Tutorial
6/3/2013 8:30 AM

"Scrum: An Experiential Workshop"

Presented by:
Mitch Lacey
Mitch Lacey & Associates, Inc.

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073
888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

Mitch Lacey
Mitch Lacey & Associates, Inc.
Over the past fifteen years, Mitch Lacey has managed numerous plan-driven and agile
projects. At Microsoft, Mitch honed his agile skills, successfully releasing core enterprise
services for Windows Live, and transitioned from program manager to Agile Coach, helping
others transition to agile practices. At Ascentium Corporation he became the Agile Practice
Manager, coaching customers on agile practices and adoption worldwide. As a Certified Scrum
Trainer and a registered Project Management Professional, Mitch shares his experience in
project and client management through Certified ScrumMaster courses, agile coaching
engagements, conference presentations, and his writings, including his new book The Scrum
Field Guide: Practical Advice for Your First Year.

SQE Agile West 2013 Reference Material

Understanding Scrum: An Experiential
Workshop
Reference Material
Mitch Lacey
SQE Agile West 2013
Las Vegas

PLEASE NOTE
These slides are for REFERENCE ONLY!
We will not be using/covering the slides.


Copyright 2007‐2013 Mitch Lacey (mitch@mitchlacey.com). No reproduction without written
authorization.

1


About Mitch Lacey
•
•
•
•
•
•
•

Author: The Scrum Field Guide
15+ years of project management experience
Agile 2012 Conference Chair, Dallas Texas
Former Agile Alliance Board Member
Former Scrum Alliance Board Member
Project Management Professional (PMP)
Certified Scrum Trainer (CST)


Mitch Lacey Contact Info
•
•
•
•

Twitter: mglacey
Linked In: http://www.linkedin.com/in/mitchlacey
Email: mitch@mitchlacey.com
Phone: +1 206 228 3544

vcard

LinkedIn


authorization.

2


The Scrum Framework


The Scrum Team
Product owner

Core team
(development team)

ScrumMaster

authorization.

3


The ScrumMaster
Protects
the Team

Team
Facing
Servant
Leader

Manages
Social Risk
Provides
Leadership


Roles in Scrum: ScrumMaster
• Goal: Build & Maintain a Healthy Team
• Responsibilities
–
–
–
–
–
–

Removes impediments / clears blocking issues
Protects the team from randomization
Is the team’s Scrum expert (exacts values and principles)
Defines and reports on Team productivity
Manages Daily Scrum
Coordinates Team time requests (e.g. Product Owner
meeting requests)


authorization.

4


The Product Owner
Customer
Facing
Owns the
Budget
Owns the
ROI

Manages
Feature
Risk

Provides
Direction


The Product Owner
Goal: Business & Customer Advocacy and
Product (or service) Guidance
Responsibilities
Optimizes the business value of the work
Represents and Manages Stakeholder interests
Owns the Product Backlog (requirements list)
Establishes, nurtures and communicates the
product vision
– Monitors the project against its ROI goals and
investment vision
– Makes decisions about when to create an
official release

–
–
–
–


authorization.

5


Self
Managing

Cross
Functional

Estimates
the Work

Manages
Technical
Risk
Collective
Ownership

Committed
Develops
High
Priority
Features


Roles in Scrum: The Core Team
• Goal: Execute on the Vision and Product
Backlog – Accomplishes the Sprint Goal
• Responsibilities
– Self Managing / Organizing
• Makes its own commitments
• Manages its own work
• Manages itself to its commitments

– Develops the highest-priority features
on the Product Backlog
– Cross functional


authorization.

6


Roles in Scrum: The Team – What they Do
• Plan the work / own and update the estimates
• Place value on following a plan but value
responding to change more (values)
• Rely on the Product Owner for product
clarification questions (feature risk)
• Authority and empowerment (does what’s
needed to achieve the goal)
• Rely on the ScrumMaster to help clear
blocking issues (social risk)
• Commit to the Sprint


Roles in Scrum: The Team – How Big?
• Six is ideal
– As little as three and as big as eight

• Co-located
• Scrum scales by adding teams, not growing
team size


authorization.

7


Team Consultant Model


Roles in Scrum: The Team - Agreement and
Support
•
•
•
•

Teams are cross functional
Team members need to support each other
ScrumMaster drives the team to consensus
Fist of Five Technique:
–
–
–
–
–

5 = 100% support
4 = Good idea, wish it was mine 
3 = I can live with and support this
2 = I would like to think about this more
1 = I am against this and will fight moving in this
direction


authorization.

8


Ideal Team Size

491 medium sized projects with 35k‐95k SLOC
Source: Putnam, Lawrence H. and Myers, Ware. Familiar Metrics Management: Small is Beautiful Once Again. IT Metrics Strategies IV:8:12‐16, Cutter Information Corp., August 1998


“A distinct difference in the person-months needed to do a
comparable amount of work begins to show up when group
size exceeds eight people.”

491 medium sized projects with 35k‐95k SLOC
Source: Putnam, Lawrence H. and Myers, Ware. Familiar Metrics Management: Small is Beautiful Once Again. IT Metrics Strategies IV:8:12‐16, Cutter Information Corp., August 1998


authorization.

9


The Product
Backlog


Levels of Planning: Being “Done” Example
Examples:
1. Architectural
Diagrams Updated
2. Automated User
Tests Passing

Examples:
1. Stress Testing
2. User Training
Completed

Examples:
1. Failover Testing
2. Release Readiness
Review

Examples:
1. SQL Optimization
and Tuning
2. Data Security
Roles Updated

Prod
Examples:
1. Installation
Package Updated
2. > 70% Code
Coverage

Sprint
Story
Task

authorization.

10



Definition of Done Exercise
Build your own definition of done!
1 – in the book
2 – on this webpage:
http://www.mitchlacey.com/introto-agile/scrum/definition-of-done


authorization.

11


Product Backlog: What is it?
• Ordered, prioritized list of features and work
• High level estimates (story points)
– Preferred: Story points: 1,2,3,5,8,13
– Alternatives
• Exponential: 10, 20, 40, 80
• T-shirt sizing: XS, S, M ,L, XL

• Items added at any time
• Owned and prioritized by the Product Owner
• Should reflect the vision (why the project exists and its
desire end state)


Product Backlog Prioritization
Highest Priority
Work on it now – lots of detail

1
2

Up Next – more detail
Work that is 3‐5 sprints out – Some detail

Too far out – little detail

3

4


authorization.

12


User Stories
• As a <user> I can/want <action> so that <result>
• As an administrator, I can look up this month’s patient
report and am able to see who is over the user defined
threshold
• Have business value
• Are easily identifiable by the Product Owner, customers
and the team
• Rely on the 3 C’s
– Card
– Conversation
– Confirmation


INVEST in Your Product Backlog
• Independent

– Dependencies lead to problems estimating and prioritizing
– Can ideally select one item to work on without pulling in 18 others

• Negotiable

– Product backlog items are not contracts
– Leave or imply some flexibility

• Valuable

– To users or customers, usually not to developers
– Try rewriting developer-oriented backlog items to reflect value to users or
customers

• Estimable

– Because plans are based on user stories, we need to be able to estimate
them

• Small

– Complex backlog items are intrinsically large
– Compound backlog items are multiple items in one

• Testable

– Make backlog items testable by having acceptance tests

1 Bill Wake 2003


authorization.

13


Make it DEEP
• Detailed Appropriately.
– Stories coming up should be understood
– Stories that will not be developed for awhile should be described
with less detail

• Estimated.
– More precise at the top
– Less at the bottom

• Emergent.
– Stories grow and change. The more you learn, the more you
tweak

• Prioritized.
– Valuable stories at the top, less so down the list


Product Backlog Grooming
• The team should spend 5%-15% of Sprint time (1-6h)
in reviewing the Product Backlog and estimating it for
each Sprint (s)
• Similar to a specification only never out of date
• Continuously prioritized and updated
• Anyone can add to the product backlog


authorization.

14


Planning


Levels of Planning


authorization.

15


Levels of Planning: Being “Done”
• What is Done?
– How do you know when your project is done?
– How do your customers and stakeholders know?
– How do you communicate it?


Levels of Planning: Sprint Planning Meeting 1
Vision
Product(s)

Releases

Sprint

Day

• Scale duration depending on
Sprint Duration
– 1mo Sprint = 4h
– 2w Sprint = 2h

• Defines what the team will build
• Product Owner states what the
business wants (high value, high
risk)
• Agrees on the goal of the sprint
• When Team has enough
information, or time has ended,
Planning Meeting 2 begins


authorization.

16


Levels of Planning: Sprint Planning Meeting 2
Vision

• Scale duration depending on
Sprint Duration
– 1mo Sprint = 4h
– 2w Sprint = 2h

Product(s)

Releases

Sprint

Day

• Defines how the team will build
the stories
• Tasks are small (2-14h)
• Team owns Sprint Backlog
(builds, estimates, updates)
• Team signs up for work,
collectively commits to the work
• Attended by the Team (Product
Owner optional)

Sample Sprint Backlog


authorization.

17


The Sprint Backlog
• Is the output of the planning meeting
• Is used for the team to manage themselves and their
work during the sprint
• Creates transparency between all Scrum team members


Download my Sprint Excel Sheet
http://www.mitchlacey.com/resources/sprint‐excel‐templates


authorization.

18


Levels of Planning: Daily Scrum Meeting
• Occurs Daily
• Team members answer three questions:
•
•
•
•

What did you work on since the last meeting?
What will you work on today?
What impediments / blocking issues do you have?
(optional) What is your confidence that we will achieve the sprint goal?

• Timeboxed to 15m
• Same time/place daily
• No deep dive problem solving
(deal with that after)


The Sprint: Reporting Progress - Burndown


authorization.

19


The Sprint: Reporting Progress - Burndown


Release Burndowns
• Use the same sprint burndown but instead of days, use it
for sprints
• Should be updated after every sprint
• Useful to allow the Product Owner to see the overall
release plan progress


authorization.

20


Sprint Review Meeting
• Occurs on the last day of the Sprint
• Allows stakeholders to review the work done and provide
guidance on what to do next
• One hour per week of sprint (e.g. two week sprint is two
hour meeting)
• The team drives the meeting
• Everyone attends
• Can impact the upcoming Sprint planning sessions
– Reprioritize the backlog
– Change high level estimates of work
– Team composition may change


What do we Review in the Review Meeting?
•
•
•
•
•
•
•
•

Review the Sprint Goal
Review the commitments made by the team
Review work accomplished
Review the work that was not accomplished
Review the decision made
Demo the work
Summarize
Asks


authorization.

21


Retrospective
• Occurs on the last day of the Sprint
• One hour per week of sprint (e.g. two week sprint is two
hour meeting)
• Allows the team to inspect itself to learn about & change
behavior as needed
• Facilitated by ScrumMaster
• ScrumMaster and the Team prioritize the improvements
• The sprint ends when the timebox expires,
typically after the retrospective


Getting Started with Scrum
•
•
•
•
•
•
•
•
•
•
•

Get a senior Sponsor in the company
Get a champion to drive the effort
Agree on who will play the roles
Set a date to “start scrumming” and prep the team to that
date
Build a prioritized Product Backlog and estimate it
Build the team and clear blocking issues (like not being colocated)
Build a Sprint Backlog and start working
Use Burndowns
Conduct a demo and review
Inspect and Adapt
Repeat!


authorization.

22


Cadence
•
•
•
•
•
•

Set a cadence and keep it
Put all meetings in calendars on day 1
Keep your daily Scrum on track
Use planning
Work to potentially shippable code
Always demo at the end

• CELEBRATE SUCCESS AT EVERY SPRINT!


Getting People on Board with Scrum
Be patient
Use the local network – get testimonials
Provide articles and books
Show incremental benefits
Get external speakers to talk to
management and teams
• Ensure risk will not be penalized
•
•
•
•
•


authorization.

23


Be Warned
•
•
•
•
•

Most projects deliver every 6-18 months.
Scrum reduces this through inspect and adapt
Things will be stressful
Fight the urge to be lazy
Stay disciplined


What Causes Scrum to Fail?
• Making changes out of the gate
• Thinking that “this can’t work in our company”
• Not having an honest retrospective and doing
something about it
• Bad ScrumMasters
• Falling into old habits
• Lacking authority and being empowered
• Business culture does not support Scrum


authorization.

24


Scrum Resources
• My contact
– http://www.mitchlacey.com
– http://twitter.com/mglacey

• My book, The Scrum Field Guide
• Jeff Sutherland Scrum Papers
– The Scrum Papers (jeffsutherland.com/scrum/ScrumPapers.pdf)

• Mike Cohn & Mountain Goat Software
– http://www.mountaingoatsoftware.com/scrum

• Scrum Alliance
– http://www.scrumalliance.org


Offshoring – Making it Work
• About 3 time zones away seems to work
• Phone/shared desktop pair-programming is essential

– Set management expectations that pairs will be based on work, not
proximity

• Use technology!
–
–
–
–

Push to talk cell phones so every team member can talk anywhere any time
Use teleconferencing for all “formal” meetings like standups
Use VNC
Get webcams

• Face time matters, travel often.
• Travel any time there are communication difficulties
• Travel any time you feel trust is breaking down between the
locations
• Do absolutely anything you can do to build a one-team culture
• Do absolutely nothing to build the perception fragmented teams


authorization.

25


Offshoring – Making it Work Part 2
• Have a project / team coordinator
– The coordinator has the responsibility of relaying the backlog to
the offshore team and tracking progress.

• Have in-person kick-off meetings with the entire
worldwide team
• Bring offshore people to the central office on a rotational
basis to build team cohesion
• Have offshore teams take on as much independent work
as possible, a whole feature set possibly


Offshoring – Impediments to Manage
Time zone differences
Culture and values
Inexperienced teams
Face-to-face communication
Language barriers
Trust
Building a common development environment and
codebase
• Stronger Command & Control tradition in Asia
• Offshore turn-over
• Recruiting the right offshore workers
•
•
•
•
•
•
•


authorization.

26


When to Offshore
• Don’t Offshore:
– First releases of complex and high-technology-risk projects
– If your onshore development process is not in place (”CMMI
level 3”)
• Process = the daily work in the teams
• Process ≠ the corporate process guidelines

• Don’t Agile Offshore:
– If you don’t have any onshore Agile experiences


authorization.

27

Scrum: An Experiential Workshop

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (6)

Similaire à Scrum: An Experiential Workshop

Similaire à Scrum: An Experiential Workshop (20)

Plus de TechWell

Plus de TechWell (20)

Dernier

Dernier (20)

Scrum: An Experiential Workshop