Scrum Slides [PDF]

Zitiervorschau

SCRUM

THE

ART OF DOING TWICE THE WORK IN HALF THE TIME ! ! ! ! !

States - 3440 in the Germany

With help from Citrix Online, Google, Yahoo, Microsoft, IBM, Oracle, MySpace, Adobe, GE, Siemens, Disney Animation, BellSouth, Nortel, Alcatel-Lucent, EMC, GSI Commerce, Ulticom, Palm, St. Jude Medical, DigiChart, RosettaStone, Healthwise, Sony/Ericsson, Accenture, Trifork, Systematic, Exigen Services, SirsiDynix, Softhouse, Philips, Barclays Global Investors, Constant Contact, Wellogic, Inova Solutions, Medco, Saxo Bank, Xebia, Insight.com, SolutionsIQ, Crisp, Johns Hopkins Applied Physics Laboratory, Unitarian Universalist Association, Motley Fool, Planon, FinnTech, OpenView Venture Partners, Jyske Bank, BEC, Camp Scrum, DotWay AB, Ultimate Software, Scrum Training Institute, AtTask, Intronis, Version One, OpenView Labs, Central Desktop, Open-E, Zmags, eEye, Reality Digital, DST, Booz Allen Hamilton, Scrum Alliance, Fortis, DIPS, Program UtVikling, Sulake, TietoEnator, Gilb.com, WebGuide Partner, Emergn, NSB (Norwegian Railway), Danske Bank, Pegasystems, Wake Forest University, The Economist, iContact, Avaya, Kanban Marketing, accelare, Tam Tam, Telefonica/O2, iSense/Prowareness, AgileDigm, Highbridge Capital Management, Wells Fargo Bank, Deutsche Bank, Hansenet/Alice, GlobalConnect, U.S. Department of Defense, Agile Lean Training, EvolveBeyond, Good Agile, Océ, aragostTRIFORK, Harvard Business School, Schuberg Philis, ABN/AMRO Bank, Acme Packet, Prognosis, Markem-Imaje International, Sonos, Mevion, Autodesk, First Line Software, SCRUMevents, UPC Cablecom, NIKO, CWSBOCO, BottomLine, Lean Enterprise Institute, Liberty Global, Monster, Dartmouth University, Health Leads, Samsung R&D Center, Monster.com, Grameen Foundation, Diplomat, Silicon Valley Leadership Network, Raytheon, Fidelity, John Deer, Mass IT, HP, Lockheed, Saab, European Union, EduScrum.com © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

534,339 (7%) open Scrum jobs in the

! ! ! United !

As a class group we need

Introductions

2 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

in order to work together effectively

Group Introductions • Who’s in your group? • Pair introductions • Talk to each other and line up across

3 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

the room by level of Scrum experience • Line up in a second dimension by job function • What companies, industries, nonsoftware application are represented?

Self-Organize Teams • Based on line exercise, divide up into crossfunctional teams. ! !

• Then: Select a team name Select a Product Owner Select a Scrum Master Create a learning backlog – what do you hope to get out of the class individually and as a team

4 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• • • •

Scrum Stuttgart Doing

Done

5 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Do

Course Overview • Sprint 1: Day 1 morning • The Scrum Framework and its origins

• Sprint 2: Day 1 afternoon • Patterns for starting Scrum

• Sprint 3: Day 2 morning • Building and managing the Backlog

• Sprint 4: Day 2 afternoon

6 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Team Backlogs • Advanced topics and closeout

Agenda - Sprint 1 • Sprint 1 - Scrum Origins and Practice • • • • • • •

Intro (2) Team Learning Backlog (8) Scrum Origins (9) Agile Manifesto (5) Airplane Game (9) Getting Started (6) Scrum Framework (8)

7 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Sprint 2 - Starter Kit for a Scrum Master • Sprint 3 - Planning & Estimation • Sprint 4 - Team Backlogs & Review

Agenda - Sprint 2 • Sprint 1 - Scrum Origins and Practice • Sprint 2 - Starter Kit for a Scrum Master • Roles - Project Manager Exercise (8) • Patterns (4) • Daily Clean Code (5) • Avoid Multitasking: Swarming (9) • Handle Interrupts (3) • Improve Flow - Constraint theory (2) • Identify Bottlenecks - Value Stream Mapping (3) • Remove Major Impediments - A3 exercise (7) • Scrumming the Scrum (6)

8 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Sprint 3 - Planning & Estimation • Sprint 4 - Team Backlogs & Review

Agenda - Sprint 3 • Sprint 1 - Scrum Origins and Practice • Sprint 2 - Starter Kit for a Scrum Master • Sprint 3 - Planning & Estimation • A3 Review (2) • Exercise: Daily Meeting (7) • Exercise: Scrum of Scrums (3) • Scrum Board (5) • User Stories (12)

Nice to have * Money for nothing * Velocity * Technical Debt * Acceptance tests

• Exercise: Create User Stories (4) • Failed Scrum (9) • Exercise: Estimate Stories (7)

9 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Sprint 4 - Team Backlogs and Review

Agenda - Sprint 4 Sprint Sprint Sprint Sprint

1 2 3 4

-

Scrum Origins and Practice Identify and Remove Impediments Planning & Estimation Advanced Topics and Review

• Product Backlog Refinement (5) • Release Planning (6) • Teams Backlogs (27)

• XP Game (12) • Dan Pink Video (1) • Certification/Handouts/Evaluations (1)

10 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• • • •

11 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

As a Scrum Master understanding the Origins of the Agile Manifesto will help me implement Scrum

Disruptive Leadership: Life, Liberty, and the Pursuit of Happiness

Make Work Visible

Plans are Worthless, Planning is Everything!

Captain Edwin Atterberry Shot Down August 1967- Wikipedia

GANNT Chart

Landing the Project

YouTube: RF-4E of the Hellenic Air Force

Make Work Visible!

infoq.com

Continuous Improvement

Nonaka and Takeuchi Type A – Isolated cycles of work

NASA

Type B – Overlapping work

Fuji Xerox Scrum Project Management Type C – All at once

Honda, Toyota, 3M, …

Agile Leadership •

Sales, Marketing, Finance

•

Manufacturing

•

Technology, Software

•

Families and weddings

•

Education

•

Agriculture

•

Government

•

Space

Changing the World Higher grades Faster learning More fun Leadership Development Involves handicapped Motivated students Self-discipline

eduscrum.com

23 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

As a Scrum Master understanding the Agile Manifesto will help me implement Scrum

Lean Enterprise Institute

Production Techniques

Lean

Product Creation

24 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Scrum

Applicability of Scrum! Ogunnaike and Ray’s Process Control Requirements!

Far from Agreement

Chaos

Requirements

Complex

Empirical Process (Scrum) Lean

Complicated

Defined Process

Simple Close to Agreement

Close to Certainty

Technology Adapted from Snowden’s Cynefin Framework - see Wikipedia

25 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Far from Certainty

Defined Process

Defined plan with one input and one output and (hopefully) no deviations 26 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Traditional waterfall development is a “defined process.” A plan is defined at the beginning and precisely followed to the end. • This assembly line approach requires minimizing deviations from plan to be successful. • On average 65% of requirements change during software development causing waterfall projects to have an 14% worldwide success rate during the past decade. (Jim Johnson, Standish Group, 2011)

Empirical Process

Empirical plan with a new input after each cycle

27 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Controlling a process that has many unexpected changes requires introducing a feedback loop in order to inspect and adapt. • Product is build iteratively and incrementally where each set of features is fully operational after a short cycle. Results are inspected and changes are made in repeated cycles as work progresses. • Inspecting and adapting require full transparency of the work process to be successful. • During the past decade, the worldwide success rate of software projects developed with empirical processes and been triple the success rate of defined projects.

Agile Manufacturing - Beyond Lean

28 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Agile competition goes beyond the Japanese marketing strategies know as lean manufacturing by permitting the customer, jointly with the vendor or provider, to determine what the product will be. • For agile competitors, the ability to individualize products comes at little or no increase in manufacturing cost. It does, however exact a cost: It requires major changes in organization, management philosophy, and operations.

Agile Manifesto www.agilemanifesto.org! 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 processes and tools! Working software over comprehensive documentation! Customer collaboration over contract negotiation! Responding to change over following a plan 


29 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

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

Agile Manifesto Principles 1. Our highest priority is to satisfy the customer through early and continuous delivery of Customer visible value.


7. Customer Visible Value 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.


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











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


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








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


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









 6. The most efficient and effective method of 
 conveying information to and within a delivery team is face-toface conversation.


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

Survey: Mario Moreira

30 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

5. Build projects around motivated individuals. 
 Give them the environment and support they need, and trust them to get the job done.


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


State of Agile Chaos Manifesto 2011, Standish Group International, Inc.

