intro to scrum slides 2.0

8/8/2019 Intro to Scrum Slides 2.0

1/133

Introduction to Scrum

Pete DeemerCPO, Yahoo! India R&D


2/133


3/133

Defined Processes

Defined Process

Input

Input

Input

Output

Output

Output

Assuming every step is understood, a

given well-defined set of inputs produces

the same set of outputs every time.

Predictability is key.


4/133

The Waterfall

Requirements

Gathering

Design

Development

Testing

Launch &

Maintain

Documentation,

Signoffs, Handoff

Documentation,

Signoffs, Handoff

Documentation,Signoffs, Handoff

Documentation,

Signoffs, Handoff

Job Function A Job Function B Job Function C Job Function D Job Function E

Advantage: Highly Logical

Disadvantage: People are involved


5/133

Empirical Processes It is typical to adopt the defined (theoretical) modeling approach when the

underlying mechanisms by which a process operates are reasonably well

understood. When the process is too complicated for the defined approach,the empirical approach is the appropriate choice.

Process Dynamics, Modeling, and Control,

Ogunnaike and Ray, Oxford University Press, 1992

Translation into English: Inspect and Adapt

Process

Inspect & Adapt

Input Output


6/133

Iterative Incremental Development

Iterative Development

Project is structured as multiple short cycles in

sequence, versus one long cycle

Incremental Development Each iteration produces a usable increment of

finished product, with actual customer value


7/133

The Emergence of Scrum

Scrum formalized in 1996 by Ken Schwaber

The Origins of Scrum, OOPSLA 1996

Google

Sun

Siemens

Nokia

Philips

BBC

IBM

Yahoo!

SAP

HP

Motorola

TransUnion

BT / British Telecom

CapitalOne

Now in use at a growing list of big companies:


8/133

What Is Scrum Being Used For?

US FDA-approved software for X-Rays, MRIs

High availability systems (99.9999% uptime)

Financial payment applications

Large database applications Embedded systems

CMMi organizations

Multi-location development Non-software projects


9/133

Scrum at Yahoo!

4 pilot teams migrated to Scrum in early 2005

Since then, >200 Yahoo! projects (>2000 people) aroundthe globe have migrated to Scrum

Consumer-facing projects

Major infrastructure projects

Distributed Projects

New Products

Maintenance Products

Policy is 100% voluntary adoption

Teams hear about or observe the experiences of other teams usingScrum and decide to learn more


10/133

Scrum Disadvantages

Its hard!

Makes all dysfunction visible Scrum doesnt fix anything: the team has to do it Feels like things are worse at the beginning

Bad products will be delivered sooner, and doomedprojects will fail faster

Some teams and organizations are not right or ready for it Team willingness, capabilities

Management buy-in

Risk of turnover during adoption

Some people will refuse to stay on a Scrum team Some people will refuse to stay if Scrum is abandoned

Partial adoption may be worse than none at all

If adoption fails, time will have been wasted, and somepeople may leave


11/133

Scrum Basics



12/133

The Basics of Scrum

4-Week

Sprint

PotentiallyShippable

Product

Product OwnerReview

ScrumMaster

The Team

7

8

9

10

11

12

1

2

3

45

6

13

No Changes(in Duration or Deliverable)

Commitment

Daily ScrumMeeting

Retrospective

7

8

9

10

11

12

1

2

3

45

6

13


13/133

The Basics of Scrum

4-Week

Sprint


Product

Product OwnerReview

ScrumMaster

The Team

7

8

9

10

11

12

1

2

3

45

6

13


Commitment

Daily ScrumMeeting

Retrospective


14/133

Product Owner Responsible for the overall project vision and goals

Responsible for managing project ROI vs. risk

Responsible for taking all inputs into what the

team should produce, and turning it into a

prioritized list (the Product Backlog)

Participates actively in Sprint Planning and Sprint

Review meetings, and is available to team

throughout the Sprint

Determines release plan and communicates it to

upper management and the customer


15/133

The Basics of Scrum

4-Week

Sprint


Product

Product OwnerReview

ScrumMaster

The Team

7

8

9

10

11

12

1

2

3

45

6

13


Commitment

Daily ScrumMeeting

Retrospective


16/133

Team 7 people, + or 2

Has worked with as high as 15, as few as 3 Can be shared with other teams (but better when not)

