scrum master training [autosaved] · julya van berkel ( [email protected] ) •scrum –is not a...

Scrum Master training

Julya van Berkel

Julya van Berkel ([email protected])Julya van Berkel ([email protected])

Scrum: It’s All About Common Sense

Julya van Berkel

[email protected]

mailto:[email protected]


What are we going to show you

• What is Scrum?• History of Scrum• Theory, Concepts, practice• Sprint Planning• Production & Sprints• Sprint Review & Retrospectives• Velocity game• Management, distribution & scaling


• Scrum– Is not a method, important during the exam, Scrum is a lightweight framework

– Does not describe how to work, does have team values

– Is not about software, projects, system layers, components

– Focus on what’s important

– Is usually fun!

Wat is Scrum?


The History of Scrum1


• Agile is not new, a lot of Agile is borrowed from history.

• We won’t go back too far. Not farther than the 80’s– Origin in Object Orientation

– How did the Agile manifesto get created

– Influence from production

History of Scrum


• In 1986 Ikujiro Nonaka & Hirotaka Takeuchi published the Harvard Paper

“The New New Product Development Game”. In this white paper

knowledge management got focus again.

"a flexible, holistic product development strategy where a development

team works as a unit to reach a common goal"

The New New Product Development Game


• OOPSLA ‘95– OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) is an annual ACM

research conference

Jeff Sutherland & Ken Schwaber

http://jeffsutherland.org/oopsla/oo95wrkf.html

Scrum at OOPSLA ‘95

http://en.wikipedia.org/wiki/Object-Oriented_Programming

http://en.wikipedia.org/wiki/Association_for_Computing_Machinery

http://jeffsutherland.org/oopsla/oo95wrkf.html


• Agile is not a method– Has 4 values

– Has 12 principles

– Can still be signed

In 2001 a group of software people gathered in Utah to look at the new ways of

working that were being developed. They put together a Manifesto

Birth of Agile


Manifesto for Agile Software DevelopmentWe 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. http://agilemanifesto.org/

Agile Manifesto

http://agilemanifesto.org/


Four types of systems

• Cynefin

Dave Snowden

Planning a vacation

Having dinner together

Raising a teenager

Changing a diaperChecklist

Lean / WaterfallAgile

?

In complex systems you cannot understand the problem until you know

a part of the solution

All complex development needs

knowledge emergence


Agile, Scrum, Lean, TPS, etc


Scrum Theory, Concepts, Practice2


• Motivation and basis for Scrum and Agile

• Scrum as viable framework

• Scrum as 3 roles 5 events and 3 artifacts

• Timeboxing

• Planning

Scrum Theory, Concepts, Practice


Scrummy

• Predicting is proven tobe unreliable

• Traditional processesrely on predictions

Take the weather, can you predictwhat weather it will be tomorrow? How about, on this day next year?


Agile

• Agile lays out a vision and then nurtures project resources to do the best possible

to achieve the plan

• Agile is the “art of the possible”

• The heart of Agile is self organization

(Ken Schwaber)


How does Agile work?

• Agile employs the following practices:– Frequent inspection

– Emergence of requirements, technology, and team capabilities

– Self-organization and adaptation in response to what emerges

– Incremental emergence

– Dealing with reality, not artifacts

– Collaboration (Ken Schwaber)


• How Agile are you?

Agile exercise!


When Rosing started at Google in 2001, “we had management in engineering. And the structure was tending to tell people,

No, you can't do that.” So Google got rid of the managers. Now, most engineers work in teams of three, with project

leadership rotating among team members. If something isn't right, even if it's in a product that has already gone public,

teams fix it without asking anyone. . . .

“For a while,” Rosing says, “I had 160 direct reports. No managers. It worked because the teams knew what they had to do.

That set a cultural bit in people's heads: You are the boss. Don't wait to take the hill. Don't wait to be managed.” . . . And if you

fail, fine. On to the next idea. “There's faith here in the ability of smart, well-motivated people to do the right thing,” Rosing

says. “Anything that gets in the way of that is evil.” Fast Company. April, 2003.

An Agile story


How do we support it?

• Maximized Communication

– Effective, regular (daily!) meetings

– Collocation and true small-team dynamics