Source: 31 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

The agile process is the universal remedy for software development project failure. Software applications developed through the agile process have three times the success rate of traditional waterfall method and a much lower percentage of time and cost overruns. The secret is the trial and error and delivery of the iterative process.

32 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Source: Version One

Top 12 Failure Modes for Scrum

• • • • • •

Overburdening team (bad management, no happiness metric) No stable teams or people not assigned 100% to one team Poor user stories, no clear definition of READY (bad product owner) Taking too much into a sprint and failing to deliver working software Daily meeting not replanning and removing impediments Not fixing bugs found inside a sprint, particularly integration bugs Working on too many stories at once inside the sprint Failure to have a plan for interruptions or emergencies No clear definition of DONE Not executing improvements identified in the retrospective

33 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• • • •

!

Scrum Production ! ! ! !

34 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

!

How to Play the Game Goal: See how good your team can get at making many airplanes – Each airplane must be made from ¼ of a sheet of Letter/A4-sized paper – Each team member may only do 1 “fold” of the paper at a time. You must then pass the airplane to another team member to do the next fold. – Planes must have a blunt tip (so no injury if hit in the eye) • Each airplane must tested and shown to fly 3 meters in the testing area. – Planes may only be tested once; if it fails, it must be discarded. – Only successfully tested planes count towards your goal. – Work in progress (partially folded airplanes) must be discarded at the end of each Sprint. • Teams are responsible for self-organizing, and deciding among themselves how to manage the work, assign roles, etc. – Teams are not in competition with each other – only with themselves.

35 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

•

36 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

One Person, One Fold

37 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Product Owner Tests

38 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Agile DC ScrumInc Build Party 2013

Amsterdam 32/33

39 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

World Record

Munich 32/32

As a Scrum Master I need to understand

How to Get Started

40 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

in order to begin a Scrum

Scrum is easy to understand but hard to implement

41 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• A systematic approach to implementing Scrum will give you the most benefit fastest for the least effort. • The Shu Ha Ri concept from the martial arts can help.

Aikido

42 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

The Way in Harmony with the Spirit

Making the Most of your Scrum • Shu state • Scrum Master sets up process as in the Scrum Guide. See

43 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

scrumguides.org. Team has a known velocity at a sustainable pace • Retrospective is used to enhance performance • Review Core Scrum at agileatlas.org for Scrum Alliance version of Scrum Guide.

Ha State

44 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Team has software done with all features tested and no bugs at the end of a sprint. • Product owner has ready backlog at beginning of the sprint (good user stories) • Team has data showing velocity and quality has at least doubled. • Team is positioned to work towards hyperproductivity, the design goal of Scrum

Ri State

45 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Teams look different. People will say this is not Scrum • Software delivered multiple times in sprint • ancestry.com goes live 12 times per day • hubspot.com goes live 170-270 times per day

Team of One in Ri State

http://www.youtube.com/watch?v=Hzgzim5m7oU

46 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Team needs to be hyperproductive. • But what does a great Scrum Master do?

47 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

As a Scrum Master I need to understand the Scrum Framework in order to implement Scrum

Scrum Framework Scrum

Product Backlog

Make Work Visible

Product Backlog Refinement Get Backlog Ready

Meeting Deliverables

Social Objects Scrum Board Burndown Points Velocity

Sprint Planning Sprint Backlog

Roles

Scrum Master

Team Ceremonies

Daily Scrum Replan

Sprint Review Product Increment! Velocity! Feedback

Retrospective

Kaizen

© 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Sprint Backlog

Product Owner

Scrum has Three Roles • Product Owner: • Define and prioritize the features of the Product Backlog • Decide on release date and content • Responsible for the profitability of the product (ROI)

• Scrum Master • Facilitates the Scrum process and Team self-organization • Removes obstacles and shields the team from interference • Responsible for improving performance of the team

• Team autonomy regarding how to achieve its commitments • typically 3-9 people 49 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• cross-functional (incl. testing) • self-organizing/-managing group of individuals, has

Scrum has Four Meetings • Sprint Planning • Product Owner presents READY backlog to Scrum Master and Team • Deliverable is Sprint Backlog

• Daily Scrum • Team self-organizes to improve performance • Deliverable is new daily plan for implementation and impediment

removal

• Sprint Review • Team presents backlog that is DONE to Product Owner and Stakeholders • Deliverable is velocity (what Product Owner confirms is DONE), feedback

(used to update Product Backlog), and potentially shippable Product Increment

• Retrospective

50 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Scrum Master and team identify the top process improvement • Deliverable is the KAIZEN to put at top of Sprint Backlog for next Sprint.

Scrum Makes Work Visible • Scrum Artifacts • Product Backlog • Sprint Backlog • Amount of work remaining in Sprint !

• Useful tools • Scrum Board • Burndown Chart • Show work remaining

51 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Helps calibrate velocity

52 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Sprint - Iterative and Incremental

© 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

53

• FOR experienced Scrum practitioners (Jill) who are “in the trenches” • WHO need clear and actionable information to answer specific Scrum questions whenever they arise • ScrumLab is the authoritative, curated on-demand ounce for Scrum Inc.’s leading thinking • That: • Clearly explains Scrum and its underlying principles (i.e. why if works) • Shares successful advanced practices for different contexts • Provides actionable solutions to implement successfully • Is available whenever you need it • Unlike other online Scrum resources • Our product captures decades of successful experience and wisdom from the co-creator of Scrum and his hand-picked team of thought leaders 54 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

ScrumLab Vision Statement

55 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

As a Scrum Master I need to understand Roles & Responsibilities in order to implement Scrum

Scrum Value Courage Commitment Openness Focus

56 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• • • •

Scrum Master Role & Responsibilities Facilitator Knowledgeable about the Scrum process Coach – Team and PO to enhance team performance Removes impediments Protects the team from interruptions Holds Scrum values and practices

57 © 1993-2014 Jeff Sutherland © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• • • • • •

The Scrum Master Owns The Process • Scrum is a simple framework that requires consistent discipline !

• Scrum Master owns the process Facilitates Daily Stand-Up Facilitates Sprint Planning Facilitates Retrospective Protects the team Removes impediments

58 © 1993-2014 Jeff Sutherland © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• • • • •

Product Owner Owns The WHAT • Have a compelling product vision that is executable, generates lots of cash, and arouses passion in the team, company, and customers !

• Build a roadmap for rolling out the vision that everyone can see and sign up for !

• Build a Product Backlog of “enabling specifications” that are “just enough, and just in time.” !

• Spend half the time with customers, sales, and marketing. !

59 © 1993-2014 Jeff Sutherland © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Spend the other half working closely with the team clarifying specifications.

• Delivers: • The right product set to excite customers • At the right time • In the order that maximizes business value

Value

A Successful Product Owner…

Time

!

• Responds dynamically to change faster than competitors • Clarifies customer need to development teams so that uncertainty is removed and developer velocity is maximized !

$ 60 © 1993-2014 Jeff Sutherland © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• The Product Owner is ultimately accountable for winning in the market!

Scrum Master • Works with the Product Owner to: • Find techniques for effective Product Backlog

• • • •

61 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

•

management; Clearly communicate vision, goals, and Product Backlog items to the Team; Teach the Scrum Team to create clear and concise Product Backlog items; Understand long-term product planning in a Scrum environment; Understand and implement the values of the Agile Manifesto; and, Facilitate Scrum events such as release planning

Teams are:

62 © 1993-2014 Jeff Sutherland © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Cross-functional - most members can do more than one thing • Self-organizing - they decide how they will work • Self-managing - they decide how much work they can do in a Sprint • Collaborative - they work together to achieve the Sprint goal • No more than 3 - 9 people

Basic Truths about Teams • Team motivation • People are most productive when they manage themselves. • People take their commitment more seriously than other people’s commitment for

them. • People do the best they can. • Under pressure to “work harder,” developers automatically and increasingly reduce quality.

• Team performance • Teams and people do their best work when they aren’t interrupted. • Teams improve most when they solve their own problems. • Broad-band, face-to-face communications is the most productive way for teams to

work together.

• Team composition • Teams are more productive than the same number of individuals • Maximum effective team size is around 7-8 people.

the work • Changes in team composition reduce productivity. Source: Ken Schwaber

63 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Products are more robust when a team has all of the cross-functional skills focused on

Leadership Responsibilities • Provide challenging goals for the teams • Create a business plan and operation that works • Set up the teams (in collaboration with teams) • Provide all resources the teams need

• Identify and remove impediments for the teams • Know velocity of teams • Understand what slows teams down • Remove waste

64 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Hold Product Owners accountable for value delivered per point • Hold Scrum Masters accountable for process improvement and team happiness

Exercise: Project Manager/Leader

