certified scrummaster® (csm) - wisecrum

Copyright Wisecrum Associates, LLC, 20191

Certified ScrumMaster® (CSM)Rick Waters, CST


Certified ScrumMaster® Workshop

Certified Scrum Trainer®Rick Waters, CST®

Rick has been practicing Agile software development since the late 1990’s. His move into Agile leadership roles was made out the necessity to retain his sanity, in a world of command and control managers. Discovering that he gravitated to processes built on Empiricism, Rick found that Scrum and Kanban resonated with his sensibilities.

Rick has been teaching Agile Principles and Values, and how they are used in Scrum and Kanban, professionally since 2012. When Rick is not training, he is coaching Agile teams. Since 2010, Rick has coached more than 90 teams, participated in over 700 Sprints, and helped teams move from deploying once per year, to once per week.

This workshop will focus on single-team Scrum, as defined by the Scrum Guide, authored by the inventors of Scrum—Ken Schwaber & Jeff Sutherland. This class is not focused on scaling Scrum, scaled Agility, or what electronic tools you should use to sub-optimize your Agility efforts. If you have questions pertaining to tools or scaling, please seek your trainer’s attention during breaks or after class.

If you have Scrum-related questions, don’t wait for a Q&A session, we won’t have one. Ask your question when it’s still fresh on your mind. It’s possible you aren’t the only person with the same question.

Rick’s Email: [email protected]’s Twitter Handle: @AgileWatersRick’s LinkedIn Profile: https://www.linkedin.com/in/agilerick/Wisecrum Website: http://wisecrum.com/For Veterans Needing Training: http//Scrum.vet


CSM Workbook Table of ContentsCertification Paths..........................................................Class StructureTeam Working Agreements............................................Agile ManifestoAgile Principles..............................................................EmpiricismScrum Values.................................................................Scrum OverviewSprint Backlog................................................................Sprint & Sprint GoalSprint Planning..............................................................Daily ScrumSprint Review.................................................................IncrementScrumMaster..................................................................Role Responsibilities - Scrum Team Bill of RightsDevelopers.....................................................................Product OwnerSprint Retrospective.......................................................Product BacklogProduct Backlog Refinement..........................................Definitions of Ready & Done Reference Materials ......................................................

4567

89

1011121315161921243133343539414446


Certification Paths

Where you go from here is completely up to you. Consider your true career goals, and focus your efforts there. If further and continued certification is for you, consider staying on the path that defines your role, before seeking certifications outside your role.

However, since you are in a Scrum Master certification workshop, and knowing that mastering Scrum is important, also consider certifications for all Scrum roles.

A-CSM® and A-CSPO®, as well as CSP-SM® and CSP-PO®, certification workshops of 2 or 3 days are available from very competent and accomplished trainers. There are also online and face-to-face mentorship alternatives to achieving these certifications. Weigh your needs and your time commitment possibilities when selecting the avenue toward these certifications.

Be advised, the need for bona-fide Agile Coaches is growing daily, and the path to certification as a Scrum Alliance Certified Coach (CEC & CTC) is your best option in terms of proving your experience and acceptance in the industry.


Class StructureThis class is obviously being delivered virtually, but that is no reason to not participate. Your participation will determine whether you end up fully understanding the materials, or not.

We will be using Mural and Zoom to communicate and collaborate.

The class has a set agenda, but we can stray from that agenda, slightly, if students want to explore a certain topic more deeply. What this means, though, is that we may not be able to focus much on other topics. Your trainer is very experienced in making these types of adjustments, so please don’t worry.

Here is how the class usually breaks down...

Agile ManifestoAbout 1 hour

Class Ground Rules & IntroductionsAbout 20 to 30 mins

Empiricism & Scrum TheoryAbout 20 to 30 mins

Team Working AgreementsAbout 30 mins

Scrum Deep Dive - A DrawingAbout 60 to 90 mins

Scrum Team Rights and ResponsibilitiesAbout 30 to 40 mins

Definition of a Good ScrumMasterAbout 45 mins