• Autonomy

• Time-boxing: give the team space and uninterrupted time to do work

• We expect the team only to do their best: it is easier to ask forgiveness than ask

permissionJim Coplien, Gertrud & Cope

G&C


Scrum as an organizational pattern

NAMED STABLEBASES TAKE NO

SMALL SLIPS COMPLETIONHEADROOM

RECOMMITMENTMEETING

WORKQUEUE

INFORMALLABOR PLAN

PROGRAMMINGEPISODE

DEVELOPER CON-TROLS PROCESS

SOMEONE ALWAYSMAKES PROGRESS

INTERRUPTSUNJAM BLOCKING

SIZE THEORGANIZATION

ENGAGECUSTOMERS

SURROGATECUSTOMER

SCENARIOSDEFINE PROBLEM

FIREWALLS

SELF SELECTINGTEAM

UNITY OFPURPOSE

TEAMPRIDE

PATRON ROLE

HOLISTICDIVERSITY

ENGAGEQUALITY

ASSURANCE

GROUPVALIDATION

COMMUNITYOF TRUST

FEW ROLES

PRODUCERROLES

PRODUCERS INTHE MIDDLE

ORGANIZATIONFOLLOWS LOCATION

SHAPING CIRCULA-TION REALMS

DISTRIBUTEWORK EVENLY

RESPONSIBILITESENGAGE

MOVERESPONSIBILITIES

3 TO 7 HELPERSPER ROLE

COUPLINGDECREASES

LATENCY

Jim Coplien, Gertrud & Cope

G&C


Scrum broken down


Scrum broken down

• 3 Roles

– Product Owner

– Developer

– Scrum Master

• 5 Events

– Sprint

– Sprint planning

– Daily Scrum

– Sprint review

– Sprint Retrospective

• 3 Artifacts

– Product Backlog

– Sprint Backlog

– Increment


Product Owner

Vision

ROI

Product BacklogShippable?

Activities:

Product Backlogexplanation/clarification

Answer question from the team about the product

Participate in Scrum events:

•Sprint Planning•Sprint Review•Retrospective


Product Owner

• The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:– Clearly expressing Product Backlog items;– Ordering the items in the Product Backlog to best achieve goals and missions;– Optimizing the value of the work the Development Team performs;– Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what

the Scrum Team will work on next; and,– Ensuring the Development Team understands items in the Product Backlog to the level needed.

• Manages ROI vs. investment-vision• Manages the Product Backlog• Decided if a release is “shippable”• Often there is a Product Owner Team working for a Chief Product Owner• The development team, Scrum Master and Product Owner are called the “Scrum Team”


The Development Team

• Cross-functional

• Stable over time

• Selects and develops highest items on Product Backlog

• Splits up work into easily estimated, small tasks

• Manages the development iteration to its forecast

• Develops the product in time-boxed intervals called SprintsJim Coplien, Gertrud & Cope

G&C


Chickens and Pigs


More precisely...

• The Scrum Team consists of the Scrum Master, the Product Owner, and the Development Team.

• Scrum Developers are called “pigs.”

• The Product Owner is the “pig” of the Product Backlog.

• The Development Team is the “pig” of the Sprint work.

• The Scrum Master is the “pig” of the Scrum process.

• Everyone else is a “chicken.”


The Scrum Master

• Sustains culture and environment to optimize ROI

• Organizes Sprint Planning Meeting

• Calls the Sprint Review Meeting

• Usually facilitate brief daily Scrum meetings

• Shields the team from outside disturbances

• Removes obstacles to progress

• May not direct the team nor tell them what to do


Customer

• There is no Customer in Scrum:

the Product Owner speaks for all stakeholders

• Customers are common in software

• End users are even more important,

given a true Agile focus

• Customers are a handoff; it is better to work in partnerships


Basic Scrum Flow

Sprint

Sprint Planning

Sprint Backlog

Product Backlog

Product VisionMarket researchWish listRequirements

Increment

Daily Scrum

Sprint Review

Retrospective


Time Boxing

• Time for the Development Team to work undisturbed• Establishes team rhythms• The Sprint is the main unit of time boxing• A Sprint represents a Development Team forecast• During a Sprint,– delivery scope (PBIs) cannot change– there may be no new external requirements