65 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• As a team, write down all responsibilities of a traditional project manager/leader • Put one responsibility on each sticky note • Time: 4 minutes

Exercise: Project Leader • Sort Project Leader responsibilities on sticky notes into these five categories • Product Owner • Scrum Master • Team • Waste • Other !

66 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Time: 5 minutes

Problems with Traditional Project Model

67 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• GANTT charts are unreliable • Too much time is spent trying to unsuccessfully resolve dependencies in the GANTT chart • Project Managers annoy teams by constantly requesting estimate updates in hours • Teams do not take responsibility for the plan • Some of the best people are the Project Leaders who could be doing productive work

Scrum Patterns

As a Scrum Master I need to understand

Common Pitfalls and Solutions

68 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

to enable a high performing team

69 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

It’s all about technique ...

Scrum Patterns - scrumplop.org

70 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• A pattern is a problem statement/solution pair. • It identifies forces that cause the problem • It proposes a common solution that is known to work in at least three different companies. • It is workshopped by Scrum experts and not published until experts agree that its quality and effectiveness are excellent. • It encapsulates the valuable knowledge of the global Scrum community.

Scrum Team Hyperproductive Pattern Language Teams that Finish Early Accelerate Faster • Stable Teams - How you get started • Yesterday’s Weather - How you pull backlog into a sprint • Daily Clean Code - How to get defect-free product at sprint end • Swarming - How you get work done quickly • Interrupt Pattern - How to deal with interruptions during the sprint • Stop the Line - How to deal with emergencies • Scrumming the Scrum - How to ensure you improve continuously

Teams That Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams! 47th Hawaii International Conference on System Sciences (HICSS) ! By Jeff Sutherland, Neil Harrison, Joel Riddle ! January 2014 71 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Happiness metric - How to ensure teams aren’t overburdened

Run a Lean Scrum

As a Scrum Master my Team

needs to have Daily Clean Code

72 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

to double production and quality

73 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Taiichi Ohno’s Taxonomy of Waste

The 7 Wastes of Software Development Features and functions used in a typical system: Partially done work Extra features Lost knowledge Handoffs Task switching Delays Defects

Always 7%

Never 45%

Only 1/5 of the stuff we build is used often or always!

Often 13%

Sometimes 16%

Rarely 19% 2/3 of the stuff we build is rarely or never used!

Source: Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

There is surely nothing quite so useless as doing with great efficiency what should not be done at all. Peter Drucker 74 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• • • • • • •

Systematic Strategy for Lean Level\Dimension Production

Value

Flow

Pull

Perfection

P6 Build Integrity in

P2 Amplify Learning P2 Amplify Learning

P6 Build Integrity In

T19 Refactoring T20 Test

T5 Synchronization T4 Iterations

T18 Conceptual integrity T17 Perceived

T3 Feedback T6 Setbased development

integrity!

Management

P1 Create Value

P4 Deliver Fast

P7 See the Whole

T1 Eliminate Waste

T11 Queue theory

T22 Contracts

T2 Value streams

T12 Cost of delay

T21 Measurement T10 Pull

People

P3 Defer Commitment T7 Options thinking T8 Defer commitment T9 Decisionmaking

P5 Empower team

P5 Empower team

P5 Empower team

P5 Empower team

T16 Expertise

T14 Motivation

T15 Leadership

T13 Self determination

Thinking tools are best transformed by people and projects 75 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Tools divided into three dimensions

Systematic Pilot Results Project effort 100%

100 %

Rework Work

90% 80%

CMMI 50 %

70%

Process focus

69 % 9%

SCRUM

60% 50%

50 %

40%

35 % 4%

50 %

25 %

20% 10% CMMI 1 Source: Systematic Software engineering 2006

10 %

6%

CMMI 5

CMMI 5
 SCRUM

76 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

30%

Impediments Data driven removal of impediments using control charts from 11/2007 Examples on causes: !

Special competencies Disk full Setup misunderstood COTS failed

Root cause analysis of time to fix a bug automatically generates Scrum Master’s impediment list.

77 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• • • •

Daily Clean Code Pattern scrumplop.org !

... bugs turn into features at midnight ... Here we discuss bugs that arise within the sprint. Preexisting bugs should be prioritized by the Product Owner and managed in the Product Backlog. Bugs appearing from outside the sprint such as customer emergencies should be handled by the Illigitimus non Interrupus pattern. It is natural to want to keep a list of bugs. There are several forces that encourage this. • One of the most compelling reasons to put bugs on a bug list is that developers are busy with other tasks, and shouldn’t be interrupted. • Managers can see that adding new features increases revenue, but fixing bugs does not apparently increase revenue. If the team has a fuzzy Definition of Done, work might be considered Done. • Bugs that arrive might be considered low priority, and it’s nice to have a place to put them. • In short, deferring the fixing of bugs until later is borrowing against your future velocity.

Therefore: Fix all bugs in less than a day. 78 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Velocity is limited because a team spends time dealing with too many bugs.

Good Agile: Use Definition of Done to Drive Performance Daily Meeting

R E A D Y Value

Remove Impediments

D O N E

R E T R O S P E C T I V E

Velocity

79 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Sprint

Scrum Patterns

As a Scrum Master I need to encourage

Swarming

80 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

to enable a high performing team

Exercise: Never Keep Customers Waiting

Never keep a customer waiting !

Start early = Finish early

LIS BOB ERI M AR

Dave Lisa

Bob

Eric Maria

81 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

D AV E

Round 2 – Swarming

Limit WIP (work in process) !

Current limit = 1 customer at a time

Dave

L I SA

Lisa

Bob

Eric Maria

82 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Policy

D AV E

83 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Discussion – what was the difference? Why?

Weinberg, Gerald M. (1992) Quality Software Management: Systems Thinking. Dorset House, p. 284. 84 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Weinberg Table of Project Switching Waste

Prioritizing Between Projects Product A

A1

A2

A3

=

A

Product B

B1

B2

B3

=

B

Product C

C1

C2

C3

=

C

Traditional strategy: ”Everything is important! Do it all at once!”

A1

B1

January

C1

February

A2

B2

C2

April

March

May

B

A

A3

B3

C

C3

June

July

June

July

Agile strategy: ”Prioritize & focus!”

A

A

January

A

B B

February

B

B

March

C C April

C

C May

Adapted from Henrik Kniberg 85 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

A

This product rocks!

Swarming

Care about the whole product Boy are we effective as a team!

I’m more efficient if I just do my tasks

Source: Revised after Henrik Kniberg

86 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

T

Not just your little task

87 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Enterprise Level Swarming

88 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

As a Scrum Master I need to manage Interruptions in order for the team to be successful

Illigitimus Non Interruptus Beginning of sprint

Product Backlog

Sprint Backlog

Support

Kaizen

8

8

5

5

5 3 5

5

5 8 5 3

3

5

Management Now

PO

Sales

10

Later

Low Priority On Buffer Overflow ABORT, Replan, Dates Slip 89 © 2011-2014 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

5

90 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

As a Scrum Master I need to optimize Flow in order for the team to be successful

Theory of Constraints – Smooth Flow Goal

PO

T

SM

Problem

Strategy

int

ak

e

ak

e

Typ 2.

Fix

t

ce

int

Typ

x ne

du

se

x Fi

Re

rea

4.

1.

Inc

91 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

3.

Case Study:
 Developing Products >5x Faster

92 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

A real-life example of applying Value Stream Mapping and Scrum to dramatically speed up product development.

Design-ready games

Game backlog

15

8

Sam 1m 2h

4h

6m

Lisa assigns resources 1d

1w

Graphics design 1m

Games out of date ⇒ Missed market windows ⇒ Demotivated teams ⇒ Overhead costs

Sound design 3w

12

Dev 6m

6m

3m (1m+2m) 3.5 m value added time 25 m cycle time

Integr. & deploy

T

3w Process = 14% cycle efficiency

Estimate

w1 w2 w3 w4 w5 w6 w7 w8

2 m cycle time

= 12x faster

Preliminary result 3-4 m cycle time = 6-8x faster

w1 w2 w3 w4 w5 w6 w7 w8 Source: Henrik Kniberg 93 © 1993-2014 Jeff Sutherland © 1993-2013 Jeff Sutherland

© 2014 Scrum Inc.

2d

Concept pres.

Production-ready games

Case Study 
 Take-away Points

w1 w2 w3 w4 w5 w6 w7 w8

• Speeding up product development is often a matter of improving the process rather than adding people. • Value stream mapping is a great tool for spotting bottlenecks • Scrum is a great tool for removing bottlenecks • But beware the trap – suboptimization!! Hey, let’s do Scrum here! Maybe we can cut dev time in half! • The pictures make it look easy.... From 3 months to 1.5 months... • But executing the change is usually hard