The Scrum TeamAbout 45 mins

Product Backlog Refinement - DiscussionAbout 20 to 30 mins

DoR & DoDAbout 45 to 60 mins

The RetrospectiveAbout 90 mins

Scrum Recap - You Teach Me Scrum!About 45 mins

Trust & Safety - CoachingAbout 20 mins

I know the times, here, don’t look like they add up to 16 hours of class, but they do. Inevitably, we will have lengthy conversations/discussions about some of these topics that make the times stretch. This is what makes this class so interesting!


Team Working Agreements

How can you help your team(s) create Team Working Agreements?

A social contract that teams create, collaboratively, to express team norms, expectations, and behaviors.

When is a bad time to modify a Team Working Agreement?

When is a good time to modify a Team Working Agreement?

When is a good time to create a Team Working Agreement?


Agile Manifesto

At the Snowbird Ski Resort in Utah, in February of 2001, 17 gentlemen from the Software Development, Organizational Design and Management Consulting industries gathered together to discuss the current and foreseen future states of their combined industry. They concluded that what they were engaged in was all intertwined so much, that a collective understanding of the future was called for. They created the...

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:

Individuals and Interactions OVER

OVER

OVER

OVER

Working Software

Customer Collaboration

Responding to Change

Processes and Tools

Comprehensive Documentation

Contract Negotiation

Following a Plan

That is, while there is value in the items on the right,we value the items on the left more.


The Agile Principles

1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable

software2Welcome changing requirements,

even late in development. Agile processes harness change for the

customer’s competitive advantage

3Deliver working software

frequently, from a couple of weeks to a couple of months,

with a preference to the shorter timescale.

4 Business people and developers must work together daily throughout the project.

5Build projects around motivated

individuals. Give them the environment and support they

need, and trust them to get the job done.

6 The most efficient and effective method of conveying information

to and within a development team is face-to-face conversation.

7 Working software is the primary measure of progress. 8

Agile processes promote sustainable development. The

sponsors, developers, and users should be able to maintain a

constant pace indefinitely.

9 Continuous attention to technical excellence and good design

enhances agility. 10 Simplicity--the art of maximizing the amount of work

not done--is essential.

11The best architectures,

requirements, and designs emerge from self-organizing

teams.

12At regular intervals, the team

reflects on how to become more effective, then tunes and adjusts

its behavior accordingly.


Empirical vs Defined Process ControlEmpiricism

[em-peer-uh-siz-uhm]

noun1. empirical method or practice2. Philosophy. The doctrine that all knowledge is derived from sense experience

• All changes based on analysis of data• Process improvement is a key element• All change is easily traced back to experiences in the system• Iterative / Incremental• Scientific

Defined Process

A process with a well-defined set of steps. Given the same inputs, a defined process should produce the same output every time.

• Few changes introduces into the system• Repetitive / Continuous• Processes based on ‘Best Practices• Alarms raised when productivity drops• Changes introduced slowly, after catastrophic failures• Existential


Scrum O

verview


Sprint Backlog

The Sprint Backlog basically contains 3 sets of things (and one optional thing)1. The Sprint Goal negotiated in Sprint Planning Part 1 (“The Why”)2. The PBI’s selected during Sprint Planning Part 2 (“The What”)3. A plan to meet the Sprint Goal from Sprint Planning Part 3 (“The How”)4. An improvement item from the previous Sprint’s Retrospective (This is

now an optional item on the Sprint Backlog)

The Developers own the Sprint Backlog, and can change it (add items, remove items, change items) as much as they see fit. BUT, they must not change the

Sprint Goal.

The Sprint Backlog remains a transparent Scrum Artifact, even though only the Developers are allowed to manipulate it. The Sprint Backlog should be accessible by anyone who would like to check in on how the Sprint is going.

This artifact serves as a Status Report for those who still believe they need such things.


Sprint

sprint/sprint/verb - run at full speed over a short distancenoun - an act or short spell of running at full speed