• Keeps feedback loops tight


Sprint Planning3


Sprint PlanningThe first event

• Meeting to produce the initial Product Backlog and update it over time

• All stakeholders present: Product Owner, Scrum Master, the Development

Team, maybe other stakeholders

• The Product Owner runs the meeting; the Scrum Master

makes sure the meeting happens

• Topic 1: work on the Product Backlog

• Topic 2: work on the Work Plan


Sprint Planning & Backlog refinementTopic 1

• Most of the backlog should be prepared before the Sprint Planning

meeting– An unprepared backlog makes for terrible

meetings, demotivates and slows down the team

• Prepare PBIs weekly in Backlog Refinement

• Sprint Planning Topic 2 focuses on the work plan


Sprint Planning Meeting

• 1 Day

• A little time to break down the Product Backlog

• 1 - 4 hours for team to define Sprint Backlog

• Anyone can attend, but primary conversation and work is between the Development Team and the Product Owner Jim Coplien, Gertrud & Cope

G&C


Sprint Planning

• Ideally, Topic I is an abbreviated Backlog Refinement meeting

• Have team allocate 5% of their Sprint time for this activity, which

should be compartmentalized to minimize interruption, and

• Never allow the Product Owner to go into the Sprint Planning

meeting with an inadequate Product Backlog — otherwise, go

to the beach / sauna!


Sprint planning (Topic 1)• Ideally, the backlog has already been refined and is largely Ready, modulo a few new

or shifted PBIs

• The Product Owner presents the Product Backlog for the next Sprint or so

• The team estimates any unestimated PBIs

• In the top two Sprints of work in the backlog, the Scrum Team breaks down large PBIs so that no PBI is larger than a week for one person

• The Product Owner re-orders the Product Backlog as appropriate

CSPO Training Jim Coplien


Sprint planning (Topic 2)• The Development Team does high-level design, making a development plan

for PBIs

• The work is assembled into a Sprint Backlog, owned by the development team

• The developers estimate the work and sizes the Sprint Backlog to exactly one Sprint of work

• The developers forecast the estimated delivery to the Product Owner


Refinement meetingEvery week during the sprint

• Schedule weekly Product Backlog Meetings

• Allows Feature Analysis and Release Planning updates more frequently than once

per Sprint

• Can make the Sprint planning meeting (Topic I) a no-brainer

• The Product Owner presents a Product Backlog of enabling specifications

• The Development Team estimates new PBI items

• Re-evaluate ordering of top three Sprints of Product Backlog every Sprint and reorder


De Product OwnerOne person!

Can be Chief PO

Maximise ROI!

Answer Questions!

Acquires product funds

Decides if PBI is releasable

Makes sure there is:• One set requirements for development• No confusion due to multiple bosses, differences or opinion or external disturbances


The Product OwnerSingle wrenchable neck of ROI

• Develops and maintains the Product Backlog

• Orders the Product Backlog

• Empowered to make decisions for all stakeholders and users

• Attends Sprint planning meetings and Sprint review meetings

• Presents and explains Product Backlog to the team

• Manages the vision, ROI, and releases Jim Coplien, Gertrud & Cope

G&C


Product Ownero Act as a Project Manager

o Demotivate the team

- it’s all about trust

o Tell what and when

something must be

done

o Talk at the daily Scrum

(if very experienced)

o Clarify issues

o Deliver the latest business value

o Inspire the team value

o Initiate the Emergency Procedure

(and terminate a Sprint in an emergency)


G&C


The Product Backlog

• List of functionality, technology, issues

• Top three sprints are Enabling Specifications

• Issues are placeholders that are later defined as work

• Emergent, ordered, estimated

• More detail on highest backlog items

• One list for multiple Development Teams

• Product Owner responsible for ordering

• Any stakeholder can contribute

• Maintained and posted visiblyJim Coplien, Gertrud & Cope

G&C


Product Backlog - Balanced

Items too big? Too many Items? Balanced

There are enough detailed, estimated and reviewed features to cover next 2-3 sprints

Features for later stages are listed, but less granular and proposed

In A Balanced Product Backlog:


G&C


Planning Poker

