Scaled ScrumDeepak T Gururaja

CSP, CSM

Agenda

Scaling Scrum

What, When and How

Sharing of Best Practices

Before we begin

What is the recommended team size in

Scrum

What if there is a need to scale to a larger

number

If it’s a single large team - administrative

issues creep up

Team of Teams a.k.a SOS

Scrum of Scrums

More than one team working on

delivering the same product

Each team have Scrum roles within

Each team is responsible for one unit of

the product

When should you use it

Typically with 2 or more Scrum teams

Teams working on the same backlog

Co-located or distributed teams

Total size typically less than 50

Fairly complex project/product

Companies that cannot afford to use the

SAFe framework

Lets look more closely

PSI

Integrate

Sprint Fundamentals

Sprint Planning

Dependencies

Prioritization

Estimation

Plan with dependencies in sight

Standup calls

At a Team

SOS

Sprint Fundamentals

Reviews

Team – Do you see a value add?

For the user story/product

Retrospectives

For the team

For the product

For the release

Scrum Fundamentals Sprint backlog

For the team

Burndown

Team

Product

Task Board

Team

Product – User story completion

Metrics

For the team

For the product

Drawing the line

Horizontal slicing v/s vertical slicing

Separation at module

Separation at feature set

Separation at plugins

Who do you think are the best people to

figure out where to draw the line?

So, how to you collaborate

Sync up call – SOS

Gives a pulse of the product as a whole

Typically conducted once or twice a

week for a duration of 15 minutes and

treated like a standup call

If there is a need for further

elaboration/discussion, talk offline

Mandate presence from all teams

The Scrum Of Scrum

Ok… what do you discuss?

What did the team do between the last

meeting and now?

What will the team do between now and

the next meeting?

Is there anything that is getting in the way

of your team?

Are you going to work on anything that

will impact other teams?

Who should attend the SOS

Scrum Masters

Team members representing the

technical area

Product management, if the need be

Product managers

Stakeholders are not typically a part of

the SOS

Best practices

Plan together – deliver together

Same length iterations

Better to have same product owner or

someone who can take responsibility of

the product release

Work off the same product backlog

Backlog grooming to identify

dependencies

Shared product Vision

Visual flow at the product level

What about Our practices?

DOD?

For the user story

Not for the team, but for the product

DOR?

Dependencies considered?

For the user stories, not for the team

Workflow

Independent to the team

What about Engineering

practices?

Donot forget the basics – Clean code, unit testing, code reviews, etc

Continuous integration eliminates risk to a large extent

Have regular technical checkpoints

Always work off the same code base

Think about weather or not you want to keep the “master” clean

Setting stringent coding standards brings more benefits than you can imagine

Pros

Light weight

Easy to implement

Does not require sophisticated structure

Is not intensive

No patents or certifications yet

Cons

Structure not defined

Cannot be scalable beyond a certain

number of teams

No definite methods defined

No dedicated roles

Think about….