Introduction to Scrum for AGILE by Kamalakar Dandu

Introduction to Scrum

Pete DeemerCPO, Yahoo! India R&D

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.

The Waterfall

Requirements Gathering

Design

Development

Testing

Launch & Maintain

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

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β

Iterative Incremental Development

“Iterative development is an approach to building software (or anything) in which the overall lifecycle is composed of several iterations in sequence. Each iteration is a self-contained mini-project composed of activities such as requirements analysis, design, programming, and test. Usually the partial system grows incrementally with new features, iteration by iteration; in other words, incremental development.”

--Craig Larman

Iterative Development

Time

AdaptabilityIterative Development

All-At-Once Development

Iterative Development

Time

VisibilityIterative Development

All-At-Once Development

Incremental Development

Time

Value

IncrementalDelivery

All-At-OnceDelivery

Incremental Development

Time

Risk / Uncertainty

IncrementalDelivery

All-At-OnceDelivery

The Agile Manifesto – 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:

That is, while there is value in the items on

the right, we value the items on the left more.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

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:

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

Google Adwords, “the highest ROI software project in history”

Scrum Disadvantages

It’s hard!Makes all dysfunction visible

Scrum doesn’t fix anything: the team has to do itFeels like things are worse at the beginning

Bad products will be delivered sooner, and doomed projects will fail faster High risk of turnover

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

Partial adoption may be worse than none at allIf adoption fails, time will have been wasted, and some people may leave

Scrum Basics


The Basics of Scrum

4-WeekSprint

Potentially Shippable

Product

Product OwnerReview

ScrumMaster

The Team

789101112

1234

56

13

No Changes(in Duration or Deliverable)

Commitment

Daily ScrumMeeting

Retrospective

789101112

123456

13

The Basics of Scrum

4-WeekSprint


Product

Product OwnerReview

ScrumMaster

The Team

789101112

1234

56

13


Commitment

Daily ScrumMeeting

Retrospective

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

The Basics of Scrum

4-WeekSprint


Product

Product OwnerReview

ScrumMaster

The Team

789101112

1234

56

13


Commitment

Daily ScrumMeeting

Retrospective

Team

7 people, + or – 2Has 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 don’t)

Can be distributed (but better when colocated)

Cross-functionalPossesses all the skills necessary to produce an increment of potentially shippable product

Team takes on tasks based on skills, not just official “role”

Self-managingTeam manages itself to achieve the Sprint commitment

The Basics of Scrum

4-WeekSprint


Product

Product OwnerReview

ScrumMaster

The Team

789101112

1234

56

13


Commitment

Daily ScrumMeeting

Retrospective

The Role of the ScrumMaster

The ScrumMaster does everything in their power to help the team achieve success

This includes:Serving the team

Protecting the team

Guiding the team’s use of Scrum

What the ScrumMaster Does

Serves the teamThe ScrumMaster takes action to help remove impediments to the team’s effectivenessThe ScrumMaster facilitates the team’s group interactions, to help the team achieve its full potential

Protects the teamThe ScrumMaster protects the team from anything that threatens its effectiveness, such as outside interference or disruptionThe ScrumMaster will need to confront uncomfortable issues, both inside and outside the team

Guiding the team’s use of ScrumThe ScrumMaster teaches Scrum to the team and organizationThe ScrumMaster ensures that all standard Scrum rules and practices are followedThe ScrumMaster organizes all Scrum-related practices

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.

What Happens to the “Manager” in Scrum?

The Team

Manager

4-WeekSprint


Product

Product OwnerReview

ScrumMaster

The Team

789101112

1234

56

13


Commitment

Daily ScrumMeeting

Retrospective

What Happens to the “Manager” in Scrum?

Manager

?

The New Role of the Manager

4 PossibilitiesScrumMaster

Possible issues?

Product OwnerPossible issues?

Team MemberPossible issues?

“Manager 2.0”

Manager 2.0

Step 1 – Create list of everything the Manager used to be responsible for (come up with as many items as possible, at least 10 items)Step 2 – Cross off this list everything that:

Conflicts with ScrumIs unnecessary in ScrumWould undermine the team's self-organization and self-management

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 what’s 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 I’ve assigned to them

Provide coaching and mentorship to team-members

Decide task assignments among the team members and assign them

Manager 2.0

Step 3 – Help the manager turn this into a new job description

Step 4 – Get sign-off / agreement from the manager’s manager

The Basics of Scrum

4-WeekSprint


Product

Product OwnerReview

ScrumMaster