Can change between Sprints (but better when they dont)

Can be distributed (but better when colocated)

Cross-functional

Possesses all the skills necessary to produce an increment

of potentially shippable product Team takes on tasks based on skills, not just official role

Self-managing

Team manages itself to achieve the Sprint commitment


17/133

The Basics of Scrum

4-Week

Sprint


Product

Product OwnerReview

ScrumMaster

The Team

7

8

9

10

11

12

1

2

3

45

6

13


Commitment

Daily ScrumMeeting

Retrospective


18/133

The Role of the ScrumMaster

The ScrumMaster does everything intheir power to help the team achieve

success

This includes: Serving the team

Protecting the team

Guiding the teams use of Scrum


19/133

What the ScrumMaster Does Serves the team

The ScrumMaster takes action to help remove impediments to theteams effectiveness

The ScrumMaster facilitates the teams group interactions, to helpthe team achieve its full potential

The ScrumMaster coaches the team, to help them improve theirpractices and effectiveness

Protects the team The ScrumMaster protects the team from anything that threatens its

effectiveness, such as outside interference or disruption

The ScrumMaster will need to confront uncomfortable issues, bothinside and outside the team

Guiding the teams use of Scrum The ScrumMaster teaches Scrum to the team and organization The ScrumMaster ensures that all standard Scrum rules and practices

are followed

The ScrumMaster organizes all Scrum-related practices


20/133

What Does the ScrumMaster NOT Do?

The ScrumMaster does not manage the team

The ScrumMaster does not direct team-members

The ScrumMaster does not assign tasks

The ScrumMaster does not drive the team to

hit its goals

The ScrumMaster does not make decisions for

the team

The ScrumMaster does not overrule team-members

The ScrumMaster does not direct product

strategy, decide technical issues, etc.


21/133

What Happens to the Manager in Scrum?

The Team

Manager


22/133

4-Week

Sprint


Product

Product OwnerReview

Scrum

Master

The Team

7

8

9

10

11

12

1

2

3

45

6

13


Commitment

Daily ScrumMeeting

Retrospective

What Happens to the Manager in Scrum?

Manager

?


23/133

The New Role of the Manager

4 Possibilities

ScrumMaster

Possible issues?

Product Owner Possible issues?

Team Member

Possible issues?

Manager 2.0


24/133

Manager 2.0

Step 1 Create list of everything the

Manager used to be responsible for (comeup with as many items as possible, at least10 items)

Step 2 Cross off this list everything that: Conflicts with Scrum

Is unnecessary in Scrum

Would undermine the team's self-organizationand self-management


25/133

Help remove impediments that the team is not

able or well-placed to resolve themselves

Fire team-members who are consistently not

able to perform

Plan and oversee budgets and financials, and

think about tools, skills and other future needs

Recruit, interview and hire new members of the

team

Stay abreast of latest developments in the

technology their team uses, industry news, etc.

Conduct weekly update and 1:1 meetings with

team, to surface issues, and provide direction

Plan training for team, and do career-

development and planning with team-

members

Monitor the team's progress, to make sure they

stay on schedule, and aren't having problems

Provide advice and input to the team on

difficult technical issues that come up

Convince team that the commitments made on

their behalf are attainable

Do performance evaluations and provide

feedback to team-members

Give direction to the team on how to do the

work, so they can meet the commitment I made

Provide input on features, functionality, and

other aspects of whats being produced

Make commitments on behalf of the team

about how much they can get done by X date

Surface issues to the team that they might

overlook scaling, performance, security, etc.

Keep track of whether team-members have

done the tasks Ive assigned to them

Provide coaching and mentorship to team-

members

Decide task assignments among the team

members and assign them


26/133

Manager 2.0

Step 3 Help the manager turn this into a

new job description Step 4 Get sign-off / agreement from the

managers manager


27/133

The Basics of Scrum

4-Week

Sprint


Product

Product OwnerReview

Scrum

Master

The Team

7

8

9

10

11

12

1

2

3

4

5

6

13


Commitment

Daily ScrumMeeting

RetrospectiveProduct Backlog


28/133

Product Backlog

Product Owner listsitems in descending

order of priority (highest

priority item is listed

first, next-highest is

second, etc.)

Size estimates are rough

estimates (can either be

arbitrary points, or

ideal days)


29/133

