Scrum overview - Animated - Scott Emery 2014

Date: July 2014

Scott Emery, CSM – Sr. Health Intelligence Analyst,

Providence Health & Services

Scrum OverviewWhat is Scrum and why would you use it?

Animated VersionThis PowerPoint does not view properly on SlideShare but must be downloaded

7/31/2014Scrum Overview 2014 – Scott Emery, CSM 2

scrumskrəm/

Noun RUGBY

1.an ordered formation of

players, used to restart

play,…

scrumskrəm/

Noun SOFTWARE DEVELOPMENT

1.A framework for managing

product development in

iterations, or sprints…


Do you want a long-winded definition of Scrum?

We can do that…

But one of the founding principles of Scrum could be stated,

“Most people don’t like to read long, tedious & very detailed documents.”

So instead, try this:


Scrum is an agile software development framework for managing

product development in iterations, or sprints.

Scrum enables teams to self-organize by encouraging close online

collaboration of all team members and daily communication with all

team members and disciplines in the project.

A key principle of Scrum is its recognition that during a project

the customers can change their minds about what they want and need,

and that unpredicted challenges cannot be easily addressed in a

traditional manner.

Scrum accepts that such problems cannot be fully defined, focusing

instead on maximizing the team's ability to deliver quickly and

respond to emerging requirements.

Small Chunks of Work

Improve over time

15-minute daily meetings

customers don’t know what they want until they actually see it

Fixing problems before they get really big


The traditional software development project management framework is called Waterfall.

Requirements

Development

Testing

Design

Deploy

It’s called Waterfall because after each functional team completes their work, they “throw it over the edge” to the next functional team. In Waterfall, change is

generally considered to be a problem stemming from poor planning.

Ouch!Didn’t see that

one coming!


The first problem with Waterfall is Built-in Communication Gaps.

Requirements

Development

Testing

Design

Deploy

• Each time work passes between these functional teams there is a high probability some of the information won’t make the transition.

Communication Gaps

More Gaps

More Gaps

More Gaps

Each stage of the Waterfall results in a detailed document that has to be consumed by the next team.

The problem is, the next team always has a tight deadline and feels pressure to “Get to work” rather than spend time reading.

“Oops, I didn’t document it correctly”

“Oh, I didn’t read that”


Requirements

Development

Testing

Design

Deploy

The second problem is that Risk Accumulates over Time.

• Restated as a Rule: The longer the time between project start and delivery of software to the customer, the greater the risk.

• Unfortunately, waterfall projects take a relatively LONG TIME before they deliver working software.

1-2 years

Very Expensive Problems!


Requirements

Development

Testing

Design

Deploy

i.e., At the 80% mark when you have run out of time and money, you must pay more of both in order to get anything at all.

Waterfall is a “risk-accumulation” model with a hostage-taking situation near the end.

If you cut the project off before 100% of the

features are 100% done, you get nothing.

That’s because 100% of the features are 80% done.

Dep

loyThe Ransom: You have to

pony up more time and money if you actually want

the product delivered.


Requirements

Design

Develop

Test

Demo & Deploy

Evaluate & Re-prioritize

It starts with the same basic framework as Waterfall:

But it shortens the time frame…

Bites off smaller chunks…

Adds a step…

Then its “Wash, Rinse and Repeat” for the rest of the To Do list.

2 Years2 Weeks

2

3

1

4

5

6

7

8

9

10

12

13

14

15

16

17

18

19

20

11

To Do

5

6

4

8

9

7

Agile is a refinement of the waterfall process.

n

n

n


Gather Requirements

Design

Develop

Test

Deploy & Demo


Gather Requirements

Design

Develop

Test

Deploy & Demo


Gather Requirements

Design

Develop

Test

Deploy & Demo


Gather Requirements

Design

Develop

Test

Deploy & Demo


Each feature is fully developed and tested within a Sprint, and is demoed & delivered right away.

1st most important requirement

2nd most important requirement

3rd most important requirement

N most important requirement

And with each delivery of functional software,RISK ACTUALLY DECLINES.And you start with the MOST important features.

Because problems are quickly identified in the Demo session…

…and can be immediately fixed in the next sprint.

