Practical Scrum - one day training

PRACTICAL SCRUM

Like us: Visit: Follow me:Tweet:

CONSTANT HIGHER MORE

LEARNING QUALITY FUN

Day 1

www.facebook.com/PracticalAgile www.practical-agile.com@Linkedin@PracticalAgile1

https://www.facebook.com/PracticalAgile/?fref=ts

http://www.practical-agile.com

https://www.linkedin.com/in/anat-alon-a43b453a?trk=hp-identity-photo

BEING AGILE IS OUR FAVORITE THING

Some Working Agreement

If you want to be here - act like you want to be here

Some Working Agreement

EXERCISE

Let’s Form Teams

Respect the sticky noteOne item per sticky, use a sharpie

What are we going to cover today?

TABLE OF CONTENTS

What is Agile?

What is scrum?

What are the roles in scrum?

What is the manager role within agile environment?

How to estimate stories?

How do we do long term planning?

What is the meaning of each ceremony in scrum?

“It ain’t what you don’t know that gets you into troubles. It’s what you know for sure that just ain’t so”

Mark Twain

WHAT WE THOUGHT VS. WHAT WE KNOW

What we thought vs. What we know

Requirements

Design

Implement

Test

Acceptance

Analysis

Deliver

WINSTON W. ROYCE 1970

"I believe in this concept, but the implementation described above is risky and invites failure"

“It ain’t what you don’t know that gets you into troubles. It’s what you know for sure that just ain’t so”

Mark Twain

WHAT WE THOUGHT VS. WHAT WE KNOW

01WHAT WE KNOW

The harder we plan and analyze in the beginning, the less there’s change in the project and the more successful the project

WHAT WE THOUGHT

WHAT WE THOUGHT

01WHAT WE KNOW

There is change always and responding to it is vital. Uncertainty is best reduced by learning from actual implementation

02WHAT WE KNOW

It is possible to “collect” or even “know” all the requirements up-front

WHAT WE THOUGHT

02WHAT WE KNOW

Requirements evolve as customers and our knowledge increases – based on experience

WHAT WE THOUGHT

03WHAT WE KNOW

Division of work to specialized teams (specification, design and testing) is efficient

WHAT WE THOUGHT

WHAT WE THOUGHT

03WHAT WE KNOW

Cross-functional teams reduce the amount of handovers and are more productive

04WHAT WE KNOW

Multiple parallel programs speed up the development

WHAT WE THOUGHT

EXERCISE

Exercise: The Name Factory

••

••

Round 1

Context Switch

Round 2

No Context Switch

WHAT WE THOUGHT

04WHAT WE KNOW

Multiple programs create big management overhead and risk of overloading the pipeline, R&D works most efficiently in continuous mode

05WHAT WE KNOW

Resource usage and cost optimization is the key to increased productivity

WHAT WE THOUGHT

Continues Improvement Respect for People

Waste Value

Opportunity for improvement

Traditional improvement

Lean Thinking

Kaizen - Reduce Waste

Value:

The moments of actions or thoughts creating the product that the customer is willing to pay for

Total value time

Total cycle time= Value ratio____________

Waste:

All other moments or actions that do not add value but consume resources

Detect and Eliminate Waste1. Overproduction of features

2. Waiting and delay

3. Handoff

4. Extra process

5. Partially done work

Detect and Eliminate Waste6. Task Switching

7. Defects

8. Under-realizing people’s potential

9. Knowledge scatter

10. Wishful thinking

WHAT WE THOUGHT

05WHAT WE KNOW

Concentrating on value stream optimization, removing waste and sustainable flow increases productivity

06WHAT WE KNOW

It’s possible to transfer information effectively on written documents without much of human contact.

WHAT WE THOUGHT

WHAT WE THOUGHT

06WHAT WE KNOW

Essential knowledge is lost in every handover and human interaction is needed to overcome it.

07WHAT WE KNOW

You can save time by “good-enough” development.

WHAT WE THOUGHT

Technical Debt

Time

Work left 20

10 12 14 16 18

Low Quality

WHAT WE THOUGHT

07WHAT WE KNOW

Any technical debt will slow development down and thus we don’t allow technical debt to accumulate.

08WHAT WE KNOW

Product development process can be defined as a predictable and repeatable process

WHAT WE THOUGHT

WHAT WE THOUGHT

08WHAT WE KNOW

Product development is an evolving and adaptive process

THE ORIGIN

• Toyota lean concept

