agile basic training - transformation · 2018-10-14 · scrum team launch workshop 3 scrum...

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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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


• 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



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


• 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



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

C:/Users/Roger/Documents/_AgileCrossing/Courses/CSM/videos/SPF.mov

http://www.exampler.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



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



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



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



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

http://www.agilecrossing.com/

mailto:[email protected]

http://www.agilecoachjournal.com/

http://www.linkedin.com/in/rogerwbrown

http://www.linkedin.com/in/rogerwbrown