Product Backlog

List of everything that could ever be of value tothe business for the team to produce

Ranked in order of priority Priority is a function of business value versus risk

Product Owner can make any changes they want

before the start of a Sprint Planning Meeting Items added, changed, removed, reordered

How much documentation is up to the team andProduct Owner to decide

The farther down the list, the bigger and lessdefined the items become ~2 Sprints worth are defined in detail


30/133

User Stories

User Stories are a good approach for

writing Product Backlog Items User Stories are a short, plain-language

description of the functionality, in terms of

the customer benefit and need


31/133

Good Format

As a

I want

So that

As a customer, I can place an item

on my wishlist, so that I can

decide later whether or not I wantto buy it

As a frequent flyer member, I can

see the number of miles I have

earned in my frequent flyer

account, so that I can decide

whether to redeem them for a

ticketAs a new user, I can set up a

profile so that potential

employers can find out more

about my skills and qualifications


32/133

The Basics of Scrum

4-Week

Sprint


Product

Product OwnerReview

Scrum

Master

The Team

7

8

9

10

11

12

1

2

3

4

5

6

13


Commitment

Daily Scrum

Meeting

RetrospectiveProduct Backlog


33/133

Sprint Planning Meeting

Takes place before the start of every Sprint

Team decides how much Product Backlog it will committo complete by the end of the Sprint, and comes up witha plan and list of tasks for how to achieve it

Whats a good commitment?

Clearly understood by all Shared among the team

Achievable without sacrificing quality

Achievable without sacrificing sustainable pace

Attended by Team, Product Owner, ScrumMaster,Stakeholders

May require 1-2 hours for each week of Sprint duration 2 week Sprint = 2-4 hours, 4 week Sprint = 4-8 hours


34/133

Sprint Planning

Team understands thedetails of what the ProductOwner has prioritized onthe Product Backlog

Team decides how

much productivetime it has availableduring the Sprint

Team decides howmany Product Backlogitems it can committo complete during

the Sprint


35/133

Sprint Planning

Team understands thedetails of what the ProductOwner has prioritized onthe Product Backlog

Team decides how

much productivetime it has availableduring the Sprint

Team decides howmany Product Backlogitems it can committo complete during

the Sprint

Sprint

Pre-PlanningMeeting

Sprint

PlanningMeeting


36/133

Sprint Cycle: 2-Week Sprint

2423222120

3130292827

1716151413

109876

321

FriThursWedsTuesMon

Sprint

Planning

Meeting

Sprint Review

& Retrospective

2 3 41

6 75 8


37/133

Sprint Cycle: 4-Week Sprint

2423222120

3130292827

1716151413

109876

321

FriThursWedsTuesMon

Sprint

Planning

Meeting2 3 41

6 75 8 9

11 1210 13

Sprint Review

& Retrospective16 1715 18

14


38/133

Available Time During Sprint

25 (5 * 5)55Jing

24 (8 * 3)38Phillip

35 (7 * 5)57Sanjay

32 (8 * 4)48Tracy

Total Avail Hrs

in Sprint

Avail Hours

Per Day

Avail Days

During Sprint*Team Member

8 daysWorkdays During Sprint

2 weeksSprint Length

*Net of holidays and other

days out of the office


39/133

Hours Per Day

8-Hour Day

meetings, e-mail

lunch and tea breaks

hacking, reading blogs, playing foosball

time available for productive work


40/133

Hours Per Day

8-Hour Day

meetings, e-mail




operational responsibilities


41/133

Hours Per Day

8-Hour Day

meetings, e-mail




operational responsibilities


42/133

Hours Per Day

8-Hour Day

meetings, e-mail




time committed to another team


43/133


25 (5 * 5)55Jing

24 (8 * 3)38Phillip

35 (7 * 5)57Sanjay

32 (8 * 4)48Tracy

Total Avail Hrs

in Sprint

Avail Hours

Per Day

Avail Days







44/133

Another Approach: Quarter Days

1 Day

1/4 Day

1/4 Day

1/4 Day

1/4 Day


45/133

Available Time in Days

20 (5 * 4)5Jing

32 (8 * 4)8Phillip

28 (7 * 4)7Sanjay

32 (8 * 4)8Tracy

Total Avail

Days in Sprint

Avail Days







46/133


47/133

Product Backlog


48/133

Getting to Done