• The Delphi technique brought up-to-date

• Visibility of differences

• Drive to consensus

• Breaks down linear thinking


Why Planning Poker

• It ensures everybody participates in the estimation

• It avoids 'coloring' of the estimates by a few key members of the team

• It speeds up the estimation process

• It’s pigs, not chickens

• It is fun!Jim Coplien, Gertrud & Cope

G&C


Estimation points

• How far is it from here to Berlin?

• How far is it from here to Paris?

• Given the answers to these previous questions, can you answer:– How long will it take by car?

– How long will it take on foot?


Velocity

• Velocity is per Sprint

• For the team this is input that they can use to predict

• The previous sprint I got from A to B

• This sprint we’re likely to get from B to C (Yesterday’s weather)

Product Backlog

A

B

C

Best Practice


Rules of the game

• Everyone gets a set of cards• Discuss one PBI at a time• PO answers any questions• Everyone individually selects a card that represents their estimate• All cards are shown at the same time• Highest and lowest estimators provide an argumentation• Discuss the arguments• New round of estimation• Continue until consensus• Write down the estimation on the Product Backlog at the PBI

Best Practice



2

Scrum master

Product owner

Team

Argumentation

As user I want to log on sothat I can access my data

Planningpoker Best Practice

8 5

20


2nd time5

Planningpoker Best Practice

3

Scrum master

Product owner

Team

As user I want to log on sothat I can access my data

5 3

5

5


Planning Poker Tips• Baseline? Team finds the item with the smallest effort/complexity this is

• Very large estimates? Sign to break up the PBI

• Discussion of arguments takes too long? Timebox it, 10 sec!

• Planning Poker, best with the whole team

• Make sure the Product Backlog is ordered, – Prevent waste of time on unimportant items

• No card in the Fibonacci set between estimations, choose the highest!

Best Practice


G&C


Exercise: Kitchen Remodeling

• Install new hardwood floor• Refinish (remove, sand, repaint) the cabinets• Install granite countertop instead of tile• Repaint entire kitchen• Lay shelf paper• Install recessed lighting• Replace electric stove• Install built-in refrigerator• Install a new oven• Plumb the island and add sink• Replace simple window with a bay window (exercise by Mike Cohn)

End


Production en Sprints4


Production en Sprints

• The Scrum Master• The Sprint Goal• Backlog Refinement Meeting• Scrum Boards• The Daily Scrum• Burndown Charts and Velocity• “Done”• Sprint Signatures• Surprises and Emergency Procedure


Scrum Master Role

Servant Leader and Facilitator:

• Removing the barriers between development and the

Product Owner so the product owner directly drives development

• Teaching the Product Owners how to maximize ROI and meet

their objectives through Scrum

• Improving the lives of the development team by facilitating creativity and empowerment

• Improving the effectiveness of the development team in any way possible, and

• Improving the engineering practices and tools so each increment of functionality is

potentially shippable


Impediment list

• The Scrum Master’s Product Backlog

• Updated daily

• Open, visible, and honest

• Team should first try to solve its own impediments: Scrum Masters should

push back

• Scrum Master takes ownership of impediments that the team can’t solve

• Management is the last level of escalation

Best Practice


Why the Scrum Master?

• Scrum makes problems visible

• Project managers too often help hide problems

• Scrum Masters help keep problems visible

• Resolving problems relieves stress on the team

• The team gets better and better


ScrumMaster Etiquette

• Do what it takes, but...

• A dead Scrum Master is a useless Scrum Master

• The team hires and fires the Scrum Master

• Powerless, except:– May remove a disruptive person from the team


Single Wrenchable Neck

Responsibilities

• The Scrum Master is the single point of accountability

for the Development Team’s Sprint delivery

• The Product Owner is the single point of accountability

for the company’s ROI


The Sprint Goal

• The focus of the Sprint

• If the Team finds it can’t deliver its forecast,

the Sprint Goal is a guiding light and fallback position

• Helps the Team adjust quickly in emergency

• Agreed by the PO and the Developers, and the Developers commit to it

• Usually derived from the Vision

• Examples: “these two PBIs,” increased value per estimation point, decrease bug

incidence


De Sprint Backlog

Sprint 1