2d

1m 2h

Lisa assigns resources 6m

4h

Graphics design

Sound design

1w 1d

6m 1m

Source: Henrik Kniberg

3w

Integr. & deploy

Dev 6m 3m (1m+2m)

3w

94 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Concept pres.

Sam

!

Managing to Learn: Using the A3 Management Process
 By John Shook

Eliminating Challenging Impediments A3 Process

Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System


95 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

By Durward K. Sobek II., Art Smalley

Exercise

96 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Think of the most difficult problem in your company. • Share the problem with the team. • Team pick the most interesting problem to write an A3. • The person with the real problem picked by the team is the Product Owner • Develop an A3 in three short sprints (8 minutes each) that will enable the Product Owner to return to his/her company and implement a countermeasure.

http://www.youtube.com/watch?v=IETtnK7gzlE 97 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Root Cause Analysis

© 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

98

Venture Company Example
 A3 Process Creates Pull-Based Authority Background • Teams not getting software done and tested • Critical components failing every other sprint

P Current Condition • Engineers not working together? • Inability to test causing failure • Waste estimated at 2.1M Euro/year

L

Goal / Target Condition • Clean tested code worked at end of sprint • Cut waste by 90% • Save 1.8M Euro/year while improving quality

A

Root Cause Analysis • Why- engineers had different design concepts • Why- Team members not communicating • Why- Scrum Master not doing good job • Why- No continuous integration • Why- Product Owner focused on new features • Why- Product Owner is CEO

N

Owner: Mentor: Date:

Countermeasures (Experiments) • Meet with board member • Conference call with CEO • Commitment to implement continuous integration • Site visit to demonstrate working processes

Do Confirmation (Results ) • Clean implementation in one month • Velocity of seven teams average increase of 20% • Immediately savings of 1.7M Euro/year • Cost of implementation 3000 Euro for expert consultant

Check Follow-up (Actions) •Introduced prioritized automated testing •Introduced code reviews •Cut deployment time in half •Cut support calls in half •Increased sales A3 Thinking – Durward Sobek

Act 99 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Title: Seven teams failing too many sprints

A3 Template Title: Concise, self-explanatory

Background • Why is this important? • Why should the reader care about this situation and be motivated to participate in improving?

Current Condition • How do things work today? • What is the problem? • Baseline Metrics?

Goal / Target Condition • What outcomes are expected for what reasons? • What changes in metrics can be plausibly expected?

P

L

Owner: Mentor: Date: Countermeasures (Experiments) • Proposed countermeasure(s) to address each candidate root cause. 
 [This should be a series of quick experiments to validate causal model analysis.] • Identify where in the cause/effect model changes are possible and likely to significantly improve the overall situation. • Predict results for each countermeasure.

Do A

N 100

© 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Root Cause Analysis • What is the root cause(s) of the problem? • Use a simple problem analysis tool (e.g., 5 why’s, fishbone diagram, cause/effect network) to show cause-and-effect relationships.

101 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

As a Scrum Master I need to Scrum the Scrum to get an effective Retrospective

Sprint Retrospective What happened?

First story ready for test

New desks installed

Week 1

Half-day nce confere Sam sick

Big argument

Story #25 removed from sprint

Server crashed

LAN shootout

Week 2

New build server

Team flow!

Sprint demo

Week 3

Source: Henrik Kniberg

102 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Sprint planning

Source: Henrik Kniberg

103 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Sprint Retrospective

Sprint Retrospective Velocity

Long term effect

1 2 3 4 5 6 7 8 9 10 11 12 13 Sprint

Effective velocity over time (without retrospectives)

Source: Henrik Kniberg

104 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Effective velocity over time (with retrospectives)

Powering Up the Retrospective • Identify the top process improvement • Create acceptance tests • Put it in the sprint backlog as top priority !

• This is called Scrumming the Scrum !

105 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• An easy way to identify top process improvement is the Happiness Metric

Happier People Function Better

106 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Doctors in a positive mode show three times the intelligence and creativity and diagnose 19% faster. • Optimistic salespeople outsell pessimistic counterparts by 56%. • Happier CEOs are 15% more productive. • Happier managers improve customer satisfaction by 42%. • Research shows that happiness causes better performance

Happiness Metric On a scale of 1 - 5 we rate • How do you feel about your role? • How do you feel about the company? • What would make you feel better? • With data from Happiness Metric, order individual and company improvements by value - then Scrum the Scrum

Vote for highest value

Estimate value 107 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

•

“Rules”

108 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Only address one impediment • Put the kaizen in the backlog for the sprint Scrum the Scrum • Action should usually yield results quickly • Communicate actions (and success or not) back to the Team • And the hardest rule: Use common sense.

0"

© 2011-2014 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

10/27/13"

8/27/13"

6/27/13"

4/27/13"

2/27/13"

12/27/12"

10/27/12"

8/27/12"

6/27/12"

4/27/12"

2/27/12"

12/27/11"

10/27/11"

8/27/11"

6/27/11"

4/27/11"

2/27/11"

12/27/10"

10/27/10"

8/27/10"

6/27/10"

350"

4/27/10"

2/27/10"

12/27/09"

150"

10/27/09"

8/27/09"

6/27/09"

4/27/09"

Results: Scrumming the Scrum Using Happiness Metric Raw Scrum Inc. Velocity History (not adjusted for fluctuation in team capacity by sprint)

300"

250"

200"

16x output with 4x FTEs = 4x

100"

50"

“Scrum is mandatory reading for any leader, whether they’re leading troops on the battlefield or in the marketplace. The challenges of today’s world don’t permit the luxury of slow, inefficient work. Success requires tremendous speed, enormous productivity, and an unwavering commitment to achieving results. In other words success requires Scrum.”! --General Barry McCaffrey ! “Jeff Sutherland has written the essence of Scrum for the masses. In this easy-to-read book, which is filled with lively stories, apt metaphors, and illuminating quotes, Jeff has converted all the ‘tacit knowledge’ he has gained -- as a West Point cadet, fighter pilot in Vietnam, Aikido enthusiast, academic, technology expert, and father of Scrum -- into wisdom. This book elevates Scrum from a fix-it tool to a way of life.”! --Hirotaka Takeuchi, Professor of Management Practice, Harvard Business School ! “Jeff Sutherland's book masterfully speaks truth to the political complexities that easily stand in the way of getting a lot of work done in the least amount of time. He lays out a doctrine of simplicity, showing -- with surprising insight -how to categorize roadblocks, systematize solutions, choose action over prolonged study, and retain the important emotional aspects of work that ground meaningful interactions. The busy professionals who’ll likely be drawn to this book will find not only an effective manual for getting things done but, also, a how-to guide for living a meaningful life.”! --John Maeda, Design Partner, Kleiner Perkins Caufield & Byers ! “This extraordinary book shows a new way to simplify your life and work, increase your focus, and get more done in less time than you ever thought possible.”! --Brian Tracy, bestselling author of Eat that Frog and Time Power ! “Engaging…Sutherland tackles the problem of the perennially late, over-budget project—and actually shows how to solve it. His fascinating examples of rescued projects will change the way you think and act."! --Dorothy Leonard and Walter Swap, authors of Deep Smarts: How to Cultivate and Transfer Enduring Business Wisdom ! “Jeff Sutherland is the master of creating high-performing teams. The subtitle of this book understates Scrum’s impact. If you don’t get three times the results in one-third the time, you aren’t doing it right!” --Scott Maxwell, Founder & Senior Managing Director, OpenView Venture Partners

110 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Preorder discounted new Scrum book on Amazon or Barnes and Noble! Get free signed copy of Power of Scrum!

SCRUM: TWICE

THE

WORK

Sébastien Chabal

IN

HALF

THE

TIME 111 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Preorder and get free Power of Scrum

© 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

112

113 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

As a Scrum Master I need to Run a Good Daily Meeting to help the Team improve performance

Motivation for Daily Scrum

% Saturation

120 100

Bell Labs Pasteur Project! 82 Companies

80 60 40 20 0 0

20

40

60

80

Communication Saturation and Roles. Organizational Patterns of Agile Software Development by Coplien and Harrison (2004) 114 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Number of Roles

115 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

All Blacks, New Zealand http://www.youtube.com/watch?v=0C434QFTjok

Purpose of Daily Scrum Build team focus All arms linked - intense collaboration Mental attitude - we will crush impediments Create team spirit

116 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• • • •

Daily Scrum Meeting 15 minutes

•

What  did  I  do  yesterday  that  helped  the  Team  meet  the  Sprint  goal?  

117 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

•

What will I do today to help the Team meet the Sprint goal? •

Do I see any impediment that prevents me or the Team from meeting the Sprint goal?

Brooks Law: Adding People to a Late Project Makes It Later

3-5