3TomDocumentation

Upgrade

transaction

processing

module

2PhilipRegression testing

4PhilipUnit testing

8JoeImplement front-end code

6TracyImplement back-end code

2TracySet up shopping cart module

2JingDesign user interface

4SanjayDesign business logic

Enable all

users to place

book in

shopping cart

EstimateOwnerTaskBacklog

Item

G i T D


49/133

Getting To Done

S P R I N T

DESIGN CODE TEST

G i T D


50/133

Getting To Done

S P R I N T

DESIGN CODE TEST

S P R I N T S P R I N T

G tti T D


51/133

Getting To Done

DESIGN

TEST

CODE

G tti T D


52/133

Getting To Done

S P R I N T

DESIGN CODE TEST

C ti th S i t B kl


53/133

Creating the Sprint Backlog

3TomDocumentation

Upgrade

transaction

processing

module


4PhilipUnit testing

8JoeImplement front-end code

6TracyImplement back-end code

2TracySet up shopping cart module

2JingDesign user interface4SanjayDesign business logic

Enable all

users to place

book inshopping cart

EstimateOwnerTaskBacklog

Item



54/133


2555Jing

2438Phillip

35 3157Sanjay

32 28 2548Tracy

Total Avail Hrs

in Sprint

Avail Hours

Per Day

Avail Days






Sprint Planning Ends when


55/133

Sprint Planning Ends when

Teams available time is mostly committed

Good idea to go through and make suretheres full agreement on the commitment

After the meeting, ScrumMaster turns the

task list into the Sprint Backlog

The Sprint Backlog


56/133

The Sprint Backlog

5TracyImplement back-end

code

Upgradetransaction

processing

module

6JoeComplete

documentation

3PhilipUnit testing


214Total

32

2

4

8

6

2

2

4

Initial

Est.

Day of Sprint

1 4 5

PhilipRegression testing

PhilipUnit testing

JoeComplete

documentation

TracyImplement front-end

code

TracyImplement back-end

code

JingDesign user interface

SanjayDesign business logic

Enable all

users to place

book in

shopping cart

6OwnerTaskBacklog

Item


57/133

And the Sprint Begins!


The Basics of Scrum


58/133

The Basics of Scrum

4-WeekSprint

PotentiallyShippableProduct

Product OwnerReview

Scrum

Master

The Team

7

8

9

10

11

12

1

2

3

4

56

13


Commitment

Daily Scrum

Meeting

Retrospective

Intensity


59/133

Intensity

Time

Intensity

Waterfall

Scrum

The Basics of Scrum


60/133

The Basics of Scrum

4-WeekSprint


Product OwnerReview

Scrum

Master

The Team

7

8

9

10

11

12

1

2

3

4

56

13


Commitment

Daily Scrum

Meeting

Retrospective

No Changes During Sprint


61/133

No Changes During Sprint

No Changes to the Deliverable

Once team has committed, no changes to thedeliverable

If something major comes up, Product Ownercan terminate the Sprint and start new one

Details and clarifications will emerge duringSprint, but no new work or substantiallychanged work

Difference between change andclarification

If theres any doubt, then its a change

Impact of Change


62/133

Impact of Change

Every Future SprintCurrent Sprint

Teams

discipline in

following theother rules of

Scrum

Other teams

discipline in

following the

rules of Scrum

POs

discipline in

preparing theProduct

Backlog

Teams focus

on delivering

what it

committed to

Teams focus

on delivering

what it

committed to

Product

Owners

discipline tonot request

changes

Teams ability

to deliver

what it

committed to

Near-term

Priorities of

Product

Owner

What happens if the Product Owner gets to add just a small

amount of work, or swap work in & out during the Sprint?

What if the Team is Responsible for


63/133

Emergency Response?

What is Emergency Response?

Critical operational issues

P1 (critical) Bugs in a live system

2 approaches that some teams use

Designated Responder

Emergency Response Buffer

Not Scrum standard! Proceed at your own risk

Option 1: Designated Responder


64/133


Scrum Work

(items from theProduct Backlog

that the team has

committed to do)

Critical Issues

(emergency requeststhat need to be

responded to

immediately)



65/133


Product Backlog Work(items from the Product

Backlog that the team has

committed to do)

Critical Issues(emergency requests

that need to be

responded to quickly)

