Waterfall into Scrum

|

Intro

Chad “Uber Scrum Master” Holdorf

Scrum Master / Program Manager: John Deere

Certified Scrum Master and Product Owner

Email: chadholdorf@gmail.com

Blog: http://uberscrummaster.wordpress.com

2

|

Agenda

• Results• Overview of Framework (Scrum)• How Scrum fits with current Waterfall processes

3

|

What have been the results of other companies?

Increased Speed• SalesForce.com

• Prior to Agile• 1 Release per year

• Post Agile• 4+ Releases per year

• Inovis- EDI/Business Software• Post Agile: < 1 Month per Release• Industry Avg: 6 Months per Release

Increased Efficiency• Inovis Post Agile

• Average Release in Person Months: 12PM• Industry Release Avg: 34PM

More Examples in Backup Section at End

4

|

What is this Agile/Scrum Framework?

5

|

3 Facets of the Framework (Scrum)

Roles(Who)

Product Owner Team Scrum Master

Artifacts(What)

Product Backlog Sprint Backlog Potentially Shippable

Product Burndown Charts

Practices(How)

Sprint Planning Sprint Sprint Review Retrospective

6

|

Overview of Scrum Framework

7

Roles

Product Owner

Scrum Master Team

Artifacts & Practices

|

Product Owner

• Owns the vision of what should be produced to achieve business success

• Manages ROI through prioritization and release plans

• Gets input from customers, end-users, team, managers, stakeholders, executives, industry experts when crafting the vision

• Turns input into a single list of what should be produced, prioritized based on business value and risk

• Owns the Product Backlog

“The Product Owner’s focus is ROI. The Product Owner directs the project, sprint by sprint, to provide the greatest ROI and value to the organization.”

Product Owner

Scrum Master Team

8

|

The Scrum Master

• A new leadership role• It can be played by an existing person (such as a former Project Manager or team-

member).

• Serves the team• Helping remove any and all impediments that surface

• Protects the team• Teaches and guides the team’s use of Scrum• Facilitates – doesn’t “manage” (direct) the team

Product Owner

Scrum Master Team

“The Scrum Master is responsible for the success of the project, and helps increase the potential for success by helping the Product Owner select the most valuable backlog items and by helping the Team turn that backlog into functionality.”

9

|

The Team

• Owns the production and engineering process• Cross-functional - it has all the skills to produce the finished

product• Self-organizing and self-managing - it is responsible for making

a commitment and managing itself to hit the goals (or get as close as it can)

• Authority to do whatever is necessary to meet it’s commitment• The ideal team size in Scrum is 7 people +/- 2

Product Owner

Scrum Master Team

“The Team is responsible for managing itself and has the full authority to do anything to meet the sprint goal within the guidelines, standards, and conventions of the organization and of Scrum.”

10

|

Artifact:

Product Backlog

• Single master list of features, functionality, and other work required

• Prioritized based on business value and risk, in the judgment of the Product Owner

• Items at the top of the list will be completed by the team first and should have more detail than lower priority items

• Constantly being revised by the Product Owner, to maximize the business success of the team’s efforts

• Product Backlog Items vary in size (typically 2-3 people, 2-3 days).

11

|

Artifact:

Product Backlog

12

Product Backlog

Item

Priority

High-Level Est.

|

Practice:

Sprint Planning Meeting

• Team selects what it will commit deliver by the end of Sprint• Team creates a task-level plan for how they will deliver• Team creates an initial assignment of tasks• Team compares total estimated task hours with total

estimated available hours, to make sure the commitment is reasonable

• Everyone on the team takes part, regardless of role and experience-level

13

|

Practice:

Sprint Planning Meeting

• Product Owner must not pressure the team into committing to more than they think is doable.

• Managers may initially be concerned that their team might under-commit.

• Many teams are initially concerned about the perception of the amount of work being completed, so they over commit.

• In reality, most teams have the opposite problem: it may take them several Sprints to learn to not over-commit.

14

|

Artifact:

Sprint Backlog

• Complete list of tasks required to meet the sprint goals and committed product backlog items

• Tasks include detailed estimate created by the team• Team tracks effort remaining to complete each task• Constantly being revised by the Team, to maximize

achievement of the sprint goal• Tasks vary in size but no larger than 2 days

15

|

Practice:

Daily Standup

• A short meeting daily to update each other on progress and surface impediments

• Strictly time-boxed to 15 minutes• 3 questions: what was done since last meeting, what will be done by

next meeting, and any issues/impediments• Scrum Master notes issues/impediments, and afterwards helps

resolve them• Others can attend the meeting if the team invites them, but they do

not speak. This meeting is not for monitoring the team

16

|

Artifact:

Burndown & Burnup Charts

• Each day, the team updates simple charts that show progress towards their Sprint goal.

• The Burndown Chart graphs the total hours left for all tasks.• The Burnup Chart graphs the total number of backlog items

completed in the Sprint.• These charts enable the team to successfully self manage and

deliver what they committed to by the end of the Sprint.

17

|

Artifact:

Burndown & Burnup Charts

18

|

Artifact:

Potentially Shippable Product

• The goal for the team is to complete 100% of what they committed to, ideally an increment of Potentially Shippable Product at the end of each Sprint.

• For software, this means functionality that has been designed, fully implemented, and fully tested, with no major defects.

• Few teams can produce Potentially Shippable Product from Sprint 1, but each Sprint they work to get closer to this goal.

19

|

Practice:

Sprint Review (Demo)

• Performed at the end of each Sprint• Product Owner, Team, Scrum Master, and Stakeholders come

together and see a demo of what the team has produced• Product Owner gathers feedback from everyone on the ways

to improve what has been built• Feedback is incorporated into the Product Backlog

20

|

Practice:

Sprint Retrospective

• Critical for continuous improvement of team effectiveness• Method for identifying and addressing critical problems• Retrospective meeting requires the Team, Product Owner, and

Scrum Master• Focuses on 3 questions:

1. What worked well?2. What needs improvement?3. What action items do we implement in the next sprint

21

|

Typical Project Lifecycle

22

|

Scrum Shifts the Drivers

23

Scope

Traditional ProjectThe plan createscost / schedule

estimates

Budget Schedule

Plan Driven

Fixed

Estimated

Value Driven

Budget Schedule

Scope

Scrum ProjectThe vision creates scope estimates

|

So how does the framework fit?

24

|

Sco

pe

Waterfall vs. Agile

25

Analysis/Design

Code

Component Test

System Test

Sch

edule

End to EndSmall Slices of work

20% Done = 100% usable

Ph2

Ph 3

Ph 4

Ph 5

Ch

Scope

Budget

ScheduleCh Ph2 Ph 3 Ph 4 Ph 5

|

Align w/ Waterfall Exits

26

Sco

pe

100%

Schedule/Budget

Product IncrementsPhase Exits

RequirementsSprints

Charter Ph2 Ph4Ph3

System Verification

Value

Team members dedicated

Not all requirements are written

Teams “sprint” all the time

Value is created quicker

“Trimming the Tale” Time to

move on

Goal is to remove this

phase through automation

Ph5

|

References

• Salesforce.com Agile Transformation • Inovis - Reformulating the Product Delivery Process• Project Management With Scrum

27