In Agile, Change is welcomed as a way to catch mistakes early, before they become really expensive to fix!Change?

Change?

Change?


Scrum is a specific “Flavor” of Agile.

Scrum’s greatest strength is in it’s focus on “Tips and tricks” that have proven to be very effective at helping development teams be more productive.

Other Agile “Flavors” include:• XP (Extreme Programming) • Kanban (derived from Toyota)• Feature-Driven Development

This development team focus is also Scrum’s greatest weakness: It doesn’t explain how to gather requirements. • It only defines how requirements need to be presented to the development team

in order to eliminate confusion.• Some trainers and practitioners (e.g., Mark Layton and Platinum Edge) have

created expanded frameworks that include requirements gathering.

7/31/2014Scrum Overview 2014 – Scott Emery, CSM

23456789

10N

1

Product Backlog

The Product Owner meets with Stakeholders, Business Analysts and Subject matter Experts to develop a PRIORITIZED list of requirements called a “Product Backlog”

In Scrum, requirements are grouped into features, or “Stories.” A story is written from an end-user perspective, so it is always tied to actual user needs.

The Story is a one sentence description with three parts:

1. The user

2. The feature

3. The benefit of the feature

Example: As a CFO I want to be able to see daily admissions for each hospital and clinic so I can manage performance in a timely manner.

A story is just a reminder of the actual

requirement. Each story has a list of testable factors called “Acceptance Criteria”

• Stats must be graphical• Graphs must drill down• Refreshed by noon• Able to view hospitals

and clinics separately• 12 months of history

QA tests each story during the sprint, and it is only Done when it meets the Acceptance Criteria.

12

To Do


23456789

10N

SprintBacklog

1

Product Backlog

The ScrumMaster holds a Sprint Planning Meeting with the Development Team to determine how many features (Stories) the team can develop in the sprint. These stories become the Sprint Backlog.

The Development Team plans and estimates the work and Commits to do the amount of work they believe is possible in the sprint.

When the Development team commits to the work, the sprint is Frozen – no more work can be added until the next sprint.

One of a ScrumMaster’s main responsibilities is to

make sure the sprint stays frozen.

SprintPlanning meeting

Co

mm

it

Free

ze

Backlog is just a fancy term for a “To Do” list

DoneWorkingTo Do


2 - Kim3 - Phil4 - Kim5 - Ray

6789

10N

----------------- Scrum Board -----------------

1 - Phil

Product Backlog

SprintPlanningmeeting

The Dev Team immediately starts working on the highest-priority items.

The major idea is to get each story 100% done by the end of the sprint.

Sprints are Time Boxed,meaning every sprint has

the same duration, Usually 1-4 weeks.

Sprints are never extended.

The team shows their progress to the rest of

the world on a scorecard called a Burn Down Chart

The team tracks their progress within the team on a scorecard

called a Scrum Board

DoneTo Do



6789

10N

-----------------Scrum Board ------------------

1 - Phil

ProductBacklog


Working

The Scrum meeting is a 15-min coordination meeting.

• What I did yesterday

• What I will do today

• What is giving me grief

During the scrum meeting, Each Dev Team member tells three things:

The team coordinates its activities each day with a Scrum Meeting.

Because the scrum meeting is a team

coordination meeting, instead of a reporting

meeting…

if things are going smoothly enough, the scrum master doesn’t

even have to be present.

DoneTo Do



6789

10N

-----------------Scrum Board ------------------

1 - Phil

ProductBacklog


Working

Sprint 3

Sprint 2

Sprint 1

WorkingSoftware

Release 1

Sprint 5

Sprint 4

Release 2

Sprint 6

Sprint n

The Scrum Team is held accountable to the Product Owner and other Stakeholders by a Demo of working software at the end of each Sprint.

The Scrum Team meets at the end of every sprint for a Dev Team Retrospective to determine how they can work better in the next sprint.

Each sprint ends with additional FULLY FUNCTIONAL software that the customer has seen and approved.

Releases are when the software is published.

Customer Demo

Retrospective

Working DoneTo Do



6789

10N

----------------- Scrum Board ------------------

1 - Phil

Product Backlog


Sprint 3

Sprint 2

Sprint 1

WorkingSoftware

Release 1

Sprint 5