Commits in this Sprint to

complete items 1-13 on

the Product Backlog

Commits to fix Critical Issues.

May work on items from lower

on Backlog (items >13)

Scrum Team D.R.

Option 2: Emergency Response Buffer


66/133


Scrum Work(items from the

Product Backlog

that the team has

committed to do)

Critical Issues(emergency requests

that need to be

responded to

immediately)



67/133

8-Hour Day

productive time available

meetings, email, lunch, etc.

Opt o : e ge cy espo se u e



68/133

8-Hour Day Emergency Response Buffer

time available to commit to the Sprint

meetings, email, lunch, etc.

p g y p



69/133

To make this work, 3 things are required Clear definition of what qualifies as a Emergency

Response request (these are the only things that teamwill work on)

Time spent from ER Buffer must be tracked whenbuffer gets to 0, work on bugs has to stop, or Sprint hasto be terminated

Team must have the discipline to follow first two points

Risks

Becomes a back door for change during the Sprint Buffer overrun

p g y p

The Basics of Scrum


70/133

4-WeekSprint


Product OwnerReview

Scrum

Master

The Team

7

8

9

10

11

12

1

2

3

4

5

6

13


Commitment

Daily Scrum

Meeting

Retrospective

Daily Scrum Meeting


71/133

y g

Purpose of Daily Scrum Meeting Keep team coordinated and up-to-date with each other

Surface impediments daily How it works

Every weekday

Whole team attends

Team chooses a time that works for everyone

Product Owner can attend, but doesnt speak

Everyone stands in a circle, facing each other (not facing the SM)

Lasts 15 minutes or less

Everyone reports 3 things only to each other What was I able to accomplish since last meeting What will I try to accomplish by next meeting

What are my blocks / problems / difficulties

No discussion or conversation until meeting ends

Table Exercise: Daily Scrum Meeting


72/133

y g

Do a Daily Scrum Meeting for your table

One person plays the role of ScrumMaster

The rest of the table are team-members

Each team-member reports to the group:

What I was able to get done since last Daily StandupMeeting

What I will try to get done by the next Daily Standup

Meeting

What is blocking me? (If nothing, say No Blocks)

Follow the instructions on the slips

Updating the Sprint Backlog


73/133

After the Daily Scrum, team members

update the hours remaining on the SprintBacklog

Updating the Sprint Backlog


74/133

8105TracyImplement back-end

codeUpgrade

transaction

processing

module

666JoeCompletedocumentation

333PhilipUnit testing


180210214Total

3

2

3

6

6

2

20

2

2

4

8

6

2

24

Initial

Est.

Day of Sprint

2

3

6

6

4

22

1 4 5

PhilipRegression testing

PhilipUnit testing

JoeCompletedocumentation

TracyImplement front-end

code

TracyImplement back-end

code

JingDesign user interfaceSanjayDesign business logic

Enable all

users to place

book in

shopping cart

6OwnerTaskBacklog

Item

Burndown Chart


75/133

Task Board


76/133

IN PROGRESSTO DO DONE

Task Board


77/133


Task: Configure databaseand SpaceIDs for Trac

Owner: Sanjay

Task Board


78/133

Task: ConfiguredatabaseandSpaceIDsfor Trac

Owner: SanjayTimeRemaining:4hrs










