Scrum In Action

Shay Cohen11/5/2010

Agenda

• The Pain Points• What is SCRUM ?• Scrum Flow• Roles• Planning a Sprint• Pillars & Principals• The Results• From hell to Heaven• Recommendation

• Worked very similar way to waterfall– Try define all at the beginning– Break the plan– Fix and delay as we go along– Months ahead

• Every feature is P0• Low productivity due to missing / changing requirements• Low visibility during planning stage• Long release cycles – TTM• We establishing our RoB as we progress• A lot of noise during the development – DCRs, Integrations, Bugs• Poor WLB

The Pain Points

Areas for improvement:

• Communication• Simplicity• Feedback• Courage

• Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time.• It allows us to rapidly and repeatedly inspect actual

working software.• The business sets the priorities. Teams self-organize

to determine the best way to deliver the highest priority features.• Every 5w anyone can see real working software and

decide to release it as is or continue to enhance it for another sprint.

SCRUM in 100 words

Scrum Flow

RolesProduct OwnerPM

Teams

• Represent the stakeholders • Owner the Product backlog• Owner the Sprint backlog• Responsible for the prioritization

process• Approve removal of items during

running sprint

• Protect the Team and keep them focused on the tasks in hand

• Manage the daily SCRUM meetings• Update the dev task progress

Has the responsibility to deliver the product

SCRUM MastersTeam Leaders

Planning a Sprint

Product BacklogUser Stories User Stories Tasks (hours)

Iteration Backlog

Commi

t!

Commi

t!1

1

1

Can’t Commi

t!

Product BacklogUser Stories User Stories Tasks (hours)

Iteration Backlog

1

1

1

1

Commi

t!

? Commi

t!

Commi

t!

Planning a Sprint

Sprint Vs. Release

Sprint• Fixed duration• Potentially deployable

Release• Fixed content• Content of one or more Sprints• Deployable• Requires stabilization period and ZBB

1. Planning take place before the sprint begin2. We only plan what we know (well defined)3. Each user story get unique priority4. High priority items should be scheduled to the

beginning of the sprint5. We strive for HLD & STP before planning6. All tests are automated (Unit, Component, E2E)7. No test – no feature (E2E)

Pillars & Principals

Dev/Test Dev/Test Dev/Test Dev/Test QualitySprint N

Sprint N-1 Planning N

Planning N+1Planning N+1 Dev/TestSprint N+1

1. Last week is for quality and planning – no “new” code2. No buffers – Every developer has a long tail of low

priority user story3. New backlog items shall not be added to a running

sprint4. Integrations are planned for beginning* of Sprint5. Deployments ? Integrations ? Live system support ?

Pillars & Principals

Dev/Test Dev/Test Dev/Test Dev/Test QualitySprint N

Sprint N-1 Planning N

Planning N+1Planning N+1 Dev/TestSprint N+1

Addressing Pain Points

ClearOwner

Reporting & Tracking

Communication & Sync

Better Planning

Organizational Structure

The Results I

The Results II

From hell to HeavenThe outcome• The “right” feature are in, Nice-to-have / future are out• Better TTM • Better Quality• Better transparency• Less status reports/emails• Less meetings• Well known & establish ROB• Developers have clear and quiet work plan and environment • Better WLB

RecommendationsOrganization• Management buy-in / sponsorship• All or nothing - PM/Test/Dev• Daily scrum, Scrum of Scrums, Daily war-room on quality week

Quality & Automation• Test automation• Smoke Tests on submit• Nightly builds with BVT• Weekly / bi-weekly FRS & Manual tests• Quality week• Quality gates

State of mind• Transparency & communication is the key• Constantly give/take feedback• Courage