• The new, new software development game [Takeuchi & Nonaka, 1986]

• Iterative & incremental development

WHAT IS AGILE?

EXERCISE

Rewrite Each Agile Principle With 3 Words

Agile Principle 1-4

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

Agile Principle 1-41. Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software

2.Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage



2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to a shorter timescale



2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to a shorter timescale

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

Agile Principle 5-85. Build project 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 development team is face-to-face conversation




7. Working software is the primary measure for progress




7. Working software is the primary measure for progress

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely

Agile Principle 9-12

9. Continuous attention to technical excellence and good design enhances agility

Agile Principle 9-129. Continuous attention to technical excellence and good design

enhances agility

10.Simplicity – the art of maximizing the amount of work not done – is essential


enhances agility


11.The best architectures, requirements, and designs emerge from self-organizing teams


enhances agility


11.The best architectures, requirements, and designs emerge from self-organizing teams

12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

EXERCISE

Command and Control Vs.

Self Manage

Where Scrum Fits?

• In our industry people got used to create and use META solutions to problems.

• The problems we are facing have nothing to do with technology, it is a people issue.

• In this land the basic assumption is that there is no META solution, just an empirical framework to allow inspect & adapt cycles.

• This experience is frustrating for those who are looking for predefined processes and final answers.

• ENTER AT YOUR OWN RISK!!!

WHAT IS SCRUM?

"Scrum is a team of eight individuals in Rugby. Everyone in the pack acts together with everyone

else to move the ball down the field in small incremental steps. Teams work as tight,

integrated units with whole team focusing on a single goal."

THE ORIGIN OF SCRUM

• Toyota lean concept

• The new, new software development game [Takeuchi & Nonaka, 1986]

• Iterative & incremental development

• Jeff Sutherland• Ken Schwaber

• Understanding that we cannot predict the future

• One size does not fit all

• Constant improvement

• Transparency & Visibility

• Team work

SCRUM PRINCIPLES

• Deliver business value fast (max. 30 days)

• Prioritizing

• Empirical approach

• Fun !!!

SCRUM PRINCIPLES

THE HIGH MOON STUDIO

SCRUM PROCESS OVERVIEW 3 Roles:

Product owner

Scrum Master

Team 4 Ceremonies :

Sprint Planning

Daily

Sprint review

Retrospective 3 Artifacts:

Product Backlog

Sprint Backlog

Burndown Charts

SCRUM MASTER (SM)• Scrum - A framework for

managing the development lifecycle of software products

• Master - A skilled practitioner of a particular art or activity

• A Scrum master - the leader of the Scrum process (& team)

What does it means “The leader of the scrum process”?• Coach the team with Scrum• Coach the PO with Scrum• Help Facilitate effective ceremonies• Helps removing impediments• Help the team grow • He is standing at the nexus between:

The product management that believes that any amount of work can be done

Developer’s that have the willingness to cut quality to support the managements belief

The English verb “to manage” was originally derived from the Italian maneggiare, meaning to handle and

train horses

The SM has no authority over the team or the PO

WHAT IS THE MANAGER ROLE WITHIN AGILE ENVIRONMENT?

A change in Manager’s roleStop:

• Assign task and verify completion• Micro manage to have the “illusion of control”• Makes decisions for the team• Limit the information & resources available to the team

Start:• Trust the team to get the job done• Gather data• Coach - observe and ask questions• Challenge• Give feedback

SCRUM TEAM• Self organizing• Typically 5-9 people • Cross functional (Preferably a

feature team)• Provide estimate for the tasks• Decides how much it can do• Decides how to reach the sprint

goal (within the project’s boundaries)• The team is responsible for the

outcome

CONCEPT CHANGE • Decides what it can do• Decides how to do it• Responsible for the quality• If the job is successful the team

gets the credit• If the job is not DONE the team

is responsible

ALL OF US ARE SMARTER THAN

ANY OF US

THE TEAM IS WRONG?

• Let the team fail• Create an environment where it

is ok to fail• Failure amplifies learning• Where failure is allowed,

innovation and experiments are encouraged

• Increases trust

THERE IS NO FAILURE ONLY FEEDBACK

PRODUCT OWNER (PO)• Defines the features of the product• Defines release dates and content• Responsible for ROI• Prioritizes feature according to value• Can change features and priority

once every predefined interval• Decides what will be worked on in

each iteration• Accepts or rejects results

Manage the product Backlog 1. Clear2. Ranked