The Team

789101112

1234

56

13


Commitment

Daily ScrumMeeting

RetrospectiveProduct Backlog

Product Backlog

Product Owner lists items 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”)

Product Backlog

List of everything that could ever be of value to the business for the team to produceRanked in order of priority

Priority is a function of business value versus riskProduct Owner can make any changes they want before the start of a Sprint Planning Meeting

Items added, changed, removed, reorderedHow much documentation is up to the team and Product Owner to decideThe farther down the list, the bigger and less defined the items become

~2 Sprints worth are defined in detail

The Basics of Scrum

4-WeekSprint


Product

Product OwnerReview

ScrumMaster

The Team

789101112

1234

56

13


Commitment

Daily ScrumMeeting

RetrospectiveProduct Backlog

Sprint Planning Meeting

Takes place before the start of every SprintTeam decides how much Product Backlog it will commit to complete by the end of the Sprint, and comes up with a plan and list of tasks for how to achieve itWhat’s a good commitment?

Clearly understood by allShared among the teamAchievable without sacrificing quality Achievable without sacrificing sustainable pace

Attended by Team, Product Owner, ScrumMaster, StakeholdersMay require 1-2 hours for each week of Sprint duration

2 week Sprint = 2-4 hours, 4 week Sprint = 4-8 hours

Sprint Planning

Team understands the details of what the ProductOwner has prioritized on the Product BacklogTeam decides how much productive time it has available during the SprintTeam decides howmany Product Backlog items it can commit to complete during the Sprint

How much “money”do we have in our

bank account?

How many items on the shopping list can we afford to “buy”with that “money”

What’s on the Product Owner’s “shopping list”

Sprint Planning


SprintPre-Planning

Meeting

SprintPlanningMeeting

Sprint Planning


SprintPre-Planning

Meeting


Weds Thurs Fri Mon Tues

Pre-Meetingfor Sprint 4

Review & Retrospective

for Sprint 3(afternoon)

Sprint PlanningMeeting for

Sprint 4(morning)

Sprint 4 Begins

Sprint Pre-Planning Meeting

Not textbook Scrum, but many teams find it useful