The Sprint is a timeboxed container event for everything in Scrum. No work is done outside of a Sprint, so when one Sprint concludes, the next immediately begins. The Sprint is a fixed length, and it is suggested that all

Sprints, for a single team, are of the same length - to aid in planning Empirically.

The Product Owner is the only person allowed to cancel the Sprint.

The only legitimate reason for canceling a Sprint, is because the Sprint Goal has become obsolete.


Sprint Planning - The Goal

• The Sprint Goal sets the ‘vision’ for a single Sprint• Each Sprint’s Goal should be unique & independent. A Sprint Goal can be related to previous Sprint

Goals, but they should not be extended from one Sprint to another.• Sprint Goals describe a desired set of features, or functions, that will work together with previous

Increments. • Sprint Goals are NOT a collection of PBI’s (“Let’s do the top 10 PBI’s on the Product Backlog.”)

Example Sprint GoalWrite a few Sprint Goal examples below

•

•

•


Sprint Planning

Who goes to Sprint Planning?

How long does it last?

Where should you hold Sprint Planning?

How often should you do Sprint Planning?

When during the Sprint should you do Sprint Planning?

Why should Scrum Teams do Sprint Planning?


Daily Scrum

The Daily Scrum has gone by many names: “The Daily Meeting”, “Huddle”, “The Scrum”, “The Standup”. But, officially it is called The Daily Scrum.

The Daily Scrum is used by Developers on a Scrum Team, to update each other on what has happened in the last day’s worth of work, and to plan out the next day’s worth of work.

This is NOT a status meeting.This is not a meeting for management.

This is not a meeting for the ScrumMaster.This is not a meeting for the Product Owner.

Mature, intelligent adults do not need someone (ScrumMaster) to call their name, and prompt them on what to say. Often in the past, ScrumMasters have done this, but a self-organizing team does not

need this minute level of facilitation.

The 3 Questions are not needed for mature teams. They were a crutch, originally intended for young teams to help them get to the valuable team discussion that needs to take place during the

Daily Scrum. Once the team has begun to mature, they should not need the crutches anymore.


Daily Scrum

What it IS

• For the _______• By the _______• Used for ___________• _________, Concise, Informative• A specific time & place for the team to align on what has been

completed, and what should be done next• An opportunity team members to ask for __________• An opportunity to react to any ____________ since the team met last

• For anyone in ________________• A _______ meeting• _________, drawn out, wordy• A time for others to assign work

to the team

• A complaint session• Optional• The ScrumMaster’s responsibility• A time to update JIRA, Rally, or

VersionOne

What it is NOT


Daily Scrum

Who MUST be at the Daily Scrum?


Where should you hold the Daily Scrum?

How often should you do Daily Scrum?

When during the day should you do the Daily Scrum?

Why should Scrum Teams do the Daily Scrum?


Sprint Review

The Sprint Review is the Scrum Team’s opportunity to review the Increment AND the Sprint with Stakeholders

The Sprint Review is not a demo to the Product Owner for their acceptance. This should have happened already.

• Arguably Most Important—FEEDBACK! Collaborate on what’s next for the Scrum Team

• Team demonstrates a “Done, usable, releasable Increment”• Budget, release timeline, product’s viability, etc. Everything is up for discussion• If you want a deep discussion, pass out Sharpies and index cards to stakeholders,

and they can pass them in after each demo. The event facilitator can then have the Scrum Team start addressing topics for discussion.

How does that differ from how you’ve seen Sprint Reviews used at your organization?


Sprint Review

Who should be at the Sprint Review?


Where should you hold the Sprint Review?

How often should you do Sprint Review?

When during the Sprint should you hold the Sprint Review?

Why should Scrum Teams hold the Sprint Review?


The Increment

+ =

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.

Work cannot be considered part of an Increment unless it meets the Definition of Done.

- The Scrum Guide, November, 2020


The Increment

Iteration #1: Make a snowball Iteration #2: Add more snow to it

That’s your process - each iteration, you evenly add more snow to the snowball