5-7

9-11

15-20

• Optimal team size is 4.6 people according to Harvard research.

Source: http://www.qsm.com/process_01.html (491 projects)

118 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

1.5-3

Scrum of Scrums

Waterfall Comm Paths! n(n-1)/2 for 120 people! 120(119)/2 = 7140! !

Communication Paths! n(n-1)/2 per team! 5(4)/2 = 10! 24 teams(10) = 240! + a few cross team! 80% less comm 119 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Scrum is an object-oriented organizational framework! • The organization will need to be refactored to maximize flow! • Small steps regularly! • Large changes periodically

Manufacturing Scrum of Scrums First Zero Defect Release

After failed software releases we adopted a program Scrum-Of-Scrums… ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! -Very uncomfortable for people in the beginning -Huge impact on communications and problem resolution

!! ! “I was reluctant at first but the Daily Scrum of Scrums was the key reason this is the best launch in our history...”

Adapted from Slides By Chris Sullivan 120 © 1993-2013 © 1993-2012Jeff JeffSutherland Sutherland © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Manufacturing Manager

!

121 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

As a Scrum Master I need to act on Scrum Board Warning Signs in order to improve team performance

Visual Flow Tools • Principle 7 of the Toyota Way is to use visual control to improve flow • Visual control is any communication device used in the

work environment that tells us at a glance how work should be done and whether it is deviating from the standard. • It helps employees who want to do a good job see immediately how they are doing.

• Scrum artifacts are visual flow tools • The Scrum Board is not a core artifact in the Scrum Guide.

122 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Yet it is an extremely useful tool used by almost all Scrum teams.

© 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

123

Sprint: Day 0 To Do:

Doing:

Sprint Goal: Get a ready release!

Done!

Burndown

Daily Clean Code

3pts

Kaizen

100

Buffer 33

Deposit

90 80

Points

70

code write a failing cleanup. 2 test.. 2 pts.pts

Integration test

2 pts

DAO

3pts

60 50 40 30 20 10

Backend Login Backend User Admin

write a failing pts.

Miigration 8 pts test.. 2

0

Days

Implement Integrate w// GUI

boss

5 pts 8 pts

GUI design

Clarify Req

write a failing 5 ptsImplement 3 pts test.. 2 pts.

GUI

5 pts

124 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Migration Tool

Tapestry ry spike

code write a failing 8 pts cleanup. 2 test.. 2 pts. GUI spec

Miigration 8 2 pts pts pts

Sprint Backlog: After First Meeting To Do:

Doing:

Sprint Goal: Get a ready release!

Done!

Burndown

Daily Clean Code

3pts

Kaizen

100 90

Buffer 33

70

code cleanup. 2 pts Integration test

2 pts

write a failing test.. 2 pts.

DAO

3pts

DB Design

3pts

Points

Deposit

80

60 50 40 30 20 10

Tapestry ry spike

8 pts

code cleanup. 2 pts Miigration 8 pts

Backend Login

write a failing test.. 2 pts.

Backend User Admin

GUI design

Clarify Req

5 ptsImplement 3 pts write a failing GUI

test.. 2 pts.

5 pts

write a failing test.. 2 pts.

0

Days

Integrate w// boss

Implement 8 pts GUI

5 pts

125 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Migration Tool

GUI spec 2 pts

Sprint Backlog: Day X To Do:

Doing:

Sprint Goal: Get a ready release!

Done!

Burndown

Daily Clean Code

3pts

Kaizen

100

Buffer 23

90

Sales Support

3pts

Fix Bug

2 pts

White Paper

5 pts

80

Deposit

code write a failing cleanup. 2 test.. 2 pts.

pts DB Design

3pts

Integration DAO

test

3pts

2 pts

Points

70 60 50 40 30 20 10

Backend Login Backend User Admin

code cleanup. 2 pts

Miigration 8 pts

Integrate w// boss

Implement Miigration 8 pts GUI

8 pts 5 pts

write a failing Tapestry ry spike

test.. 2 pts.

8 pts

GUI spec 2 pts

0

Days

write a failing test.. 2 pts.

GUI design

Clarify Req

5 ptsImplement 3 pts write a failing test.. 2 pts.

GUI

5 pts

126 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Migration Tool

127 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Scrum Board Warning Signs

Warning Sign #1 To Do: Kaizen

Doing:

Sprint Goal: Get a ready release!

Done!

Burndown

Daily Clean Code

100 90

Buffer 33 Deposit

80

Points

70

code cleanup. 2 write a failing pts DB Design

test.. 2 pts.

Integration 3pts

DAO

test

3pts

2 pts

60 50 40 30 20 10

Backend Login

GUI spec 2 pts Tapestry ry code spike

cleanup. 2 pts 8 pts

write a failing test.. 2 pts.

Miigration 8 pts

Implement GUI

5 ots

0

Days

Integrate w// boss

8 pts

write a failing test.. 2 pts.

Backend User Admin

GUI design

Clarify Req

write a failing 5 ptsImplement 3 pts test.. 2 pts.

GUI

5 ots

© 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Migration Tool

Warning Sign #2 To Do:

Doing:

Kaizen

Sprint Goal: Get a ready release!

Done!

Burndown

Daily Clean Code

100 90

Sales Support

3pts

Deposit

code cleanup. 2 write a failing pts DB Design

test.. 2 pts.

Integration 3pts

DAO

test

3pts

2 pts

Marketing Demo

5 pts

Fix Bug

2 pts

Fix Bug

2 pts

White Paper

5 pts

Customer Down!

13 pts

80 70

Points

Buffer 3

60 50 40 30 20 10

Backend Login Backend User Admin

code Tapestry ry cleanup. 2 spike

pts 8 pts

Integrate w// Miigration boss

8 pts 8 pts

write a failing test.. 2 pts.

write a failing test.. 2 pts.

Miigration 8 pts

0

Days

write a failing Implement GUI

test.. 2 pts.

5 ots

GUI design

Clarify Req

5 ptsImplement 3 pts GUI

5 ots

129 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Migration Tool

GUI spec 2 pts

Warning Sign #3 To Do:

Doing:

Sprint Goal: Get a ready release!

Done!

Burndown

Daily Clean Code

Kaizen

100

Migration Tool

Backend Login Backend User Admin

White Paper

5 pts

write a DB Design

failing test.. 2 code 3pts

cleanup. 2 DAO

pts.

pts 3pts

Integration test

2 pts

80 70 60 50 40 30 20

write a failing test.. 2 Miigration 8 pts.

pts

code cleanup. 2 pts

Implement GUI

5 ots

Miigration 8 pts

GUI design

5 ptsImplement GUI

5 ots

GUI spec 2 pts Tapestry ry spike

8 pts

10 0

Days

write a failing test.. 2 Integrate pts.

w//boss

8 pts

Clarify write Req

a failing 3 pts test.. 2 pts.

130 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Deposit

Fix Bug

2 pts

90

Customer Down!

13 pts

Points

Buffer Buffer 12 33 Points

Source: Jim Coplien

131 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Swimlane Scrum

Scrum Board Contest Winner

132 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Scrum Board on Steroids

Teams That Finish Early Accelerate Faster scrumplop.org

Daily Meeting

R E A D Y Value

Remove Impediments

D O N E

R E T R O S P E C T I V E

Velocity

133 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Sprint

134 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Product Backlog and User Stories

Product Backlog

135 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• The Product Backlog consists of work to be done ordered by business value • Anyone can put anything on the backlog • Product Owner is the final authority on ordering the backlog. • The backlog consists of Product Backlog Items (PBIs) • The majority of Scrum teams use User Stories as PBIs.

User Story

136 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• A UserStory is a story, told by the user, specifying how the system is supposed to work, written on a card, and of a complexity permitting estimation of how long it will take to implement. • The UserStory promises as much subsequent conversation as necessary to fill in the details of what is wanted. • The cards themselves are used as tokens in the planning process after assessment of business value and [possibly] risk. • The customer prioritizes the stories and schedules them for implementation. -- RonJeffries

User Story Templates

137 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• As a I would like to be able to to achieve

138 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

What’s Wrong with This Story?

Break Epics into Stories

As a frequent flyer I want to easily book a trip I take often So that I can save time As a premium frequent flyer I want to request an upgrade So I can be more comfortable 139

© 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

As a frequent flyer I want to book flights customized to my preferences, so I save time

As a frequent flyer I want to book a trip using miles so that I can save money

User Story - Guidelines Product vision

Product Backlog

A B C

Immediately actionable Negotiable Valuable Estimable Sized to fit Testable Modified from Bill Wake – www.xp123.com

A B C !

• Customer facing value delivered every sprint !

• Slices accumulate in value

GUI

Client Server DB schema

Stuff not needed 140 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• User Stories slice through all layers