Sprint 4

Release 2

Sprint 6

During the Customer Demo the Product Owner Accepts or Rejects each story.

If a story is rejected, a Refactoring (rework) story is put into the next sprint.

Stories need to be small enough to fit into one Sprint. If a story isn’t that small, it needs to be split into 2 or more smaller stories.

When the Dev Team plans the sprint, they break each story into tasks that can be done by one person in one day or less. The tasks are discussed in the Scrum meetings and tracked on the board.

Customer Demo

Retrospective

Re - 36b

6aTaskTask


----------------- Scrum Board ------------------SprintPlanning meetings

Sprint 3

Sprint 2

Sprint 1

WorkingSoftware

Release 1

Sprint 5

Sprint 4

Release 2

Sprint 6

6789

10N

Product Backlog

Repeat with more sprints until project end

DoneTo Do


1 - Phil

Working

Sprint 1 Sprint 2Sprint 3 Sprint n

Customer Demos

Retrospectives


19

Sprint Planning

WorkingSoftware

Release 2

Sprint 6

Customer Demo

Burn Down Chart

Daily ScrumDev Team

Retrospective

Sprint

1 - Phil2 - Kip3 - Lee4 - Reg5 - Bin

Sprint Backlog

Scrum Board

Increment123456

Product Backlog

Project Visibility

19


•7 people +/- 2

• Developers

• Quality Analysts

•Win/Lose as a team

• Self-directed, self optimizing

•Add Product Owner (PO)

•Add ScrumMaster (SM)

•Add Stakeholders


(PO)

•Decides What and When (i.e., the priority of each item)

•Not how much, because the PO is not doing the work

(Dev)

•How Much can be developed in one Sprint

•Commitment can’t be set from outside

(SM)

• In charge of the Process

•Works to optimize the process and the development environment so the team can be as successful as possible.


• Wikipedia Scrum_(development)

• Scrum.org

• Agile Project Management for Dummies

• Scrum for Dummies (Nov 2014)

http://en.wikipedia.org/wiki/Scrum_(development)

https://www.scrum.org/

http://www.amazon.com/Project-Management-Dummies-Lifestyles-Paperback/dp/B00GOHEFG8/ref=sr_1_6?s=books&ie=UTF8&qid=1405111006&sr=1-6

http://www.amazon.com/Scrum-Dummies-Computer-Tech/dp/111890575X/ref=sr_1_3?s=books&ie=UTF8&qid=1405111006&sr=1-3


Aligns IT with the Business

• Business becomes part of the tactical team doing the work, not separate

Early measurable ROI

• Tangible product at the end of every Sprint

Daily visibility on project progress

• Control under Scrum is MUCH higher than under other methods

Ability to empirically forecast schedule and costs

• Early project performance can be intelligently extrapolated

Systematically supports changing business needs

• Re-evaluation and re-prioritization of objectives are built in

Early and continuous customer feedback

• This results in products that better meet customer needs


Reduces product and process waste

• Scrum uses a lot of lean principles

Focus is on adding quantifiable value

• Instead of administrative activities

ScrumMaster is a coach

• Instead of a “checkbox manager” (NOT, “Are you done with this yet?”)

Performance accountability is not ‘outsourced’ to the PM

• The people who are responsible for an action item are those who are doing the work.

Less meetings

• And those are short and time boxed!

Builds empowered, motivated, self-organizing teams.


1. Commitment• Scrum provides clear lines between what I did and did not commit to.

• Team members help form the goal rather than having someone else set the goals for them.

• Team members have all the authority they need in order to meet their commitments.

2. Focus• Do your job. Focus all of your time and energy on meeting your commitments.

• Don’t worry about anything else.

3. Openness• Scrum keeps everything about the project visible to everyone. In fact, it takes

visibility to new levels.

• “If you don’t air your dirty laundry, no one will wash it.”

4. Respect• Our answers in aggregate are better than our answers as individuals.

• Team members respect each others experience and roles.

5. Courage• Team members are expected to have the courage to commit, act, be open, and

expect respect.

• Scrum takes courage because it embraces change.

Scrum overview - Animated - Scott Emery 2014

Software

Transcript of Scrum overview - Animated - Scott Emery 2014