Each Iteration, the snowball gets bigger, but it’s still a snowball

When the snowball is big enough, you start another snowball

When the second snowball is big enough, you add it to the first - you integrate it with the first snowball


The Increment

Repeat this process again, make a giant snowball, and integrate it with the first two snowballs

What you have now may be recognizable as a snowman, but is it finished?

If your product isn’t done, but it could be ‘released’ to the public, even though it would not be competitive,

you may have an MVP - Minimum Viable Product

It may take many more iterations for our increment to become competitive in the market.

An Iterative Process is a repeatable process

An Incremental Delivery/Development model is one that creates fully functional pieces of a product, that are

eventually integrated together

Scrum is intended to be used as an Iterative and Incremental product development framework


The ScrumMaster

Authority & PowerA ScrumMaster has no defined power or authority over anyone, and over anything

outside of the Scrum Framework. All other power or authority given to the ScrumMaster is assumed.

LeadershipScrumMasters are LEADERS, not MANAGERS! The only acceptable leadership style

for a ScrumMaster is Servant-Leadership.Teaching, Coaching, Mentoring, etc.

Never hand-holding, directing, commanding, controlling, or managing.


ScrumMaster Services

Service to the team

The Scrum Master Coaches and Trains the team on Scrum, Self-Management, and the importance of becoming cross-functional.

The Scrum Master helps the team focus on high-value Increments meeting the Definition of Done (DoD).

The Scrum Master works with the Scrum Team to remove impediments.

The Scrum Master ensures that all Scrum Events take place, are kept positive and productive, and kept within a timebox.



Service to the Product Owner

The Scrum Master Coaches the Product Owner on creating an effective Product Goal.

The Scrum Master Coaches the Product Owner on Product Backlog Maintenance & Product Backlog Item refinement techniques.

The Scrum Master Coaches the Product Owner on Empirical Product Planning.

The Scrum Master helps the Product Owner create and maintain great relationships with the team’s Stakeholders.



Service to the Organization

The Scrum Master helps the organization by leading, training, and coaching the organization in its Scrum adoption.

The Scrum Master helps the organization with planning and advising Scrum implementations within the organization

The Scrum Master helps employees and stakeholders understand and enact an empirical approach for complex work

The Scrum Master helps to remove barriers between stakeholders and Scrum Teams.


Many Hats of the Scrum MasterDoctor

Performs periodic checkups /

assessments; grades the health of the team’s practices

Nurse

Promotes team health and prevention; cares

for the ill, advocates for a safe and supportive environment

Psychologist

Provides diagnostic assessment using interviews

and asking questions to identify current state; connects personally with

individuals; honors doctor/patient confidentiality

Guard Dog

When needed they are the protector of the

team; protects someone or something from outside or harmful

influences

Mr. Miyagi

Taught that the secrets of the

masters lie in the mind and heart, not in the hands

Bloodhound

Keen senses and tenacious tracking

instinct, follows trails to uncover what is happening

Mother Hen

Doing whatever is needed to protect the team from any outside interference

(Helicopter-Mom)

Agile Junkie

A person consumed by Agile and seeks more

information within and outside of the organization

Guide

Provides assistance, information, cultural

and historical information, direction - when requested

Statistician

Produces trustworthy data and analyzes data

to make meaning clear; draws practical conclusions; reports data

outward from team

Servant Leader

Devotes self to serving the needs of others, focusing on meeting

those needs; the model for future leaders

Mentor

Provides examples of past experiences; guides professional

development

Coach

Listens, asks focused questions,

reflects back, clarifies goals, anticipates obstacles, gives advice

Air Traffic Controller

Maintains a safe and orderly flow of

work traffic; prevents collisions

Concierge

Goes the extra mile to make

experience happy and memorable for team members

Translator

Communicates the meaning of language

to create common understanding

Scientist

Researcher; experimenter; creatively

makes hypotheses and helps team test them

out to found out what works

Referee

Resides from a neutral point of

view, make on the fly decisions and enforces rules