Sprint 2

Sprint 3

Sprint 4-6

Planning Discussion


The Scrum Board

www.scrumtrain.com

IN PROGRESSTO DO DONETask: Configure database and SpaceIDs for Trac

Owner: SanjayTime Remaining:4 hrs

Task: Configure database and SpaceIDs for Trac









Owner:` SanjayTime Remaining:4 hrs















































PBI #1

PBI #2

PBI #3Original slide:Pete Deemer, Yahoo!

Best Practice




































































































































































































































































































Example Scrum BoardBest Practice


Daily Scrum


• What did I do yesterday that helped the Development Team meet the Sprint Goal?

• What will I do today to help the Development Team meet the Sprint Goal?

• Do I see any impediment that prevents

me or the Development Team from

meeting the Sprint Goal?

Three Answers


Rules of the Game

• Same Place and Time Every Day• One minute at most per Developer

– Stand up!

• Focus is on visibility — not problem solving– Solve problems off-line

• Complete honesty, openness, and visibility

• Personal impediments are legitimate impediments– The whole team supports the whole person

Best Practice


G&C


Burn-down Charts

• It is stupid to track time consumed doing a task– Time records are a waste of time– You want to focus on achieving the end date– We (actively) track time remaining

• Burndown Charts are the central Scrum project management tool– The focus is on delivery– Cost management comes from estimation

• The slope of the burndown chart is called the team’s velocity• Scrum mandates visibility, but the team can use a tool other

than a burn-down chart

Best Practice


G&C


Example Burndown Chart Best Practice


G&C


Example Burndown Chart

Likely Backlog Trend

0

500

1000

1500

2000

2500

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32Time

Best Practice


G&C


Example Burndown Chart Best Practice


Reduction of velocity

• The slope of the burndown chart represents the Velocity

• Velocity is per sprint, though the result is based on workable hours

• Additional hours taken away from work reduce the velocity

• What do you do with:o Vacation?

o Pregnancy leave?

o Team-building activities?

o Scrum certification courses?

Best Practice

These items go onto theproduct backlog!


G&C


Potentially Shippable Increment

• Each and EVERY Sprint delivers a potentially shippable increment

• “Potentially shippable” means that the Product Owner may decide

to ship it; the team has no say in that decision

• Only DONE functionality may be delivered at the end of the Sprint;

the team must list the incompleted parts of their forecast,

if any


G&C


Done

• What “Done” means has to be determined by the Scrum Team

• By definition, a task or PBI is “Done” when there is no known remaining work

• “Done” : we can show it to the product owner

• The Product Owner can decide to Ship the Product

• The definition of done is best defined on a Development group level


G&C


Extending the Scope of Done

The definition of done will eventually contain ALL development

PlanningAnalysis

Architecture, Infrastructure

CodingDesign

TestingPerformance

User Acceptance

PilotLive

Best Practice


G&C


Tools to support Done

• Version control

• Automatic builds

• Automatic testing

• QA Environments

• Anything you cannot reasonably do manually anymore!

... But there are no universal silver bullets or golden hammers

Best Practice


G&C


Technical Debt

• Done = “no known remaining work”

• What if a project manager forces the project to finish by making the

development team ignore tasks like:– refactoring

– documentation

• This work will increase when time moves on

• It usually is invisible!

Best Practice


G&C


Technical Debt

• Happens when you don’t do something that you should have done at that

moment — Tom Flynn, Sungard

March, 2009

Best Practice



Technical Debt

} hidden Technical Debt

0200400600800

20 15 10 5 0 } More Debt!

Best Practice


G&C


Eventually...

0200400600800

1.000

20 15 10 5 0

0200400600800

1.000

20 15 10 5 0

0200400600800

1.000

20 15 10 5 0

Best Practice7


G&C


Surprises

• New customer requirements happen• Scrum says: Put them on the product backlog for consideration at the next Sprint Planning

• Sometimes, they can’t wait even for the meeting• Scrum says: Never extend the Sprint or change priorities

• So: can the team do a new work item?

• The team gets to decide!• The team may choose to do the feature while still keeping its forecast

• If it cannot keep its forecast, it should not choose the feature

• In that case, it becomes the Product Owner’s problem


G&C


Emergency Procedure

1. Do something different

2. Get help from outside the team

3. Reduce Scope

4. Abort the sprint


G&C


Aborting the Sprint• What happens when...

– you foresee a disastrous schedule slip?

– business conditions change radically?

• You can’t stretch a Sprint — short slips are death by a thousand cuts

• There is no sense in driving the team to a point of foreseen failure

• Therefore: Stop the Sprint

– The equivalent of the Andon cord

– Only the Product Owner may abort the Sprint

never the developers or the ScrumMaster!!!


G&C


The Abort-The-Sprint Meeting• Hold the Abnormal Termination of Sprint ceremony.

Conduct it in the main lobby of corporate headquarters by:1. All team members gather. 2. They lie on the floor, on their backs, forming a circle with their feet (pointing up)

in the center, touching one another’s feet. 3. Upon command, they unloose their emotions about having their hard work

jerked around by unknown forces that view chaos as better than productivity. 4. When it is all out (usually within 15 minutes), the team members can get up and go back to something.

• The point is that people aren’t resources, and they definitely have opinions and feelings about having their forecasts abrogated by outside forces.

Ken Schwaber – March 6, 2008

Best Practice



G&C


Illigitemus Non Interruptus• Therefore, allot time for interrupts and do not allow the time to be exceeded.

• Set up three simple rules that will cause the company to self-organize to avoid disrupting production.

1. The team creates a buffer for unexpected items based on historical data. For example, 30% of the team's work on

the average is caused by unplanned work coming into the sprint unexpectedly. If the team velocity averages 60

points, 20 points will be reserved for the interrupt buffer.

2. All requests must go through the Product Owner for triage. The Product Owner will give some items low priority if

there is no perceived value relative to the business plan. Many other items will be pushed to subsequent Sprints

even if they have immediate value. A few items are critical and must be done in the current Sprint, so they are put into

the interrupt buffer by the Product Owner.

3. If the buffer starts to overflow, i.e. the Product Owner puts one point more than 20 points into the Sprint, the team

must automatically abort, the Sprint must be replanned, and management is notified that dates will slip.

Pattern

Pattern by Jeff Sutherland (ScrumPLoP

https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/product-owner


Sprint Review and Retrospectives5


Sprint Review and Retrospectives

• Why?– Show that the basic architecture and infrastructure work

– Get feedback on results

– Easier to estimate when you have proven that it works

– Keep the product owner interested


G&C


Sprint Review Meeting


G&C

• 4 hours for Sprint of 4 week

• Maximum 30-minute prep time, 1 hour presentation / No PowerPoint®

• Done on equipment where software was developed and tested

• Presented by Team to Product Owner and stakeholders/customers/users

• Basis for planning next Sprint

• Must represent potentially shippable increment of product functionality


Sprint Review subjects

• "are we happy with the overall result so far?"• the PBIs not completed (if any)• the Velocity, Release Plan and Product Roadmap• key learnings (on product)• status of bugs and builds; brief discussion of technical debt• new PBIs identified• actions/decisions arising from the Sprint Review


G&C


What does the Scrum Guide say about the Sprint Review The Sprint Review includes the following elements:

• Attendees include the Scrum Team and key stakeholders invited by the Product Owner;

• The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;

• The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;

• The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;

• The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress todate (if needed);

• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;

• Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,

• Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated release of the product.

• The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product

Backlog may also be adjusted overall to meet new opportunities.


Retrospective

• A brainstorming session– What are your impediments?

– Make an impediment list

– Order it

• Timebox 3 hours for a 4 week sprint Jim Coplien, Gertrud & Cope

G&C


Dysfunctional?


G&C


Review: De Impediment List

• The Scrum Master’s Product Backlog

• The goal: An effective, happy Team

• Updated at every daily Scrum

• Priority-ordered periodically

• Shared in Scrum of Scrums

• Open, visible, and honest Jim Coplien, Gertrud & Cope

G&C


Check-ups en Retrospectives

• The Scrum framework has process improvement

• Scrum is a process improvement, and it depends on feedback and introspection

• A check-up can be done at the end of a Sprint to address surface process issues

• A retrospective can be done once every few months to address issues of structure

• Both of these build on trust and build trust


G&C


Summary for Process improvement

• Inspect and adapt

• Leverage self-organization

• Don’t get religious: give and receive trust

• Do what it takes

• Take it seriously, but don’t be seriousJim Coplien, Gertrud & Cope

G&C


Exercise: Brainstorm your own impediments

• Does your Scrum Master / do you have an impediments list?

• We can review or add to it now!


G&C


Values of Scrum

• Commitment

• Courage

• Focus

• Openness

• Respect


Algemene Review


What did we do so far?

• What is Scrum?• History of Scrum• Theory, Concepts, practice• Sprint Planning• Production & Sprints• Sprint Review & Retrospectives• Velocity game• Management, distribution & scaling


Velocity game6


5. Velocity Game

• Similar to the XP game– Three Sprints

• Change hats three times per Sprint– Developers: estimate– Product owners: Order based on business

value and estimate– Developers: execute

• Velocity (1-6, impossible - time)– Find easiest one and give number 2– Estimate the rest relative to that one

- Think about time: it may seem simple but be timeconsuming

• There will be three iterations (sprints), each of 3 minutes– We only count time while you execute the story (like football or ice hockey)

• YOU ONLY DO ONE PBI AT A TIME (all together)


G&C


Velocity Game

• Short introduction to Scrum

• Iteration 1– Estimate (5 minutes)

– Plan (5 minutes)

– Implement (15 minutes—3 real minutes)

• Debrief first iteration• Second iteration

• Third iteration

• Debrief & Celebrate Winning Team

Einde

Einde


G&C


Velocity Game: Details

• Sand clocks are set “Time” down for start– Look at PBI and do short planning– Turn clock “Time” up and start execution– Stop the clock (turn horizontally) when you are done

• You have prototype of hat and boat• If story is about finding missing cards, call instructor

who will take cards out of the deck before execution of story.• There are three strings (40cm, 60cm, and 80cm).• For “add 40 numbers,” write out sums• How many cards can you do in three minutes?• Sum up estimation points of these cards


G&C


Team Estimate 1 2 3 €


Scaling Agile


Scaling

• Scaling usually happens like you normally do:

“divide and conquer” with overlap

Initial Product Backlog• Functional requirement

• Non-functional requirements

• In steps, scalability in requirements

• Remaining functional & non-functionalrequirements

Product Backlog• Functional requirement

• Non-functional requirements

Single Team

Many Teams


G&C


Multiple development teams: Scrum of Scrums

Coordination:Scrum of Scrums

9:00 AM9:15 AM

9:15 AM9:30 AM

9:15 AM9:30 AM

9:45 AM10:00 AM

Sprint 1

Sprint 2

Sprint 3

1. Synchronise within teams2. Synchronise over teams


G&C


In a multi-team Scrum...

• Who attends the Sprint planning meeting?

• Everyone?– maybe

• Is this hard?

Yes• Decreases the velocity by about 40%

• Nurture cross-team communication!Jim Coplien, Gertrud & Cope

G&C


Organizational Structure


G&C


Organisational StructureArchitectureTeam Test Team


G&C


Example from Spotify

• Guilds cross over in other teams, product groups, organisational parts


Meta-Scrum

• When the line management team

itself runs as a Scrum

• Leverages Scrum across the entire

enterprise

ArchitectureGroup

MetaScrum

Test Group Other Group

Scrum of Scrums Jim Coplien, Gertrud & Cope

G&C


Distribution

• A distributed team is not a team!

Type Chance on Regular Communication

Single Project, integrated location 0,95

Single Project, Distributed 0,23Multiple dependent teams,

distributed 0,002Jim Coplien, Gertrud & Cope

G&C


Distributing Scrum: Guidelines

• Teams do not spread across geographic locations

• Teams are always 10 people or less and are colocated,

working on a common goal

• Scrum of Scrums need not be daily, but they must be regular


G&C


9. Summary“If you want to build a ship, don’t drum up the men to gather

wood, divide the work and give orders. Instead, teach them to

yearn for the vast and endless sea.” — Antoine de Saint-Exupery

scrum master training [autosaved] · julya van berkel ( [email protected] ) •scrum –is not a...

Documents