Takes place several days before the end of a Sprint (and start of the next Sprint

Product Owner spends an hour walking the team through the items at the top of the Product Backlog for the nextSprint

Team asks questions, requests clarification, recommend items to be broken down further

Sprint Planning


SprintPre-Planning

Meeting


Sprint Planning


SprintPre-Planning

Meeting


Sprint Cycle: 2-Week Sprint

2423222120

3130292827

1716151413

109876

321

FriThursWedsTuesMon


First Dayof Sprint

Last Dayof Sprint

Sprint Review& Retrospective

2 3 41

6 75 8



2423222120

3130292827

1716151413

109876

321

FriThursWedsTuesMon


2 3 41

6 75 8 9

11 1210 13

Sprint Review& Retrospective16 1715 18

14


2423222120

3130292827

1716151413

109876

321

FriThursWedsTuesMon



2 3 41

6 75 8



2 3 41

6 75 8

Sprint Review& Retrospective6 75 8

1-Hr Pre-Meeting for Next Sprint

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

Hours Per Day

“10-Hour Day”

meetings

reading and writing e-mail

lunch and tea breaks

hacking, reading blogs, playing foosball

time available for productive work

Hours Per Day

“10-Hour Day”

meetings




fixing P1 critical bugs

time available to commit to the Sprint

Hours Per Day

“10-Hour Day”

meetings





fixing P1 critical bugs

Hours Per Day

“10-Hour Day”

meetings





time committed to another team


25 (5 * 5)55Jing

24 (8 * 3)38Phillip

35 (7 * 5)57Sanjay

32 (8 * 4)48Tracy


Avail Hours Per Day


Team Member




Another Approach: Quarter Days

“1 Day”

1/4 Day

1/4 Day

1/4 Day

1/4 Day

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


Team Member




Sprint Planning


SprintPre-Planning

Meeting


Product Backlog

Creating the Sprint Backlog

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

Defining “Done”

In Scrum, “Done” is defined as “Potentially Shippable”

How many teams are able to achievepotentially shippable from Sprint 1?

PRE-RELEASES 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

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

Getting to “Done”

3TomDocumentation


module


4PhilipUnit testing









Item

S P R I N T

DESIGN CODE TEST

Getting To “Done” – Not a Good Way

S P R I N T

DESIGN CODE TEST

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



DESIGN

TEST

CODE

Getting To “Done” – A Good Way

S P R I N T

DESIGN CODE TEST

Creating the Sprint Backlog

3TomDocumentation


module


4PhilipUnit testing









Item


2555Jing

2438Phillip

35 3157Sanjay

32 28 2548Tracy


Avail Hours Per Day


Team Member




Task Estimation

% Likelihood

Time

Do we need to be 100% accurate in our time estimations for tasks, in order to be successful in Scrum?

Sprint Planning Ends when…

Team’s available time is mostly committed

Good idea to go through and make sure there’s full agreement on the commitment

After the meeting, ScrumMaster turns the task list into the Sprint Backlog

The Sprint Backlog

5TracyImplement back-end codeUpgrade

transaction 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



6OwnerTaskBacklog

Item

And the Sprint Begins!


The Basics of Scrum

4-WeekSprint


Product

Product OwnerReview

ScrumMaster

The Team

789101112

1234

56

13


Commitment

Daily ScrumMeeting

Retrospective

The Sprint

Sprint Length4 weeks is standard in literature

Many teams start with 2 week Sprints

Factors in deciding your Sprint lengthLength of the release

Amount of uncertainty

How long priorities can stay unchanged

Overhead of Sprint Planning and Review

Team and Product Owner work together to decide Sprint length

Can change during the project

Intensity

Time

Intensity

Waterfall

Scrum

The Basics of Scrum

4-WeekSprint


Product

Product OwnerReview

ScrumMaster

The Team

789101112

1234

56

13


Commitment

Daily ScrumMeeting

Retrospective

No Changes During Sprint

No Changes to the DeliverableOnce team has committed, no changes to the deliverableIf something major comes up, Product Owner can terminate the Sprint and start new oneDetails and clarifications will emerge during Sprint, but no new work or substantially changed work

Difference between “change” and “clarification”

“If there’s any doubt, then it’s a change”

Impact of Change

Every Future SprintCurrent Sprint

Team’s sense of account-

ability to deliver what it committed to

Strength of team’s focus on delivering

what it committed to

Product Owner’s

discipline To not request

changes

Everyone’s likelihood to

play by all the other rules

Team’s ability to deliver

what it committed to

Product Owner

Satisfaction Level

What happens if the Product Owner gets to add just a smallamount of work, or swap work in & out during the Sprint?

What if the Team is Responsible for “Emergency Response” (P1 Bugs, etc.)?

Not Scrum standard! Proceed at your own risk

2 approaches that some teams use“Designated Responder”

“Bug Buffer”

Option 1: Designated Responder

“Scrum Work”(items from the

Product Backlog that the team has committed to do)

“P1 Bugs”(emergency requests

that need to beresponded toimmediately)

Option 2: Designated Responder

“Product Backlog Work”(items from the Product

Backlog that the team has committed to do)


that need to be responded to quickly)

Commits in this Sprint to complete items 1-13 on

the Product Backlog

Commits to fit P1 bugs. Maywork on items from lower on Product Backlog (items >13)

Scrum Team D.R.

Option 2: Bug Buffer

“Scrum Work”(items from the

Product Backlog that the team has committed to do)


that need to beresponded toimmediately)

“8-Hour Day”

productive time available

meetings, email, lunch, etc.


“8-Hour Day” bug buffer


meetings, email, lunch, etc.


To make this work, 3 things are requiredClear definition of what qualifies as a “P1 Bug” (these are the only things that team will work on)

Time spent from risk buffer must be tracked – when buffer gets to 0, work on bugs has to stop, or Sprint has to be terminated

Team must have the discipline to follow first two points

RisksBecomes a back door for change during the Sprint

Buffer overrun


The Basics of Scrum

4-WeekSprint


Product

Product OwnerReview

ScrumMaster

The Team

789101112

1234

56

13


Commitment

Daily ScrumMeeting

Retrospective

Daily Scrum Meeting

Every weekdayWhole team attendsEveryone standsLasts 15 minutes or lessEveryone reports 3 things only to each other

What was I able to accomplish since last meetingWhat will I try to accomplish by next meetingWhat is blocking me

No discussion, conversation until meeting endsProduct Owner can attend and reportUpdate of artifacts after standup

Table Exercise: Daily Scrum Meeting

Do a Daily Scrum Meeting for your tableOne 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 Standup Meeting

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

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

But there is a twist…

Updating the Sprint Backlog

Before or after the Daily Scrum, team members update the hours remaining on the Sprint Backlog

Updating the Sprint Backlog

8105TracyImplement back-end codeUpgrade