One Company’s Definition of Ready!

141 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

User Story, Acceptance Tests, Examples, Wire frame, Estimates

User Stories Improve Communication Effectiveness 2 people at whiteboard

Effective

Google Hangout 2 people on phone Communication effectiveness

Cold

o

ti s e

r) e w

s

o

ti s e

u q o N (

an n

Richness (”temperature”) of communication channel

Hot

Source: research from McCarthy and Monk (1994)

142 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Document

an n

u Q (

2 people on email

Ineffective

s n a d-

Video recording

Audio recording

)

r e w

Irrelevant Information Spec 1

Same spec + irrelevant details

A B

A

C

B C

20 hrs 39 hrs SM

Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006

143 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

SM

• User stories notes may be enough for a web site • For a complex system you need enabling specification • Short - 3-5 pages for a feature • Usually a lightweight use case • Product Owner documents critical information in collaboration with team • User experience (design) • Business logic • Data structures • Stories are derived from the enabling specification • The enabling specification is a living document • Updated over time • Global picture of the feature • Allows traceability of stories back to product design 144 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Enabling Specification

Use the Definition of Ready to Improve Team Performance Daily Meeting

R E A D Y Value

Remove Impediments

D O N E

R E T R O S P E C T I V E

Velocity

145 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Sprint

146 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Create User Stories Exercise

Exercise Background • General situation • Today is Jan 1. • The government has announced Outlook will be outlawed from April 1 to save money! • We are greatsoftware.com • Our goal: • Create ”bookmeeting.com” an online resource booking service targeted

primarily towards those that use Outlook for booking meeting rooms. • March 1: Pilot customer will start using it. • April 1: Commercial rollout.

• Our context: • We have built similar services before, so we have a functioning team,

development environment, and operational environment. • This project is top priority, we have a 5-person Scrum team ready to start

Source: Henrik Kniberg

147 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

today.

•

Product Vision • Welcome to bookmeeting.com! It doesn’t get any simpler than this. • Getting started guide: • Create an account at bookmeeting.com • Set up rooms • Your company can now surf

to bookmeeting.com and book meetings! • Payment • Pay per month (rate may vary depending on number of rooms)

Roles Booker Creates and administrates the meeting booking, invites participants Participant Attends meetings. Receives invitations & updates. Admin Sets up rooms and users. Buyer Buys the service and pays for its use. Seller Hosts the service and charges for it use. Initially greatsoftware.com.

Source: Henrik Kniberg

148 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Bookmeeting.com

Exercise • Goal: Pile of users stories • Acceptance criteria for one story !

• Time: 10 minutes

Write on sticky notes. Use a thick pen. Use the story template. As a X I want Y so that Z As a X I want Y As a X so that Z I want Y so that Z As a X I want Y As a Xso that Z I want Y As a X so that Z I want Y As a X so that Z I want Y so that Z

As a X I want Y so that Z

149 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Create product backlog

As a Scrum Master I need to know how to go from

150 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Waterfall to Scrum in order to do my job

Case Study
 Stopping a Death March

151 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

This is the real story and not for public consumption! It demonstrates: 1. How to fail with Scrum 2. How to rescue a failed Scrum 3. How to convert a waterfall team into a Scrum team

Symptom: Waterfall process (under Scrum banner)

2006

2007

Requirements Coding

Release Testing?

Q2

Q3

Q4

Q1

Q2

We are here

152 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Q1

153 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Symptom: Long, detailed requirements specifications

154 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Symptom: Lack of trust & commitment

Strategy: Implement Scrum Create product backlog Estimate product backlog Execute 2 sprints, measure velocity

• •

Show us where we stand Help us move faster

2007

Feb

We are here 155 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Jan

Step 1: Change Definition of Done Old definition of done:

• •

New definition of done: •

Releasable

Tester added to team

156 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

•

•

Code checked in

Step 2: Create a product backlog feature X

feature X

feature X

feature X

feature X

feature X

feature X

feature X

Features implemented but not tested & integrated

feature X

feature X

feature X

Test/integr feature Y

feature X

Test/integr feature Y

feature X

Test/integr feature Y

feature X

Test/integr feature Y Test/integr feature Y Test/integr feature Y

Test/integr feature Y

feature X

Test/integr feature Y

feature X feature X

feature X

Test/integr feature Y

Test/integr feature Y Test/integr feature Y Test/integr feature Y

Test/integr feature Y

feature X feature X

feature X

Test/integr feature Y

feature X

Test/integr feature Y

Test/integr feature Y

Test/integr feature Y

Test/integr feature Y

Test/integr feature Y

PO

157 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Features left to implement

Barry Boehm. Cost Estimation with COCOMO II. CS 577a, University of Southern California, Center for Software Engineering. Fall 2006!

158 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Software Estimation Error

Points vs. Hours • Rand Corporation received a grant from U.S. DOD in the 1940’s to determine best way to estimate tough projects • Discovered estimation in hours has high error rate and wide variance • Found people could put things in relative size piles best • Experts need to estimate independently - avoid anchoring

• Fibonacci growth pattern easiest for humans • Seen everywhere in nature

159 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• RAND called it the Delphi technique

Why Points are Better Than Hours Cone of Uncertainty

Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan (2012) Scrum + Engineering Practices: Experiences of Three Microsoft Teams. IEEE Best Industry Paper Award, 2011 International Symposium on Empirical Software Engineering and Measurement. 160 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Gray Line - Hours Red Line - Points

Anchoring

456 hrs

Same spec

Same spec

500 hrs Never mind me

PO

50 hrs Never mind me

PO

555 hrs

99 hrs

SM

SM

SM

Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006

161 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Spec

The Fibonacci Sequence Barry Boehme called it the Wideband Delphi Technique for software http://www.youtube.com/watch?v=ahXIMUkSXX0

162 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• •

As a Scrum Master I need to know how to

Estimate Stories

163 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

in order to know velocity and pull the right ! amount of work into a sprint

Agile Estimating Strategy • Don’t estimate time • Estimate relative size of stories • Measure velocity per sprint

• Estimates are done by the people who are going to do the work • Not by the people who want the work done • Team allocate 10% of sprint time to Product Owner

164 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Estimate continuously during the project, not all up front • Prefer verbal communication over detailed, written specifications

• Estimate stories • Pick smallest story and give it 3 story

points • Estimate relative size of other stories • Discuss outliers and vote again until all numbers are within 3 cards, then average. !

TIME: 10 minutes

As a X I want Y 2 so that Z As a X I want Y 3 so that Z As a X I want Y 5 so that Z As a X I want Y 1 so that Z As a X I want Y 2 so that Z As a X I want Y 5 so that Z As a X I want Y 13 so that Z 165 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Exercise

As a X I want Y 8 so that Z

166 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Case Study Continued

Step 3: Estimate product backlog Features left to implement

Features implemented but not tested & integrated

Total:
 180 points

2

Total:
 70 points

2 5

2 3

167 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

?

Step 4: Execute 2 sprints Actual Velocity

Sprint 1

30

9

Sprint 2

25

10

168 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Estimated Velocity

Step 5: Face reality & Revise the plan

Backlog = 250 points

Velocity = 10 points/sprint 2007

Q1

25 sprints

2008 Earliest

Promised release

Q2

> 1 year until release!

likely release

Q3

Q4

Q1

Q2

169 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

We are here

Step 6: Act Reduce

Reduce total scope Incremental releases

!

Overall priorities 1. Operations 2. Project X 3. Anything else

!

!

Backlog = 250 points Velocity = 10 points/sprint

170 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Increase

Fix impediments Pressure on team Ineffective build & test environment Lack of teamwork, discipline & motivation Disruptions & context switching Unrealistic expectations ROOT CAUSE: Company not focused

Result

Originally promised release (big-bang)

2007

Q1

Q2

Velocity 30

2008

estimated

Earliest likely release if process hadn’t changed
 (big-bang) Q3

Q4

Actual release (incremental)

Actual release (incremental)

Q1

Q2

25-30

20 actual 9-10 Q1

Q2

Q3

2007

171 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

10

Case 3: Take-away points •

•

•

•

•

Waterfall is still waterfall even if you call it Scrum • Know your tools, get training & coaching early. Don’t believe your plan • There is no ”the plan must be right because we promised”. • Make sure you have reliable feedback loops & a changeable plan. There is no ”too low velocity” • Just actual velocity, and a realistic or unrealistic plan. Build quality in • Don’t postpone test & integration, that gives a false velocity. Having good people isn’t enough • An inappropriate process can cause even a great team to fail. Dramatic improvements can be made quickly • With a strong management team that has access to empirical data and is willing to focus.

172 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

•

173 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

As a Scrum Master I Need My Team to Work with the Product Owner to Refine the Product Backlog

Register new user

Register new user

Edit existing user

Edit existing user

Find user

View Invoice in HTML, PDF, or Excel format

View Invoice in HTML, PDF, or Excel format

Delete user

As a helpdesk operator I want to see who is logged in

As a helpdesk operator I want to see who is logged in

View Invoice in HTML, PDF, or Excel format

Find user

Administrate users

Operations manual 100 simultaneous users

As a helpdesk operator I want to see who is logged in

Operations manual 100 simultaneous users Source: Henrik Kniberg

Operations manual 100 simultaneous users Delete user

174 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Product Backlog

Splitting Stories and Breaking Out Tasks Break into tasks (normally during sprint planning meeting) Split stories

5

User admin

REgister new user

User admin

Administrate users

Create DB schema

Write form validation

Do GUI design

Write serverside logic

Do integration test

3

User admin

2

User admin

8

Edit existing user

Delete user

Source: Henrik Kniberg

175 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

13

Find user

Write failing test

Definition of Done

Default Definition of Done

• Unit/Integration tested

• Ready for acceptance test

• Deployed on demo server

= I haven’t messed up the codebase

What’s else must be done before shipping the code? - For example ”customer acceptance test + user documentation” Why not? Who does it? When? What happens if a problem turns up? Burn up this work in release burndown! Source: Henrik Kniberg

176 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Default Definition of Done

• Releasable

Default Definition of Done

• Acceptance tested

• Release notes written

• Releasable

• No increased technical debt

Burndown Strategies • Burndown number of stories completed • stories must be small and of similar size • not recommended for new teams

• Burndown stories only in points • stories must be small

• Burndown tasks in points • spread points from stories across tasks - keep it simple

• Burndown tasks in hours • Scrum Foundation and ScrumInc. no longer view this as best

177 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

practice

As a Scrum Master I Need to Know How to Do

Release Planning

178 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

to Deliver Working Product to End Users

Product Owner Responsibility • Get one sprint READY backlog • Team can get started

• Get two sprints READY backlog • Team can accelerate sprint to sprint

• Build out Release Plan • Company can predict revenue

• Build one year roadmap

179 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Customers can be briefed on company strategy

Release Cycles • Goal: every sprint results in potentially releasable product increment. • Product owner decides when to release.

Sprint #

1

2

3

4

5

Release 2 (Beta)

6

7

8

9

10

Release 3 (Live)

11

12

Source: Henrik Kniberg

13

Release 5 Release 4 (maintenance)(maintenance)

14

15

16

17

18

19

Release 6 (maintenance)

20

180 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Release 1 (Alpha)

Backlog Maintenance

2009

Apr 2008 May 2008

June 2008

2010

Q3 2008

Q4 2008

2011

2009

2012 181 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

V

V

T

V

V

Release Planning Prerequisites • Vision for release • Product backlog prioritized and estimated • Historical data • • • •

Velocity of teams Emerging requirements Undone work Customer feedback that must be dealt with immediately after release

182 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• If historical data is not available, velocity, emerging requirements, and undone work must be estimated after the first few sprints

Release Planning Meeting Participants • Includes stakeholders, Product Owner team, and all parties that execute the release • Scrum Masters and cross functional teams • Third party team teams (waterfall teams or external

vendors) • Sales, marketing, and operations

183 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Could be half a day for small release with Ready backlog • Could be multiple days for large release or backlog that needs refinement

Release Planning Agenda • Background, business and competitive climate (PO) • Release goals (PO) • Current product and development state (PO)

• Product Backlog refinement for release (All) • Capture and discussion of issues (All) • Technical Issues (Dev teams) • Technology • Testing Challenges and Strategies • Dependencies • Engineering Standards and Practices • Hardening and Hackathon • Development regimen • Build • Test • Continuous integration • Scrum of Scrums • Special handling of multi-team Sprint Planning, Sprint Reviews • Multi-team retrospectives

• Tentative schedule (PO) 184 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Team interactions (Dev teams)

Measuring Velocity Beginning of sprint

Product Backlog

End of sprint

Sprint Backlog

Sprint Backlog

8 5 5 3 5 5

Done!

8 5 5 3 5

Estimated velocity = 26

Done! Done! Almost done Not started

8

Actual velocity = 18

5 5 3 5

8

185 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

5 3 5

Release Burndown Chart Key to 
 On Time Project Delivery • Answers the key question “Will we be done on time?”

Work remaining   (story points)

!

• Useful for “what if?” analysis and managing tradeoffs of Scope, Velocity and Time

400

300

200

!

• Vital for identifying and addressing unreasonable expectations

100

1

2

3

4

5

6

7

8

9 10 11 12 13 14 15 16

Sprint Source: Henrik Kniberg

186 © 1993-2014 Jeff Sutherland

Critical Estimates for Release Date • • • • •

Product Backlog Estimates (based on Definition of Done) Undone Work (anything beyond DoD needed to deploy) Emerging Requirements (historical data) Customer Issues post release (historical data) Example: • For a healthcare company in Houston, for every 100 points

estimated there are 20 points of undone work (User Acceptance Testing) plus 40 points of emerging requirements plus 60 points of customer feedback when new features go live for the first time. • Plan must include 100+20+40+60 = 220 points for every 100 points of initial estimate

187 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Release plan must be updated based on real data after every sprint

188 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Acceptance Tests

Modern Agile Acceptance Model • The move toward Acceptance Test Driven Development requires a more complete model of progressing requirements acceptance • Example model (sharper definition of done) • Conditions of Satisfaction - broad terms

189 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Acceptance Criteria - further refined • Examples - actual scenarios or data • Executable Examples - Executable Spec

Simple Scenarios • Suppose we are creating a registration function • It consists of specifying email (as User ID) and Password

Enter your Email and Password to Register Email Address: Password:

190 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Register

Acceptance

Condition of Satisfaction • Conditions of Satisfaction are high level criteria established with an initial Epic/Feature/User Story • In our previous example, the conditions of acceptance for

the password would be:

• Ensure the password is not easy to crack.

• The PO would define the conditions of acceptance in concert with business stakeholders

Email Address: Password: Register

191 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Enter your Email and Password to Register

Acceptance

Examples Make It Real • Actual examples are the ultimate way to communicate requirements: Password

Expected

Expected Message

abc123

Invalid

abcdefghi !

Invalid

Your password must be at least 8 characters and no more than 12 charcters long Your password must contain at least one character and one number

! !

1aaaaaaaa Valid ! ! ajx972dab

Comment

Why valid?

Valid

• The PO works closely with a tester, developer, and business stakeholder to define these criteria 192 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

!

Acceptance

Acceptance Criteria • Acceptance Criteria specifies the details that the team can then build against: • Following the example for Password: • Must be at least 8 characters and no more than 12 • Must contain only alpha-numberics and the period • Must contain at least one digit • Must contain at least one character • Etc. (there may be more criteria)

Enter your Email and Password to Register Email Address: Password: Register

193 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• The PO works closely with a tester, developer, and business stakeholder to define these criteria

Acceptance Test Driven Development (ATDD) Tools: Fit and Cucumber

•

Cucumber New tool for natural language scenarios

numerator

denominator

quotient

10

2

5

12.6

3

4.2

100

4

25 expected 24 returned

In order to ensure my account is correct As a Registered User I want to check my recent activity ! Scenario: Recent Account Activity Given I am a registered user “Jsmith” And I am logged in with password “xyx123” And I have had account activity in the last 45 days And I am on the home page When I click the “Recent Activity” button Then I should see the “Account Activity” Page And I should see a list of my activity over the last 45 days ! Scenario: No Recent Account Activity Given I am a registered user “Jsmith” And I am logged in with password “xyx123” And I have had account activity in the last 45 days And I am on the home page When I click the “Recent Activity” button Then I should see the “Select Account Activity Period” Page And I should get a message: “You had no activity in the last 45 days, please select a time frame to review” 194 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• • •

FIT (Framework for Integrated Test) and Fitnesse (Wiki front end) Test specified in table format Developers generates classes (“fixtures”) to hook into application Users/testers use Wiki or Excel to specify inputs and outputs

195 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Prince 2

What Is PRINCE2? • Process driven Project Management method • Describes procedures to coordinate people and activities in

a project

• A project has a clear start and end • Goal: deliver product according to business case

• Projects are split in stages

Source: Marco Mulder

196 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• At the end of each stage, verify if business case is still valid • If not: terminate

197 Rev. 2013 - 01

Rev. 2013 – 08

10 September 2013

198 Rev. 2013 - 01

Rev. 2013 – 08

10 September 2013

9

199 Rev. 2013 - 01

Rev. 2013 – 08

10 September 2013

SCRUM FLOW AND PRINCE2


Stage Plan PID

Project Brief

Project Mandate

Notification Highlight Next Stage Report 200

Rev. 2013 - 01

Rev. 2013 – 08

10 September 2013

12

201 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Velocity and Technical Debt

Clean & Simple Code

import java.sql.Connection; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors;

! !

public class Dog { private Executor executor = Executors.newFixedThreadPool(18); private int CACHE_SIZE = 50; public Dog() { try { Class.forName("oracle.jdbc.ThinDriver"); connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); } catch (ClassNotFoundException e) {}

! !

new Thread().start(); }

public class Dog { public static void main(String[] args) { System.out.println("WOOF 1!"); System.out.println("WOOF 2!"); } }

public void woof(Person woofCaller) { Connection connection = null; PreparedStatement statement = null; try { connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); statement.setLong(1, System.currentTimeMillis()); statement.setString(2, person.getName()); statement.setString(3, person.getPhoneNumber().getNumber()); statement.executeUpdate(); } } } } Connection a = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); b = a.prepareStatement("select * from Dog where name = '" + name + "'"); c = b.executeQuery(); if (c.next()) { String foundName = c.getString("name"); PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount")); Person person = new Person(foundName, phoneNumber); return person; } else { return new Person("", null); }

!

} catch (SQLException e) { return null; } catch (IllegalArgumentException x) { throw x; } }