3. Optimize the value

4. Visible transparent

5. Ensure understanding

Traditionally throws content “over the fence”

The PO takes an active role throughout the development lifespan

Traditionally throws content “over the fence”

NO MORE! CONCEPT CHANGE

How? • Talk directly and frequently with your

customers

• Talk directly and frequently with your development teams

• Engage the development teams in creating value for your customers

• Maintain your product’s quality and agility – do not let technical debt accumulate

Product Backlog Refinement = GroomingThe team and the PO together review the backlog in order to make it ready for the next 2-3 sprints

How?

Grooming = Clarifying, Estimating, and Splitting

Recommended to allocate ~5% of the sprint time

Sizing Requirements

KEN SCHWABBER, “SCRUM ET AL”

What is Definition of Done (DoD)Terms of satisfaction of the product owner

Defined by the PO with the team

reflecting the technical abilities of the team

Items that are not Done “do not count”

This is just one example

Expending the Definition of Done over time

Designed

Coded

analyzed

Unit tested

Perf. tested

Code coverage

Live

Deployable

Acc. tested

This is just one example

Expending the Definition of Done over time

Undone Undone UndoneUndone

Stabilization sprint(s)

Sprint 1 Sprint 2 Sprint 3 Sprint 4

Undone = risk

Undone = no visibility Can we

release ?

Unfinished Unfinished Unfinished

Agile Effort Estimations

EXERCISE

Estimate The Following Based On Weight In Kilograms [No Google Please!!!]

• Chihuahua • Great Dane • Staffordshire bull terrier • Appalachian mountain dog • Border Collie • American Cocker spaniel

“IT IS BETTER BE ROUGHLY RIGHT THAN PRECISELY WRONG”John Maynard Keynes

Persistence of Time

34.4

Relative Estimations

• We are: - Not good in measuring absolute values- Good in comparing things

• We have the basic math skills (or a calculator)

• High accuracy has a high toll

• Estimates become commitments

• Time is not persistent

Why Relative?

Story Points:

They reflect the “bigness” of a user storyHow hard it is ? How risky it is ? How much of it there is ? 5

?

3

1. Each person gets a deck of cards (Fibonacci)

2. The item to be estimated is read to all

3. Attendants ask clarifications for the item

4. Each person selects a card and puts it on the table facing down

5. When everyone is done, cards are exposed

6. If the estimations do not match a short discussion is done:Highest and Lowest estimators speak first -> return to step 4

7. Handle next item

Planning Poker:

EXERCISE

Estimate The Following Based On Size Using Planning Poker

• Spain • China • Luxembourg • Denmark • South Africa - 8 (Reference

point) • Belize

• Those who do the work estimate it

• Emphasizes relative estimation

• Estimates are within one order of magnitude

• Modeled for open discussion – forces thinking

• Reduces anchoring - Everyone's opinion is heard

WHY USE PLANNING POKER?

One page specGroup A

7 Pages specGroup B

173 hours

117 hours

Specification Length

Group A

Customer thinks 500 customer has no technical knowledgeDon’t let the customer influence you

Group B555 hours

456 hours

Same as B customer thinks 50

Group C99 hours

Anchoring

WHY USE PLANNING POKER?

IT IS QUICK!

IT IS FUN!

Spain 3

China Too big

Luxembourg 0

Denmark 1

South Africa 8

Belize 1

Chihuahua 3

Great Dane 90

Staffordshire bull terrier. 17

Appalachian mountain dog.

???

Border Collie 23

American Cocker spaniel 13

The Results

Velocity = Speed + Direction How many points can the team complete in one iteration

Easy to measure

Fixes estimation errors

Easily reflects the project status

Primary parameter in planning

SP 8

priority

5

priority

4

SP 8

priority

3Planning

Iteration Planning

As Anat, scrum Master, I would like to calculate team velocity so that I will be able to estimate how much work I can do in the following iteration

SP 5

priority

2Planning

SP 2Iteration 1:

SP Done = 5+8+2 = 15

velocity = 15

SP 8

priority

5

priority

4

SP 8

priority

3Planning

Iteration Planning

As Anat, scrum Master, I would like to calculate team velocity so that I will be able to estimate how much work I can do in the following iteration

SP 5

priority

2Planning

SP 2Iteration 1:

SP Done = 5+8+2 = 15

velocity = 15

priority

7

SP 5

priority

6Planning

As Elad, product owner, I would like to calculate team velocity so that I will be able to estimate how much work we are going to complete in two months