Owner:`SanjayTimeRemaining:4hrs
















































Task Board


79/133




























































Task Board


80/133




























































Task Board


81/133




























































Task Board


82/133




























































Task Board


83/133




























































The Basics of Scrum


84/133

4-WeekSprint


Product

Product OwnerReview

ScrumMaster

The Team

7

8

9

10

11

12

1

2

3

4

5

6

13


Commitment

Daily Scrum

Meeting

Retrospective

Sprint Review


85/133

Purpose of the Sprint Review Demo what the team has built

Make visible whether the team completed what they set out to

Generate feedback, which the Product Owner can incorporate inthe Product Backlog

Attended by Team, Product Owner, ScrumMaster,

functional managers, and any other stakeholders A demo of whats been built, not a presentation about

whats been built no Powerpoints allowed!

Usually lasts 1-2 hours Followed by Sprint Retrospective

The Basics of Scrum


86/133

4-WeekSprint


Product

Product OwnerReview

ScrumMaster

The Team

7

8

9

10

11

12

1

2

3

4

5

6

13


Commitment

Daily Scrum

Meeting

Retrospective

Sprint Retrospective


87/133

What is it?

1-2 hour meeting following each Sprint Demo

Attended by Product Owner, Team, ScrumMaster

Usually a neutral person will be invited in to facilitate

Whats working and what could work better

Why does the Retrospective matter?

Accelerates visibility

Accelerates action to improve


88/133

WHAT WORKED WHAT DIDNT WORK

W didnt finish h t c mmitt d t in thT m f lt m f cus d th n b f n


89/133

We didn t finish what we committed to in thetime available

Our estimations were way off

We didnt think through the dependenciesbetween tasks

The coordination between developers andtesters wasnt very good

Our daily Scrum meeting didnt start on time

The food in the cafeteria was really bad

There were a lot of outside distractions

during the SprintBlocks didnt get removed quickly enough bythe ScrumMaster

There were too many bugs yet to be fixed atthe end of the Sprint

Team didnt really work together as a team still felt like a group of individuals

Team felt more focused than before onhitting its goals

Sense of commitment for the team washigher

Team had a better sense of where it was inthe Sprint because of the burndown chart

The Daily Scrum Meeting improved Teamcommunication during the Sprint

Good idea came out during the Sprint Review

Planning Poker


90/133

Getting Started

1. Everyone creates cards with followingvalues on them: ?, , 1, 2, 3, 5, 8, 13, 20, 50

(WRITE LARGE USING MARKER!)

2. Team agrees on a backlog item to use as abaseline or benchmark, and gives it a

size of 5 (item should be neither biggest

nor smallest on list)

3. Size = Effort x Complexity x Uncertainty

Planning Poker


91/133

For each Product Backlog item:1. Each person decides their size estimate relative

to the items that have already been estimated,and privately selects a card

2. Everyone shows their cards at the same time(ScrumMaster says 1-2-3-Show)

3. If estimates vary significantly, high and lowestimators briefly explain

4. Repeat steps 3-5 until estimates stopconverging

5. Decide estimate for backlog item

6. Move to next backlog item


92/133

The Release Cycle in Scrum


Scrum Release Cycle


93/133

2 Common Approaches:

S P R I N TS P R I N T S P R I N T S P R I N T S P R I N T S P R I N T

RELEASE

Multi-Sprint Release

S P R I N T S P R I N T S P R I N T S P R I N T S P R I N T S P R I N T

RELEASE RELEASE RELEASE RELEASE RELEASE RELEASE

Release Every Sprint

Multi-Sprint Release One Approach


94/133

PRE-RELEASES P R I N T

S P R I N T 0 S P R I N T S P R I N T S P R I N T S P R I N T

RELEASE

HIGH-LEVEL DESIGN

& ARCHITECTURE,

INVESTIGATION,

SETUP OF DEV EL

ENVIRONMENT

FINAL STABILIZATION,

TESTING, RELEASE

PREPARATION

Multi-Sprint Release One Approach


95/133

S P R I N T 0 S P R I N T S P R I N T S P R I N T S P R I N T

RELEASE

HIGH-LEVEL DESIGN

& ARCHITECTURE,

INVESTIGATION,

SETUP OF DEV EL

ENVIRONMENT


96/133

Release Planning and

Estimation in Scrum


Estimation and Release Planning


97/133

You can continue to use your existing estimationmethods, if theyre working for you

Scrum will almost certainly allow you to get the sameor more done in a given timeframe

However, there are Scrum-specific methods that

many teams find more effective that theirprevious approaches

Estimation in Scrum is based on whats calledVelocity Velocity is measure of how much Product Backlog the

team can complete in a given amount of time

Product Backlog


98/133

Velocity Based on Historical Data


99/133

90 points

120 points

100 points

~105 size points per Sprint

Teams Recent Sprints

How to Plan a Release in Scrum


100/133

Calculate velocity then apply to the Product Backlog:

Teams velocity is

~105 points per

Sprint

Therefore, in 6

Sprints, the team

should be able to

complete

This is 620

points of

ProductBacklog

6 x 105

= 630 points worth of

Product Backlog

Velocity Calculation


101/133

S P R I N T 1 S P R I N T 2 S P R I N T 3 S P R I N T 4 S P R I N T 5

Initial Estimate

Of Velocity at

Project StartRefinement

of Estimate

based on

1 Sprint of

Actual Data

Recalculation

based on

2 Sprints of

Actual Data

Recalculation

based on

3 Sprints of

Actual Data

Recalculation

based on

4 Sprints ofActual Data

Release Planning


102/133

Product Owner determines whether Its a feature-driven release (launch when features

X, Y, Z can be completed)

Its a date-driven release (launch on April 15 with as

many features as possible)

Its date- and feature-driven (launch on April 15with features X, Y, Z)


103/133

Using Scrum for Multi-Location

Development

Distributed Scrum Practices


104/133

Structure A: Product Owner is in US, team is

in India

One Common Approach

ScrumMaster located with team in India

2-week Sprints Team holds daily standup meetings in own

location

ScrumMaster emails blocks list to Product Owner forassistance clearing in US



105/133

Sprint Planning

Team has 1 hour real-time meeting with Product Owner to

discuss goals of Sprint, broad review of Product Backlog Items(example: Weds night IST)

Team spends 1-3 hours doing preliminary analysis and

breakdown of Product Backlog Items (example: Thurs

afternoon IST)

Team spends 1-3 hours real-time with Product Owner

completing analysis and breakdown of Product Backlog Items,

and makes commitment (example: Thurs night IST)

Sprint begins (example: Fri morning IST)

Sprint Review and Retrospective

Videoconference + Webex (example Weds morning IST)



106/133

Product Owner in US travels to India for project kickoff

All real-time meetings with Product Owner are visual

Videoconference + Webex

Use a webcam if you have to

Mailing list for Product Owner and all team members,

with most project-related emails cc:ed to this list

Verbose subject lines to emails

At least 1 weekly 1-hour real-time check-in between

Product Owner and team

In-person planning and review regroup in India or USbetween Product Owner and team at least once per

quarter

Distributed Team


107/133

Stucture B: Team split between two locations For example, 3 developers, 1 tester, and 1 analyst in US, 5

developers and 1 tester in India 2 ScrumMasters, one in each location

Lighter load than a full ScrumMaster may be a team-member

2 separate daily standup meetings

Notes from each teams standup emailed to the otherand read at the beginning of the meeting

(this is in addition to all the previous recommendations)


108/133

Scaling Scrum

Scaling Scrum


109/133

Team A Team B Team C Team D Team E

Scaling Scrum


110/133

Product Owner


Scaling Scrum


111/133

Senior Product Owner


PO PO POPO PO

During the Sprint


112/133


Scrum of ScrumsDaily / 2-3 times per week

Coordination, Dependencies Mgt, Block Surfacing


113/133

Module: Using Scrum in a FixedBid Environment

Contract Terms


114/133

the party in the first part shall remunerate the party in

notwitstanding the foregoing clause, the party in the first

3.1.1 Vendor will demo potentially shippable software to

Customer every 30 days. There will be noadditional charge for this.

3.1.2 Customer can replace any requirements that Vendor

hasnt yet started working on with one or more of

equal total size (in the estimate of Vendor) at any

time. There will be no additional charge for this.

3.1.3 Customer may request interim releases at any time,

and will be charged an agreed-upon time and

materials cost.

3.1.4 If Customers business goals are satisfied early,

Customer may terminate contract early for 20% of

the remaining unbilled contracted amount.


115/133

Module: Scrum and Metrics

Scrum and Metrics

Scrum doesnt prevent you from tracking or


116/133

Scrum doesn t prevent you from tracking ormeasuring any aspect of the development

process you choose However, you must be mindful of

unintended consequences of measurement

Example: Individual burndown charts

Recording or reporting measurements willprobably require effort

If this effort comes from team-members, itshould be made visible in their task timeestimates or as Backlog Items


117/133

Strategies for SuccessfulScrum Adoption in

the Enterprise


118/133

1. Start With the Teams That Want To Do It

Scatter the seeds of Scrum widely then watch


119/133

Scatter the seeds of Scrum widely, then watch

closely where they sprout

One of the requirements for first pilots should beeveryone on the team had to be open to it

working

Skepticism is fine and healthy, but no overtresistance

2. Call It a Pilot Program

Pilots are supposed to be chaotic


120/133

Pilots are supposed to be chaotic,uncertain, bumpy, messy

Keep calling it a pilot as long as possible

People will ask whens the decision goingto get made to officially adopt Scrum

Wait to make that decision until there are nomore teams lining up to make the change

Then ask yourself what is it about theremaining teams?

Some people will be uncomfortable, unhappy, scared

3. Change is Scary to Many People... andScrum is Really Scary to Some People


121/133

p p , ppy, And is it unexpected? How many management fads have

preceded Scrum?

Emphasize the common sense nature of it Were not making a change were trying a new approach, and

deciding whether its better than the old way

Ken Schwaber: Were not really using scrum

Some of those people will get past it, some of them wont Just 4 months in, some of the biggest early Scrum skeptics

had evolved into the greatest Scrum evangelists Give people the room to change

Avoid battle-lines

4. Patience is a Virtue

Err on the side of making fewer teams more successful


122/133

o t e s de o a g e e tea s o e success u

Every team will hit some big bump kicking off scrum

Many will need some support, if only moral In the early days, there are many more evangelists for

failure than for success

Even the undecided will assume that an early failure is a

strike against scrum Overbudget the time early teams will need to work

through systemic issues

5. Find the Middle Path Philosophically

Scrum Purists


123/133

Tend to be the initial instigators

They also tend to be the first to feel anxiety as Scrumstops being a guerrilla campaign, and becomes howthe army is run

Scrum Pragmatists

Tend to be more effective in big organizations Also more prone that the purist to compromise,

possibly at the expense of effectiveness

Dont let either of them win outright

Make sure you have both!

6. Set a High Bar and Low Expectations forTeams that Want to Use Scrum

Its very easy when evangelizing scrum to set


124/133

It s very easy when evangelizing scrum to setunrealistic expectations

potential benefit work required

People know when theyre being sold

People also pick up on respectful realism tell them its hard, tell them it involves risk, and

emphasize that only they in their hearts know if itmight be right for their team

7. Scrum is Hard

Scrum surfaces all sorts of nasty stuff


125/133

Scrum surfaces all sorts of nasty stuff

Make sure people are prepared

Make sure they understand that this is Scrumworking, not failing

Help teams learn from each other

Be ready to stage a rescue mission

There are some problems teams cant solve bythemselves

8. Get Experienced Help

Outside experts can help with specific practices,


126/133

Outside experts can help with specific practices,

training, etc.

Dont overlook perhaps their greatest help in the earlydays: telling you theyve seen this a million times

before, and its all going to be fine

And at the same time, making sure you dont overlookand slack off on something important

9. Your Enemy is Your Friend

Spend the most time with the people who like


127/133

p p p

Scrum least

Before you have momentum, Scrum detractors canhave more impact the Scrum proponents

Get close to the detractors, and make them part of the

team Who knows, some of them might actually have

something valid to contribute

10. Be Prepared to Use Guerilla Tactics to GetThings Done

Some of the obstacles to Scrum are big


128/133

Some of the obstacles to Scrum are big

Organizational, policy, management...

Many are small

conference room table

Focus on the big ones

11. Make Good Information More Accessiblethan Bad Information

As a Scrum rollout picks up momentum, the


129/133

rumor mill becomes more of a factor

Good rumors as well as bad You have to release every month

You get to release every month!

Make sure theres a constant flow of goodinformation Email updates, brown-bag lunches, staff meeting talks

Start building a fun list of the top N greatest myths

about Scrum

12. Find Your Evangelists

Build a network that includes every group of the


130/133

company, and every level

Make sure theyre well educated on reality, andalso able to be candid, with you and others you want them able to bring you the nuggets of

information or news asap

Very helpful to have a senior executive advocate with a single statement they can set the default

management attitude to scrum

beware getting them TOO excited though

13. Measure the Results Early and Often

Scrum is in part about making things visible


131/133

p g g

So measure the results and experiences from a

bunch of different angles

Publicize both the good and bad

14. The Urge to Tinker is Great

Everyone has a way to improve Scrum


132/133

Important to set standards and adhere to them

If it isnt scrum, dont let people call it Scrum Protect Scrums good name!

15. Scrum will Always Be Messy

Scrum is about people, and people are


133/133

messy

Inconsistent, insensitive, erratic, make mistakes

For this reason, it will never be perfect

Idealists will always be disappointed

Opponents will always have ammo

Just keep asking, is it better than before

LAST

intro to scrum slides 2.0

Documents