The Scrum Master as a Servant Leader

Servant Leader

Devotes self to serving the needs of others, focusing on

meeting those needs; the model for future leaders

“Servant leadership is a philosophy and set of practices that enriches the lives of individuals, builds better organizations and ultimately creates a more just and caring world.”

Please explore more about Servant Leadership, research Robert Greenleaf’s work.

You may act as a servant leader in your organization in many ways. Whenever you truly put the needs of others, before your own needs, you are acting as a servant leader.

The Scrum Master serves the Product Owner by coaching them on new/better Product Backlog maintenance techniques. This is a form of servant leadership.

The Scrum Master serves the Development Team by training them on the use of Scrum, getting them proper training in their engineering practices (if needed), and assisting them in removing their impediments. These are

all forms of servant leadership.

The Scrum Master serves the entire company by helping other areas determine where Agility can thrive, where Scrum (or other techniques) could thrive; by helping set up Communities of Practice that will bring other

employees together around common interests. These are forms of servant leadership.


Being a ScrumMaster - How is it Possible?

Runway Model

There’s no ‘easy way’ to being a good ScrumMaster. The work is difficult and

sometimes thankless.

Often, though, modeling the behaviors and values that define Scrum and Agile, will

make becoming a good ScrumMaster easier.

It also promotes acceptance of the same by the Scrum Team

“Once you realize what you can do to make a difference, you may find yourself afraid to do it. This is a sign you’re on the right track” -Michael James


Scrum Team Rights & Responsibilities

Choose Developers, Scrum Master, and/or Product Owner• Produce a “Done,” usable, releasable Product Increment each

and every Sprint• Help those outside the Scrum Team understand which of their

interactions with the Scrum Team are helpful and which aren’t• Promoting and supporting Scrum as defined in the Scrum

Guide• Maximize the value of the product resulting from the work of

the Development Team• Define scope for the Development Team• Produce quality work• Estimate Work• Ongoing Visioning• Sign up for work rather than be assigned work• Improve their development practices• Implement action items• Experiment with new ideas• Have access to stakeholders• Decide when to release• Address issues openly• Ensure the psychological safety of the Scrum Team• Assist with Impediments• Ordering Product Backlog• Budgeting• Make sure impediments are removed• Independent Product Authority• Assist Product Owner in maintaining the Product Backlog


Scrum Roles and Responsibilities


A Day in the Life - Developers

Attend the Daily Scrum Alert ScrumMaster with Impediments, or help as

needed

Work on PBI’s with other Team

Members, to create the Increment

Everyone on the team collaborates to complete

the Sprint Goal

Ask Product Owner questions to clarify

PBI’s


A Day in the Life - Product Owner

• Developing & explicitly communicating the Product Goal

• Creating & clearly communicating PBI’s

• Ordering the Product Backlog

• Ensuring the Product Backlog is transparent

• Everybody wants something

• Prioritize requests

• Refine requests into PBI’s

• Coordinate with other Product Owners

• Arrange / group PBI’s into Release

• Be available to collaborate with Development Team

• Be available to the ScrumMaster

The hardest role in Scrum


Sprint Retrospective

The question I get asked most often by ScrumMasters:

“How do I facilitate a good Retro?”

Five Phases of a Retrospective

1.

2.

3.

4.

5.



What kinds of data can you bring to the Retrospective?

What types of data are generated during the Retrospective?



• Your improvement plan includes one improvement item that goes on the

next Sprint’s Backlog (This is now optional)

• Follow up during the Sprint on the Continual Improvement item

• Bring the new Continual Improvement Backlog to the next Retro!

• Make the Continual Improvement Backlog an Information Radiator that

everyone has access to

Do Not Forget!



Who MUST be at the Sprint Retrospective?


Where should you hold the Sprint Retrospective?

How often should you hold Sprint Retrospectives?

When during the Sprint should you hold the Sprint Retrospective?

Why should Scrum Teams do Sprint Retrospectives?


Product Backlog

A dynamic, ordered, and transparent Scrum Artifact that holds all currently identified features,