transaction processing

module

666JoeComplete documentation

333PhilipUnit testing


205220214Total

3

2

3

6

6

2

2

0

2

2

4

8

6

2

2

4

Initial Est.

Day of Sprint

2

3

6

6

4

2

2

1 4 5

PhilipRegression testing

PhilipUnit testing

JoeComplete documentation

TracyImplement front-end code

TracyImplement back-end code

JingDesign user interface

SanjayDesign business logic



6OwnerTaskBacklog

Item

Burndown Chart

Task Board

IN PROGRESSTO DO DONE

Task Board


Task: Configure database and SpaceIDs for Trac

Owner: Sanjay

Task Board


Owner: SanjayTime Remaining:4 hrs










Owner:` SanjayTime Remaining:4 hrs
















































Task Board




























































Task Board




























































Task Board




























































Task Board




























































Task Board




























































Task Board




























































The Basics of Scrum

4-WeekSprint


Product

Product OwnerReview

ScrumMaster

The Team

789101112

1234

56

13


Commitment

Daily ScrumMeeting

Retrospective

Sprint Review

Purpose of the Sprint Review isDemo what the team has builtGenerate feedback, which the Product Owner can incorporate in the Product Backlog

Attended by Team, Product Owner, ScrumMaster, functional managers, and any other stakeholdersA demo of what’s been built, not a presentation aboutwhat’s been built

no Powerpoints allowed!

Usually lasts 1-2 hoursFollowed by Sprint Retrospective

The Basics of Scrum

4-WeekSprint


Product

Product OwnerReview

ScrumMaster

The Team

789101112

1234

56

13


Commitment

Daily ScrumMeeting

Retrospective

Sprint Retrospective

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

What’s working and what could work better

Why does the Retrospective matter?Accelerates visibility

Accelerates action to improve

Sprint Retrospective – A Good Approach

Part 1Create 3 large lists (whiteboard or flipchart)

What’s working

What’s could work better

Things to try in the next Sprint

Go around the room, and give each person an opportunity to add 1 or more items to the 3 lists

If people agree with something already on the lists, put a tick mark next to them

Select a subset of the “Things to try...” list to try in the next Sprint (ScrumMaster responsible for tracking this)

Sprint Retrospective – A Good Approach

Part 2:

At the end of the meeting, mark each item on the What’s Working / What Could Work Better lists as either:C = caused by Scrum (would not be happening without Scrum)E = exposed by Scrum (would be there even if team were not using Scrum)U = unrelated to Scrum (like the weather)

Then, add up the C, E, and U in each column

WHAT WORKED WHAT DIDN’T WORKWe didn’t finish what we committed to in the time availableOur estimations were way offWe didn’t think through the dependencies between tasksThe coordination between developers and testers wasn’t very goodOur daily Scrum meeting didn’t start on timeThe food in the cafeteria was really badThere were a lot of outside distractions during the SprintBlocks didn’t get removed quickly enough by the ScrumMasterThere were too many bugs yet to be fixed at the end of the SprintTeam didn’t really work together as a team –still felt like a group of individuals

Team felt more focused than before on hitting its goalsSense of commitment for the team was higherTeam had a better sense of where it was in the Sprint because of the burndown chartThe Daily Scrum Meeting improved Team communication during the SprintGood idea came out during the Sprint Review

The Release Cycle in Scrum


Scrum Release Cycle

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

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

“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

Release Planning and Estimation in Scrum


Estimation and Release Planning

You can continue to use your existing estimation methods, if they’re working for you

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

However, there are Scrum-specific methods that many teams find more effective that their previous approachesEstimation in Scrum is based on what’s called Velocity

Velocity is measure of how much Product Backlog the team can complete in a given amount of time

Product Backlog

Velocity – Based on Historical Data

90 points

120 points

100 points

~105 size points per Sprint

Team’s Recent Sprints

How to Plan a Release in Scrum

Calculate velocity then apply to the Product Backlog:

Team’s velocity is~105 points per Sprint

Therefore, in 6Sprints, the team should be able to complete

This is 620 points of Product Backlog

6 x 105 = 630 points worth of Product Backlog

Velocity Calculation

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 EstimateOf Velocity atProject Start

Refinementof Estimatebased on 1 Sprint of Actual Data

Recalculationbased on 2 Sprints of Actual Data



Release Planning

Product Owners determines whether It’s a feature-driven release (“launch when features X, Y, Z can be completed”)

It’s a date-driven release (“launch on April 15 with as many features as possible”)

It’s date- and feature-driven (“launch on April 15 with features X, Y, Z”)

Creating Size Estimates

Planning Poker

1. Everyone has cards: ½, 1, 2, 3, 5, 8, 13, 20, 502. ScrumMaster reads description of backlog item3. Everyone selects and simultaneously shows

cards4. If estimates vary significantly, high and low

estimators briefly explain5. Repeat steps 3-5 until estimates stop

converging6. Decide estimate for backlog item7. Move to next backlog item

Table Exercise: Planning Poker

Use planning poker to estimate the effort for the Product Backlog.

1. Select an item that is roughly “medium” in size (2 minute timebox)

2. Write the number “5” next to that item

3. Proceed to estimate the other items relative to that one (15 minute timebox)

ScrumMasters: Facilitate as needed, and help the team keep to the timeboxes

Module: Using Scrum in a Fixed Bid Environment

Contract Terms

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 no additional charge for this.

3.1.2 Customer can replace any requirements that Vendor hasn’t 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 Customer’s business goals are satisfied early, Customer may terminate contract early for 20% of the remaining unbilled contracted amount.

Module: Using Scrum for Multi-Location Development

Scrum in an Offshore (Geographically Distributed) Environment

Is Distributed Development using Scrum even possible?

Scrum emphasizes face-to-face communication, physical proximity, minimizing documentation, cross-functional teams...Distributed development seems to attract plan-driven approach, detailed requirements and “defined” plans, separation by function (ie, analysts onshore, developers offshore, etc.)

Yes, but...Distributed Scrum is not as good as Colocated ScrumHowever, it’s still better than Distributed Waterfall

Quote

"If you are going to hire a group of developers halfway around the world in a time zone 12 hours away, how should you work with them? Should you give them a huge requirements document and wait to see what they give you in six months? Or should you ask for something every week?" When it's difficult to communicate, you need to shorten the feedback cycle and measure results frequently.”

“AgileDevelopment On a Fast Track”Global Services Magazine, Jan 2007

Distributed Scrum Practices

Structure A: Product Owner is in US, team is in IndiaOne Common Approach

ScrumMaster colocated with team in IndiaProduct Owner in US travels to India for project kickoffAll real-time meetings with Product Owner are visual

Videoconference + WebexUse 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 teamIn-person planning and review regroup in India or US between Product Owner and team at least once per quarter

Distributed Scrum Practices

2-week SprintsTeam holds daily standup meetings in own location

ScrumMaster emails blocks list to Product Owner for assistance clearing in US

Sprint PlanningTeam 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 RetrospectiveVideoconference + Webex (example Weds morning IST)

Distributed Team

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 meetingsNotes from each team’s standup emailed to the other and read at the beginning of the meeting(this is in addition to all the previous recommendations)

Human Dynamics

The quality of the human relationships and communication will significantly influence the outcome of the project. So...

Invest in the relationships

Invest in the communication

Developing Team Relationships

If relationships between remote teams are strong, disagreements,miscommunications, mistakes, etc. are just that –disagreements, miscommunications, mistakes

In other words, isolated problems to be solved, then move onIf relationships are week, these things become evidence in a “story of badness” – the other team is crazy, incompetent, evil, malicious, etc.

This is extremely difficult to repair“Spend some savings” at project inception to help people get to know each other

Plan work, but also plan play – dinners, outings, sightseeing, etc.Send US customers and project managers to India for creation of initial release plan with teamColocate key members of the team for first several sprintsRotate selected team members to different locationsEmphasize the human element – these are people, not just voices on a phone or names on email

Team wiki with photos, bios

Developing Team Relationships

One of the reasons a relationship of trust and openness are required is that remote teams need to be able to communicate honestly

Speak up, disagree, raise problems, express concern, voice dissatisfactionEstablish known hours, with as much overlap as possibleTelephone

Make sure people can pick up the phone easily; have a speakerphone in the work area with speed dial to remote developersDemand an excellent speakerphoneStart conf calls with chit chat, helps reinforce human elementTake turns picking times of calls, and be aware of time of call issues

Instant MessagingIM is useful, particular because it shows whether the person is theremay have to configure to make the status refresh more often

VideoconferencingJust seeing someone’s face can make a big different – if you don’t have professional videoconferencing equipment, buy webcams for both sides

WikisUse wikis to share as much project-related information as possible

Module: Scrum and Metrics

Scrum and Metrics

Scrum doesn’t prevent you from tracking or measuring any aspect of the development process you chooseHowever, you must be mindful of unintended consequences of measurement

Example: Individual burndown charts

Recording or reporting measurements will probably require effort

If this effort comes from team-members, it should be made visible in their task time estimates or as Backlog Items

Scrum and CMMi

Are Scrum and CMMi Compatible?

CMM Level 2 and 3 represent a process that is “defined and managed”

Is Scrum “defined and managed”?

CMM Level 4 represents the measurement of detailed metrics in the process

Does Scrum allow measurement in the process?

CMM Level 5 represents continuous improvement via metrics feedback

Is Scrum compatible with continuous improvement?

Strategies for Successful Scrum Adoption in

the Enterprise

The Big Picture

The full and complete adoption of Scrum will result in a profound transformation of an entire organizationVery few organizations are willing to change

Change is riskyChange hurtsChange requires workChange involves loss and waste

Very few organizations are able to successfully pull it off

1. Start With the Teams That Want To Do It

Scatter the seeds of Scrum widely, then watch closely where they sprout

One of the requirements for first pilots should be “everyone on the team had to be open to it working”

Skepticism is fine and healthy, but no overt resistance

2. Call It a Pilot Program

Pilots are supposed to be chaotic, uncertain, bumpy, messyKeep calling it a “pilot” as long as possiblePeople will ask “when’s the decision going to get made to officially adopt Scrum”

Wait to make that decision until there are no more teams lining up to make the changeThen ask yourself what is it about the remaining teams?

Some people will be uncomfortable, unhappy, scaredAnd is it unexpected? How many management fads have preceded Scrum?

Emphasize the common sense nature of itWe’re not “making a change”… we’re trying a new approach, and deciding whether it’s better than the old wayKen Schwaber: “We’re not really using scrum”

Some of those people will get past it, some of them won’tJust 4 months in, some of the biggest early Scrum skeptics had evolved into the greatest Scrum evangelists

Give people the room to changeAvoid battle-lines

3. Change is Scary to Many People... and Scrum is Really Scary to Some People

4. Patience is a Virtue

Err on the side of making fewer teams more successfulEvery 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 successEven the undecided will assume that an early failure is a strike against scrumOverbudget the time early teams will need to work through systemic issues

5. Find the Middle Path Philosophically

Scrum PuristsTend to be the initial instigatorsThey also tend to be the first to feel anxiety as Scrum stops being a guerrilla campaign, and becomes how the army is run

Scrum PragmatistsTend to be more effective in big organizationsAlso more prone that the purist to compromise, possibly at the expense of effectiveness

Don’t let either of them win outrightMake sure you have both!

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

It’s very easy when evangelizing scrum to set unrealistic expectations

potential benefitwork required

People know when they’re being soldPeople also pick up on respectful realism

tell them it’s hard, tell them it involves risk, and emphasize that only they in their hearts know if it might be right for their team

7. Scrum is Hard

Scrum surfaces all sorts of nasty stuffMake sure people are preparedMake sure they understand that this is Scrum working, not failing

Help teams learn from each otherBe ready to stage a rescue mission

There are some problems teams can’t solve by themselves

8. Get Experienced Help

Outside experts can help with specific practices, training, etc.

Don’t overlook perhaps their greatest help in the early days: telling you they’ve seen this a million times before, and it’s all going to be fine

And at the same time, making sure you don’t overlook and slack off on something important

9. Your Enemy is Your Friend

Spend the most time with the people who like Scrum least

Before you have momentum, Scrum detractors can have 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 Get Things Done

Some of the obstacles to Scrum are bigOrganizational, policy, management...

Many are smallconference room table

Focus on the big ones

11. Make Good Information More Accessible than Bad Information

As a Scrum rollout picks up momentum, the 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 there’s a constant flow of good information

Email updates, brown-bag lunches, staff meeting talksStart 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 company, and every levelMake sure they’re well educated on reality, and also 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 advocatewith a single statement they can set the default management attitude to scrumbeware getting them TOO excited though

13. Measure the Results Early and Often

Scrum is in part about making things visibleSo 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 ScrumImportant to set standards and adhere to them

If it isn’t scrum, don’t let people call it ScrumProtect Scrum’s good name!

15. Scrum will Always Be Messy

Scrum is about people, and people are messy

Inconsistent, insensitive, erratic, make mistakes

For this reason, it will never be perfectIdealists will always be disappointedOpponents will always have ammoJust keep asking, is it better than before

LAST

Documents

Introduction to Scrum for AGILE by Kamalakar Dandu