Scrum Team Launch Workshop
www.agilecrossing.com
1
Scrum Team Launch
Coach – Roger Brown CST, CSC
Training Transition
Transformation
All slides © 2014 Roger W. Brown www.AgileCrossing.com
Topics
Agile Foundations
Scrum Mechanics
Agile Planning
Scrum Roles
Agile Success Factors
Extreme Programming
Team Charter
2
Agile Foundations
History Values
Principles Brands
3
Empirical Process
• Agile success relies on “Empirical
Process”
• Improvement comes from a continuous
learning cycle we call “Inspect and
Adapt”.
4
Continuous Improvement
Plan
Do Check
Act
Deming Cycle
Empirical Process Transparency,
Inspect and
Adapt
5
notes
6
Scrum Team Launch Workshop
www.agilecrossing.com
2
Agile Basics
• Agile software development implements
Lean principles and dynamics.
• Scrum is one form of Agile, designed
initially for software development but
applicable to other kinds of work.
7
Manifesto for Agile Software Development 2001
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
Working software over comprehensive 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.
www.agilemanifesto.org
Agile Manifesto
8
What is Agile Software Development?
Team Based Incremental Iterative Frequent Delivery Fully Visible Production Quality Value Driven
9
Product Development Value Stream
Product Discovery
Product Definition
Product Development
Product Delivery
Product Operation
Support
Scrum/XP
Lean Startup
Lean UX
DevOps Kanban
Scrum is one of several complementary frameworks used to increase organizational agility
Business success comes from maximizing value/time.
10
notes
11
Scrum Mechanics
Scrum Framework and
Execution
12
Scrum Team Launch Workshop
www.agilecrossing.com
3
Scrum Framework
• Scrum has 4 meetings and 3 artifacts
• Scrum has 3 roles that share the
responsibility of creating value in small
increments
• The roles complement each other to
create a balanced team
13
Scrum Framework
Potentially Shippable Product
Increment
Sprint Backlog
Product Backlog
Release
Planning
Sprint
Planning
Sprint
Review Sprint
Retrospective
Daily
Scrum
1-4
weeks
Story Time
14
The Scrum Team
Desired Features
Product Owner
Development Team
Product
ScrumMaster
15
Product Owner
Maximizes the value of the work done
o Sets Vision o Manages Backlog o Elaborates Features o Decides Release Dates o Reviews Work
16
Development Team Member
o 7 ± 2 o Cross functional o Full-time o Self-organizing o Empowered
Develops the product with high quality
17
ScrumMaster
o Facilitator o Protector o Coach o Mentor o Gopher o Change Agent
Helps the team improve flow
and throughput The ScrumMaster is the
Heart of Collaboration
18
Scrum Team Launch Workshop
www.agilecrossing.com
4
notes
19
Scrum Execution
• Scrum organizes work into 1-4 week time
boxes called Sprints
• Each Sprint has 4 primary meetings
• The bulk of the time is spent creating
value in the form of a product
20
Sprint Planning Meeting
Product Backlog
Sprint Backlog
Pri
ori
ty
Goal 1: What? • Which PBIs can will comprise our forecast? • What is our Sprint Goal? Ex. Build the shopping cart
Goal 2: How? • Design an implementation plan, often by decomposing into tasks • Double check our forecast
Attended by • Product Owner, Development Team, ScrumMaster • Other interested stakeholders
Time-box is 1 hour per week
of Sprint
21
Sprint Time Box
S1
1-4 weeks
Steady cadence, fixed length Abnormal Termination If the Sprint Goal cannot or should not be reached for
unexpected reasons, stop and plan a new Sprint
Focus No one can change the Sprint plan except the Scrum Team to add or
remove a PBI
S2 S3 S4
22
Daily Scrum
15 Min
The Three Questions What did you do yesterday? What do you plan to do today? Is anything blocking you?
23
Task Board
Sprint Burndown
Information Radiators
Item
Scrum Team Launch Workshop
www.agilecrossing.com
5
Sprint Review
• Purpose • Demonstrate the completed stories
• Get feedback from the Stakeholders
• Attendees • Product Owner, Development Team, ScrumMaster
• Any other stakeholders
• Last day of Sprint • ~2 hours for a 2 week sprint
Preparation • Who will show what? • Deploy to a preview server • Any documentation needed? • Update and show release burnup chart • What is the Team status?
2 Hours
25
Show actual running
code!
Sprint Retrospective
• Scrum Team meets privately
• Goal is process improvement
• Format
• Gather Data
Reflect on what worked well, what didn’t
• Generate Insights
Discuss results and new ideas
• Decide Action Items
Consider adopting new practices
Stop doing things that are not working
1.5 Hours
Start Stop Continue
Keep it interesting • Appreciations • Food • Variety
26
notes
27
Agile Planning
5 Levels User Stories Prioritization
Estimation Release Planning
28
Agile Planning
• Agile planning is continuous
• Agile planning happens at 5 levels, each
with a different time horizon
• The Product Backlog is the primary
source of work to be completed and
value to be delivered
29
Value Driven
Estimates
Features
Schedule Cost
Plan
Driven
The Plan creates
cost/schedule estimates
Waterfall
The Vision creates
feature estimates
Schedule Cost
Features
Value / Vision
Driven
Agile
Source: Sliger and Broderick “The Software Manager’s Bridge to Agility”
Constraints
30
Scrum Team Launch Workshop
www.agilecrossing.com
6
Product Context - 5 Levels of Planning
Strategy
Portfolio
Vision
Roadmap
Release
Sprint
Day
P1 P2 P3 P4 P5
Product Backlog
Release 1 Release 2 Release 3
s1 s2 s3 s4 … sN
Scru
m P
lan
nin
g
31
Product Vision
• The Big Picture of how the product creates value
• Aligns team and business to the same goal
What is the name? Who is the target customer? What are the key benefits? What are the differentiating features?
32
Product Backlog
• Dynamic set of items to be done
• Prioritized
• Constantly in flux as the situation changes
Story
Story
Story
Spike
Story
Refactor
Story
Defect
Process Change
items are removed
priorities change
items are added
33
notes
34
User Stories
• User Stories are simple descriptions of
desired functionality
• User Stories have two attributes that are
helpful for planning: size and priority
• Stories are elaborated just-in-time for
implementation
35
User Story Template
As a <user role>, I can <do something> so that <I get some value>.
36
Card – Conversation – Confirmation
Scrum Team Launch Workshop
www.agilecrossing.com
7
Sample User Stories
As a student, I can get a degree on-line so that I do not have to move near a college campus
As an online student, I can print a copy of my transcript to show an employer
As a degree candidate, I can see which courses I still need to satisfy my major so I can plan my next term
As a professor, I can get student test summary reports so that I can assess my teaching effectiveness
37
Backlog Hierarchy
Epic User Story Task Task Task Task
User Story Task Task Task Task
User Story Task Task Task Task
Product Backlog
Sprint Backlog
Business Goal
Planning Implementation
38
Where are the details?
(front)
Story 6: Course Catalog Demo As a prospective student, I can browse the course catalog to see if the classes I am interested in are available.
(back)
Story 1 Acceptance Criteria [ ] Has full catalog browse and search controls [ ] Show available dates in summary list [ ] Item click leads to class detail page [ ] Show class star ratings only, no comments [ ] Replace “Register for Course” button with “Join Now!” that links to sign-up page
Automated Tests
Speclet • formula • UI design • screen flow • business rules
39
notes
40
Prioritization
• Priorities help the Scrum Team decide
what to do next
• Priorities help with long term planning
• Prioritization can be done in many ways,
based on many criteria
41
Prioritization - MoSCoW
o Business value
o New knowledge
o Risk/Complexity
o Desirability
42
Scrum Team Launch Workshop
www.agilecrossing.com
8
Story Map
Epic
I can browse by
department
I can search by subject
I can register
I can read content
I can browse by
title
I can unregister
I can browse by professor
I can join a waitlist
I can take tests
I can search by date offered
I can search by major
I can take classes on-line
Browse Search Register Attend Reports
I can do homework
I can print my
transcript
I can see my grade for a class
I can browse by popularity
Theme
Must
Should
Could
Pri
ori
ty
Smaller stories give more options for prioritizing for max value
43
I can print my
schedule
I can print my report
card
I can chat with
classmates
notes
44
Agile Estimating
• Agile estimation is done at both the high
level and the low level
• Estimates are used for planning and for
tracking progress
• Estimates are done quickly, by the
Delivery Team
• Estimates are not commitments
45
Why Estimate?
Story Points • High Level
• Compare one story to another
• Forecast Releases and Sprints
Task Hours • Low Level
• 1-8 hours for a Story element
• Refine Sprint plan
• Track Sprint progress
1 2 3 5 8 13
46
Estimation Basics
Quick
Story 1: Home Page As a prospective student, I can view the college services so that I can decide if I want to apply.
2 Story 17: Major Progress
As a degree candidate, I can see which courses I still need to satisfy my major so I can plan my next term
5
Quick
Relative
Guess
Done by Team
More than 2x effort required
47
Affinity Estimating
Groups of 2-3 people choose some stories
Put in column with similar sized stories
Team members
can move stories
Visual grouping for quick comparisons
1 2 3 5 8 13 20
48
Start with numbers
or arrange by size
first
Scrum Team Launch Workshop
www.agilecrossing.com
9
Velocity
5
12
27
32
36 38
40 37 38
40
0
5
10
15
20
25
30
35
40
45
1 2 3 4 5 6 7 8 9 10
Sto
ry P
oin
ts C
om
ple
ted
Sprint
Team Velocity
How many story points can the Team complete in a Sprint?
Varies by circumstance, increases with
experience
Aggregates Team dynamics and organizational
factors
Is measured, not “managed”
49
Velocity is sum of estimates of
stories completed
notes
50
Story Splitting
• Smaller stories provide more agility • There are known patterns for splitting
stories
51
Smaller is Better
20
5 3 5
Smaller Stories are easier to
work with
Increased Throughput
• helps flow
• quicker feedback
• unbundle priorities
Decreased Complexity
• easier to estimate
• fewer test cases
• easier to focus
• cleaner designs
52
Story Splitting Patterns
• Workflow Steps • Business Rule Variations • Major Effort • Simple/Complex • Variations in Data • Data Entry Methods • Defer Performance • Operations (CRUD) • Spikes
53
http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/
notes
54
Scrum Team Launch Workshop
www.agilecrossing.com
10
Long Term Planning
• Scrum-built products may have
Roadmaps and Release Plans
• Team velocity is a measure used in long
term planning
55
Product Roadmap
First sub-setting of Product Backlog for a long product development time frame
• How many releases?
• When?
• What is included in each?
Tim
e
Continuing Education for Professionals
Undergraduate Degrees
Graduate Degrees
The roadmap will be reviewed and updated as things
change
Product Backlog
Releases
56
The Elements of Agile Planning
Product Backlog What capabilities are needed for financial success?
Priorities Which items are most valuable?
s1 s2 s3 s4 … sN
Velocity How much can the team complete in a Sprint?
Estimates How much effort is required for each item?
Release Plan How long will it take or how many can we do by a given date?
57
Release Planning Meeting
Align Vision
Identify User Roles
Identify features/Epics
Brainstorm User Stories
List Priority Criteria
Prioritize Stories
Estimate Stories
Check Priorities
Forecast Team Velocity
Forecast Release 1-2 days
58
Time-Based Release Strategies
Release Backlog
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Q1 Release
Q2 Release
Q3 Release
How much will we complete?
How much is done so far?
Progress is reported in units of actual product ready for
delivery
59
Feature-Based Release Strategy
Release Backlog
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Release 1: Continuing Education
Release 2: Undergraduate Degrees
Release 3: Graduate Degrees
When will it be done?
How much is done so far?
Forecasting improves as
velocity becomes known
60
Scrum Team Launch Workshop
www.agilecrossing.com
11
Release Plan
s1
s2
s3
…
sN
Product Backlog
Release as often as possible
Newsworthy Release Event
Tim
e
Release Backlog
Must
Should
Could
Won’t in this
Release
Sprints
Release Plan 1. How long will it
take or 2. how many can we
do by a given date?
Release Forecast:
1. How Long? Number of Sprints = Total Backlog/Average Velocity 2. How Much? Percent of Backlog = Total Backlog/(Average Velocity * Number of Sprints) 61
notes
62
Scrum Roles
Product Owner Development Team
ScrumMaster
63
Product Owner
• The Product Owner navigates the product to maximum business value
64
Define the Product
Build the Product
Plan the Product
It’s a Big Job
Corporate Strategy Portfolio Alignment Customer Needs Corporate Needs Competition Stakeholders
Product Vision Revenue Target
Product Backlog Priorities
Funding UX
Dev Team Collaboration Scrum Framework
Product Details Product Review
Release Plan
What else?
65
Product Owner Attributes
• Domain knowledge
• Empowered to
• Spend budget
• Define vision
• Make release decisions
• Understand what customers want
• Available to the team
• Actively manage stakeholders
• Familiarity with product development
• Team protector
66
Scrum Team Launch Workshop
www.agilecrossing.com
12
Managing Value
Return on Investment =
Benefits – Costs
Costs
Cost is easy with a fixed team size and
Sprint length
Benefit is not so easy to
determine Elements of Business Value • Increased sales • Accelerated sales • Decreased expenses • Customer satisfaction/retention • External compliance • Market differentiation
67
Agile Goals for Business
Faster Time to Market
Quicker ROI
Lower Total Cost
Respond to Change
Reduced Risk
Stakeholder Relations
68 Predictability
Manage the Profit Strategy
Time
Pro
fit
competition
market penetration
customer feedback
innovation
compliance
internal stakeholders
market changes
The Product Owner balances competing demands to maximize value/time
69
notes
70
Development Team
• The Team is self-organizing • Teams go through a maturation process
71
Key Success Factors
• Self-organizing
• Cross-functional
• Full-time dedicated
• Work in a shared space
• Empowered to make decisions
• Team Working Agreement
• Definition of Done
• Automated Testing
• Right Skills and Tools
72
Scrum Team Launch Workshop
www.agilecrossing.com
13
Tuckman's Team Development Model
Storming
Forming
Norming
Performing
• Teams go through four stages
• Teams can regress when membership changes
Time
Effe
ctiv
en
ess
73
Motivation
• Financial rewards often give poor results • Intrinsic vs. extrinsic motivation • People are motivated by
• autonomy • mastery • purpose
See Dan Pink, TED.com and Drive
74
Create
Validate Improve
Agile Goals for Developers
Cadence
A Sense of Done
0
20
40
60
M T W T F M T W T F
Wo
rk R
emai
nin
g (h
rs)
Visible Progress
Quality Work
Feedback
Teaming
75
notes
76
ScrumMaster
• The ScrumMaster is responsible for the health and growth of the Scrum Team
• The ScrumMaster is a facilitator, mentor, negotiator, protector, coach and servant leader
77
Facilitator
• Keep meetings productive and short
• Mediate disputes
• Grease the wheels
78
Scrum Team Launch Workshop
www.agilecrossing.com
14
Coach
• Lead people to their own solutions
• Aware of the bigger picture
• Able to mentor individuals
• Knows when • to be prescriptive • to nudge • to keep distance
It’s better to be paying attention than to have all
the answers - Ward Cunningham
79
Servant Leader
• Lead vs. Manage
• Lead to make others better
• Increase teamwork and personal involvement
• Lead by example
80
Day in the Life of a ScrumMaster
Manage impediments Facilitate meetings Mediate and negotiate Teach Scrum Manage the process Assist the Product Owner
Observe and coach Team Encourage excellence Protect Team from distractions Build relationships Promote Organizational Agility Administer
ScrumMaster 7 Team Members Productivity
81
notes
82
Agile Success Factors
Focus and Flow Scrum Enhancers
Managing Technical Debt
83
Focus and Flow
• Scrum works best when the Team
achieves a smooth flow of work
• Scrum dynamics are based on the
mathematics of queuing theory that we
use to manage the Internet
84
Scrum Team Launch Workshop
www.agilecrossing.com
15
Pull Systems
Push systems overwhelm capacity, creating turbulence, rework, waste and delay
Pull systems have a steady flow that provides predictability
Push
♫
85
Small Batches
Small batches move through
a system quicker
Single-piece-flow reduces the wait time
and moves risk to the
margin
Minimize work in progress
86
notes
87
Scrum Enhancers
• A 1-sprint look-ahead on stories will help
the flow
• Defining Ready and Done will
dramatically reduce time waste
88
Backlog Grooming
Product Owner spends 30% of their time working on the Product Backlog
• Identify new stories
• Splitting epics and stories
• Updating Release Plan with current velocity data
• Adjusting priorities
• Preparing next stories
• Designing user experience
89
Story Time
Development Team spends 5-10% of Sprint with the Product Owner preparing for the next Sprint
• Reviewing candidate stories
• Getting details and acceptance criteria
• Some technical design
• Estimate new stories
• Considering new ideas
Often a regular meeting 1 hour/week
or 2-3 hours mid-sprint
90
Scrum Team Launch Workshop
www.agilecrossing.com
16
Definition of Ready
Negotiate with your Team - What they need for each story - When they need it
91
Sample Right size Screen sketches Acceptance criteria Dependent stories? Speclets
Definition of Done
Unit tested to 90% code coverage Code reviewed Acceptance tests pass UI Tested User Help updated Deployment scripts updated
• When estimating size, consider all the work needed to complete the story
• The Definition of Done may evolve over time
Sample
May also have one
for sprints and
releases
92
Sprint Flow
Sprint N Sprint N+1
Candidate Stories for N+1 (1.5 x velocity)
Definition of Ready
Screen Designs for N+1 (LoFi)
Continuous Product Backlog Grooming
Story Time Sprint Planning
93
Definition of Done
notes
94
Managing Technical Debt
• Technical Debt is poorly designed code
written to save time
• Technical Debt compounds over time
• Regular payments on Technical Debt will
enhance agility
95
Sources of Technical Debt
• Known defects left for later
• Stories not finished
• Overly complex code
• Unreadable code
• “Clever” solutions
• Poor designs
• Hard-to-test code
• Disabled code
96
Scrum Team Launch Workshop
www.agilecrossing.com
17
Cost of Technical Debt
Cost to fix a defect as time passes
Impact on Team Velocity over time
Debt avoidance
Debt accumulation
Delayed debt payments
97
Managing Technical Debt
• Test-Driven Development
• Pair Programming
• Legacy debt payment allowances
• Boy Scout Rule
• Agile design training
• Code quality measurement tools
• Tech Debt Backlog
• Refactor stories
98
notes
99
Extreme Programming
Quality Testing
Agile Engineering
100
Quality and Testing
• Automated acceptance testing is used to ensure the right product is built
• Unit testing ensures the product is built right
101
Elements of High Quality
• Less re-work
• Fewer trouble calls
• Higher customer satisfaction
• Easier to enhance the product
• No “technical debt”
Build quality in! It’s cheaper in the long run.
102
Scrum Team Launch Workshop
www.agilecrossing.com
18
The Testing Pyramid
Manual Tests through UI
Automation Suites
Unit Tests
Automated UI Tests
Automated Acceptance
Tests
Unit Tests
Traditional (find bugs)
Agile (prevent bugs)
Exploratory
testing
103
Single Piece Flow
Do This
Don’t Do This
104
notes
105
Testing Strategy
• An initial strategy for all testing activities is advantageous
106
The Agile Testing Quadrants
Original idea by Brian Marick, www.exampler.com
Copyright 2007 Janet Gregory, DragonFire
107
Sample Testing Strategy
Tests Hourly Daily Weekly Sprint Release
Unit X X X X X
Code Quality X X X X X
Exploratory X X X X
Current Story ATs X X X X
All Story ATs (Regression)
X X X X
Usability X X X
Performance X X
Load X X
Customer Acceptance
X X
108
Scrum Team Launch Workshop
www.agilecrossing.com
19
notes
109
Agile Engineering Practices
Review of complimentary practices
110
Complementary Practices
• Co-location
• Pair Programming
• Refactoring
• Test-Driven Development
• Continuous Integration
• Exploratory Spikes
• Legacy System
Strategies
• Evolutionary Design
• Agile Architecture
111
Co-location
• Maximum communication
• Quicker resolutions
• Team Trust
• Learning
• Reduced overhead
• Better focus
Productivity can double!
112
Pair Programming
• Team members work side-by-side
• Better Design
• Higher Quality
• Shared Knowledge
• Continuous Learning
113
Refactoring
• Improve design without changing function
• Well known patterns
• Always leave the code better than we found it
114
Scrum Team Launch Workshop
www.agilecrossing.com
20
TDD Rhythm
Add a test
Run test and fail
Write code to pass test
Run tests, all pass
Refactor
Remove duplication and improve
design
Compile or logical failure
Just enough to pass!
Start a task
115
TDD Screen Shot
116
Benefits of TDD
• Higher quality
• Testing is not short-changed
• Safer to refactor
• Living Specification
• Cadence and Momentum
• Confidence
117
Number of Tests
Con
fid
enc
e
Continuous Integration
118
Exploratory Spikes
• Time-boxed experiment with stated goals • Support feature or task estimates
• Explore unfamiliar technologies or components
• Prototype and compare major design alternatives
• Story or task-sized
119
Acceptance Test Examples
• Based on Use Case • The “sunny day scenario” is one test
• Each exception scenario can be another
• Activity description • When a user clicks on the Options screen, a modal panel of option categories opens defaulting
to the General tab
• Algorithm or formula check • Give a purchase price of $1.25 and a deposit of $5.00, the vending machine will return change
consisting of 3 dollar bills and 3 quarters
• Spread sheet
• Entitlement rule • A Supervisor can view work orders initiated by someone else but not change them
input input output output output output output
price deposit dollars? quarter? dimes? nickels? pennies?
1.25 5.00 3 3 0 0 0
1.15 2.00 0 3 1 0 4
0.85 1.00 0 0 1 1 0
120
Scrum Team Launch Workshop
www.agilecrossing.com
21
FitNesse Screen Shot
121
Legacy System Strategies
• Legacy System == system with no tests
• Known patterns
• Write “characterization tests” to reveal current behavior
• Work in small steps
• Debug with unit tests
• Look for seams
• Break dependencies
122
Evolutionary Design
• Whiteboard vs. design document
• Constant refactoring
• YAGNI – no gold plating, minimal complexity
• Change is the norm
• Write readable code
• Write testable code
• Design to interfaces
• Use design patterns wisely
123
Agile Architecture
• Architecture == anything that is hard to change
• Design for 90%, not the last 10%
• Wire frame
• Encapsulate dependencies
• Loose coupling, high cohesion
124
notes
125
Team Charter
Identity Cohesion Purpose
126
Scrum Team Launch Workshop
www.agilecrossing.com
22
Goals
Business
Team
Personal
Skills
Relationships
Stakeholders
Others Individuals
Other Teams Who ------- What
Us
Values
Examples
• everyone has a voice
• we succeed as a team
Conventions
Examples
• update task estimates each day
• keep burndown visible
Agreements
Examples
• sprint length
• daily scrum time
• core hours
Scrum Team Launch Workshop
www.agilecrossing.com
23
Development Practices
• Tools
• Definition of Done
• Definition of Ready
• Handling defects
• Testing Strategy
Team Name
• Make it about the team, not the work • Have a Mascot?
notes
135
Instructor
Roger Brown
• Agile Coach
• Scrum Alliance
• Contact Web: www.agilecrossing.com
Email: [email protected]
Twitter: @rwbrown
Blog: www.agileCoachJournal.com
LinkedIn: http://www.linkedin.com/in/rogerwbrown
V 1.1
136
Scrum Team Launch
Coach – Roger Brown CST, CSC
Training Transition
Transformation
All slides © 2014 Roger W. Brown www.AgileCrossing.com