SP 8

priority

5Planning

SP 2Iteration 2:

SP Done = 8+5 = 13

velocity = (15+13)/2 = 14

SP 5

priority

8

What will happen if support is needed?

SP 2

priority

7

Long Term Crisis:

Planning

Iteration 3:

SP Done = 2+5 = 7

velocity = (15+13+7)/3 = 12 ~

SP Done:

Iteration 4 = 5

Iteration 5 = 7

Iteration 6 = 6

Velocity = (13+7+5) = 8

Velocity = (7+5+7) = 6

Velocity = (5+7+6) = 6

Planning For Support: Alternating team each sprint

Alternating person each sprint

Limiting the hours per team

Use velocity - Ignoring it completely

Agile Planning With Scrum

Daily

Iteration

Release

Product

Portfolio

Strategy

Release Planning #Story

points

Time

Velocity

Calculating Release Time

Given that:

The items for the release are estimated

The velocity is known (or predicted)

We know the scope or deadline

#Story

points

Time

Velocity

Calculating Release Time

We can estimate:

How much content can we do until the deadline

How many sprints it will take to complete the content

# Sprints X Velocity = # Story Points

# Story Points

Velocity = # Sprints ____________

#Story

points

Time

Velocity

Scrum Ceremonies

Sprint PlanningThe first meeting of the sprint

Length: 2-8 hours

Participants: PO, Team, Scrum Master

Preconditions: Product backlog should be in good shape

Divided into two parts

Sprint Planning Goal

Sprint Planning - Part IDecide what the team takes to part II

1. PO Explains the top items from the backlog

2. Team decides what takes to part II in order to commit for sprint content

3. Team and PO selects the sprint goal

Sprint Planning - Part IIGenerate the sprint backlog & commit on the sprint’s content

How?Splitting each of the stories into smaller tasksEstimating each task (maximum length 8 hours)Design decisions Verify that the goal is achievableCommit

Sprint Backlog

The sprint Backlog Belongs to the teamAssists the team in tracking the sprint’s progressMaximum task length should not exceed 16h (2 days) for a 2 week sprintUpdated throughout the sprint• Every team member can add, remove or change the sprint backlog• Status of tasks & remaining work is updated daily• Sprint content emerges

To do In progress Done

PBI # 1

PBI # 2

Task Board


PBI # 1

PBI # 2

Task Board


PBI # 1

PBI # 2

Task Board


PBI # 1

PBI # 2

Task Board


PBI # 1

PBI # 2

Task Board

Burndown Chart

A simple visual way of tracking progress

Used in different levels:SprintReleaseProduct

Shows the amount of work left to reach target

Effo

rt re

mai

ning

0

25

50

75

100

Sprint

1 2 3 4 5 6 7 8

Sprint Burndown Chart

Daily Scrum

Every day, Same time, Same place

No longer than 15 minutes

Stand up

All the team must attend

Only team members are allowed to speak

Daily

Daily

3 Questions: 1. What have we accomplished since the last daily

2. What will we accomplish until the next daily

3. What are my/our impediments

EXERCISE

Daily Scrum From Hell

Sprint Review

Show & Tell

Bazaar Review

Close the sprint

Participants: The team, PO, everyone (managers, customers..)

Inspect & adapt, focus on feedback - this is NOT a Demo

Focus on shard learning - not reporting

Only Done Working Software allowed

Avoid power point presentation

Sprint Review

EXERCISE

Ball Point Game

EXERCISE

Ball Point Game

‣‣‣‣

Sprint Retrospective

‘The greatest enemy of great is good enough’

Goal: Inspect and create plan for improvements Team time tune & adjust After sprint review - Before sprint planningLength: 1-2 hoursParticipates: Scrum Master and the team (others are optional)Generate AI (experiments) to execute the following sprint

Sprint Retrospective

Things to Stop doing

Things to start doing

Things to Keep doing

Retrospective Model Example

Opening (2-5 minutes)

Data collection (15-25 minutes)

Generate insights (15-25 minutes)

Decide what do do (15-25 minutes)

Closing (2-5 minutes)

THE WRONG WAY TO DO RETROSPECTIVE

Parking lot

“THE VALUE OF AN IDEA LIES IN THE USING OF IT”

Thomas Edison

THE EXPERT SOLUTION

Reading List 1. Clean Code

2. Scrum Guide

3. Delivering happiness

4. Peopleware

*RECOURSE