!

public List getAll() { connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); statement.setLong(1, System.currentTimeMillis()); } if (statement != null) { if (c.next()) { String foundName = c.getString("name"); PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount")); Person person = new Person(foundName, phoneNumber); return person; } else {

Simple code: 1.Passes all tests 2.No duplication 3.Readable 4.Minimal !

Source: Henrik Kniberg

202 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Simple is hard!

Velocity Calibration Actual Velocity

40

30

40

30

28

40

30

31

40

30

30

Estimated 40 50 60

Actual 30 30 30

Estimated

Estimated

Actual 30 30 30

Actual

30 40

35

25 35

30

20 30

25

Source: Henrik Kniberg

203 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Estimated Velocity

Technical Debt & Release Planning Remaining story points 400

We’ll be done by sprint 10!

300

Sorry, we’re late!
 We should definitely by done by sprint 12!

200

Um... we’re done when we’re done!

100

2

3

4

5

6

7

8

9

10

11

12

13 14

15

Sprint

Source: Henrik Kniberg

204 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

1

Technical Debt

Vmax Vactual

Sustainable pace!

time

time Source: Henrik Kniberg

205 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

velocity

velocity

Vmax Vactual

Code duplication Test coverage Code readability

Definition of Done! • .... bla bla ....! • No increased technical debt

Dealing with Technical Debt

Ro a

d

to

Definition of Done • .... bla bla .... • Technical debt decreased

he

ll ! e c a p g in s a e Incr

Sustainable pace

First step Slow down Stop accumulating debt

Second step (optional)

Slow down even more Start repaying debt

time Source: Henrik Kniberg

206 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

velocity

Vmax Vactual

Definition of Done • .... bla bla .... • No increased technical debt

Gartner - Technical Professional Advice 2012 Planning Guide: Application Delivery Strategies

207 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Business users are losing patience with oldschool IT culture. Relationships are tense and resentful. Legacy systems and practices impede agility. Bottom line - GET AGILE • Adopt a product perspective. • Say goodbye to waterfall. • Improve cross-competency collaboration. • Launch a deep usability discipline. • Start a technical debt management program.

© 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

208

© 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

209

210 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Sprint Planning

Sprint Planning Meeting Goal: xyz Sprint 1 Backlog

Jackass team, sprint 15 !

Sprint goal - Beta-ready release! !

Sprint backlog - Deposit (5) - Migration tool (13) - Backoffice login (3) - Backoffice user admin (5) (Estimated velocity = 26) !

Schedule - Sprint period: 2006-11-06 to 2006-11-24 - Sprint demo: 2006-11-24, 13:00, in the cafeteria - Daily scrum: 9:30 – 9:45, in conference room Jimbo !

Team - Jim - Erica (scrum master) - Tom (75%) - Niklas - Eva - John

211 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Product Backlog

Why is it important that the team AND product owner attend the sprint planning meeting?

Scope

PO

As a helpdesk operator I want to see who is logged in

Priority

PO

212 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

SM

Cost

Sprint Planning Meeting Example • Goal Less important More important • Present product backlog e c i B f a c f k o o f k f c i c a e Withdraw Migration B • Reprioritize, re-estimate, split/combine stories t i s Encrypted o Dep P e r f T T e s t T logTin User aTdmin tool Password T 20 8• Break out 13 tasks 3 13 8 Write failing • testEstimate draw the line User velocity, Transaction

T T 8h T 4h

Integr Test

DB design

2h

Refact.

T Migration 5 tool

T Migration 5 tool

GOAL: Beta-ready release!

213 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

T 12h Impl. DAO

T

8h

The Sprint Commitment Team’s commitment to the Product Owner: “We promise that ...” • We believe we can reach the sprint goal. • We will do everything in our power to reach the goal and will inform you immediately if we have problems. • Code will be potentially shippable at the end of the sprint. • If we fall behind schedule we will remove the lowest priority stories first. • If we get ahead of schedule we will add stories from the product backlog in priority order. • We will display our progress and status on a daily basis. • Every story we do is complete. • Caveat • Estimates are estimates. We will be early some times and late other times. We will document this normal variation with our sprint velocity.

214 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• •

Sprint Demo What have we accomplished?

• Team demonstrates working code to stakeholders • Only 100% completed stories are demonstrated • Partially complete stories are ignored

215 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Direct feedback from stakeholders • Feedback incorporated into the product backlog

Can We Talk About Other Things? • Yes. • But talk is cheap (and easy to misunderstand)

• Yes. Velocity and its meaning Meaning of progress to date New Release plan Etc, etc, etc

216 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• • • •

Testing – Ideal Case

End users

v1.0.0

Sprint 1

Sprint 2 Timeline

Source: Henrik Kniberg

217 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Scrum team

v1.1.0

Testing – Common Alternative End users

v1.0.1

Acceptance test team

1.0 acceptance test

Bug! v1.0.0

Scrum team Sprint 1

v1.0.1

v1.1.0

Sprint 2

218 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Timeline

219 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Scaling

Microsoft Scrum - 3000 people! Deploys live at end of every sprint Product Owner

220 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Engineering Practices

221 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Linear Scalability

222 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Engineering Practices and Scrum

Scrum

Scrum & XP Team

Daily Scrum XP

Sprint backlog

Whole team Collective ownership

Product backlog

Product owner

Customer tests

TDD

Pair programming

Continuous Integration

Simple design

Coding standard

Refactoring

Burndown chart

Planning Sprint game Planning meeting

Sustainable Pace

Metaphor

Sprint Review Source: Henrik Kniberg

223 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Scrum Master

Small releases

Feedback Cycles


Sprint demo Daily Scrum Continuous integration

Unit test

Source: Henrik Kniberg

224 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Pair programming

© 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

225

Scrum Team Exercise

As a class group we need a

Course Review

226 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

in order to retain knowledge

© 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

227

XP Game - Preplanning • Elect a Product Owner (PO) and Scrum Master (SM) in each team • PO fetch product backlog • SM fetch props • For each story in backlog: • Team estimates relative complexity


(story points) • PO prioritize stories

228 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Teams estimates how many cards can get done in sprint

229 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Agile DC ScrumInc Build Party 2013

Next Steps

As a class group we need a

Course Retrospective

230 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

in order to wrap up effectively

For those who want certification ... !

231 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

• Read agileatlas.org on Core Scrum and the Scrum Guide at scrumguides.org before taking the test. • You will receive email from the Scrum Alliance with login instructions to take the test. • Students who pass the test will receive a list of missed questions with correct answers highlighted. • Students who fail will receive a list of missed questions without answers. • The test can be taken one additional time at no charge. After that a fee of $25 per additional attempt will be charged. • A passing score is a least 24 out of 35 questions correct.

http://www.youtube.com/watch?v=u6XAPnuFjJc 232 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

Motivate your teams

Stay Connected Our Website  

•

check in for announcements, new content and services, book releases, and more! • for step by step implementation of Scrum use the Scrum Handbook • www.scruminc.com/scrumhandbook.pdf   • www.scruminc.com/csmjsv18.pdf for this deck   •

ScrumLab  

• • •

!

articles, videos, papers on all things scrum   scrumlab.scruminc.com  

Blog  

• •

!

scrum.jeffsutherland.com  

Online Courses  

• •

advance your learning with our interactive online courses. visit the scrumlab store to view upcoming topics.  

!

Twitter, Facebook, and G+  

• •

@jeffsutherland, scrum and scrum inc. 233 © 1993-2014 Jeff Sutherland

© 2014 Scrum Inc.

!