enhancements, fixes, experiments for future releases of the Product.

Often referred to as the ‘Wish List’ for the

Product.

The Product Owner owns the Product Backlog, but anyone can add PBI’s to it. It is the Product Owner’s responsibility to keep track of what is being added,

and to constantly re-order the Product Backlog.

Everything in the Product Backlog is

generically labeled a Product Backlog Item

(PBI).

(There are MANY types of PBI’s. User Stories are only

1 type of PBI.)

The Product Backlog should be kept ‘fresh’. If there are PBI’s in it that you won’t get to in the next 9 - 12 months...

trash them.


Product Backlog Items

Product Backlog Items are generally referred to as PBI’s.Don’t forget, there are MANY different type of PBI’s.

You may just be using a few. Explore!

PBI’s are Estimated by the Developers.

PBI’s are ordered, by the Product Owner, in the

Product Backlog.

PBI’s should have a description that the

Developers is satisfied with, before they start

working on them.

PBI’s have value. Usually this is assigned to each PBI

by the Product Owner.

Product Backlog Refinement helps us expose the details of PBI’s, and keeps the Product Backlog Transparent.

It also helps us cut down on time spent in Sprint Planning!


Product Backlog RefinementAfter refinement...

What can you say about the size of the items at the top, middle and bottom of the Product Backlog?

What can you say about the details

of the items at the top, middle, and bottom of

the Product Backlog?

What can you assume about the estimates of the item at the top, middle and bottom of the Product

Backlog?

What can you say about the readiness

of the items at the top, middle

and bottom of the Product Backlog?


Product Backlog Refinement2 Formats

3Amigos

WholeTeam


Product Backlog Refinement

Who goes to PBR?


Where should you hold PBR?

How often should you Refine?

When during the Sprint should you Refine?

Why should Scrum Teams Refine the Product Backlog?


Definition of Ready (DoR)

What was your team’s Definition of Ready, in the class exercise?

How does the Definition of Ready apply to the work being done on your team?


Definition of Done (DoD)

What was your team’s Definition of Done, in the class exercise?

How does the Definition of Done apply to the work being done by your team?


Reference MaterialsBooksAgile Software Development with Scrum - Schwaber & BeedleThe People’s Scrum - MayerAgile Retrospectives - Derby & LarsenThe Age of Agile - DenningTurn the Ship Around - MarquetCoaching Agile Teams - AdkinsThe Nature of Software Development - JeffriesThe Skilled Facilitator - SchwarzUnlocking Agility - HesselbergSoftware for Your Head - McCarthy & McCarthyDrive - PinkThe Phoenix Project - Kim, Behr, SpaffordAmelia Bedelia - ParishOrbiting the Giant Hairball - MacKenzieCore Scrum - Jeffries, HendricksonThe 5 Dysfunctions of a Team - Patrick LencioniThe New New Product Development Game

Websiteshttp://agilemanifesto.orghttp://scrumguides.orghttp://wisecrum.comhttp://formulaink.comhttp://mypersonalagility.orghttp://scrumalliance.orghttp://retromat.orghttp://ronjeffries.comhttp:/AgileGames.ca

http://poppendieck.comhttp://objectmentor.comhttp://martinfowler.comhttp://www.scrumplop.org/http://scrumguides.org/scrum-guide.htmlhttps://pragprog.com/titles/dlret/agile-retrospectiveshttp://www.romanpichler.com/blog/one-page-product-owner/http://scrummasterchecklist.org

VideosSh*t Bad ScrumMasters SayThe Cynefin FrameworkSilicon Valley Season 1, Episode 5Scrum Master - The Power of ScrumFix the Plumbing - by Erin PerryOffice Space - I Have People SkillsThe Lone Nut and the First Follower

Scrum Alliance eLearning Series:https://www.scrumalliance.org/learn-about-scrum/scrum-elearning-series

https://hbr.org/1986/01/the-new-new-product-development-game

certified scrummaster® (csm) - wisecrum

Documents