path to agility, ken schwaber

1

Scrum! for Paris User Group!

–noun 1. flexibility, the capacity and capability of

rapidly and efficiently adapting to change. 2. ability to take advantage of opportuni6es

while controlling risk.

29 March 2011 © ADM 1993-‐2011 All Rights Reserved v2.0 Slide 2

Agility (a·∙gil·∙i·∙ty)

The courage to be honest enough to admit that building soEware is complex and it can’t be perfectly planned since requirements change.

•  More global compeLtors •  More demanding

customers •  More complex products •  More features requested


Why is Agility important?

In other words: Because your customers demand it.

•  Improved relaLonship with customers, regaining trust •  Flexibility to turn on a dime •  Improved producLvity and quality •  Taking advantage of opportuniLes •  Early eliminaLon of risk •  Early realizaLon of value •  Always knowing exactly where you are in a development/deployment

cycle •  Easier to make changes •  EliminaLon of waste •  Lean products that reach market faster and are more targeted •  Increased Return on Investment •  Engaged, empowered workers •  Reduced Total Cost of Ownership


What are some specific reasons to “be Agile?”

•  Releases take longer and longer. •  Release schedules slip. •  StabilizaLon at end of release takes longer and longer. •  While a release is being worked on, it is very hard if not impossible

to start another release. •  Planning seems to take too long. •  Changes are hard to introduce mid-‐release, even though they

consLtute 35% of the total work. •  Quality is deterioraLng. •  There have more and more arLfacts, documentaLon, and process •  Death marches are hurLng morale. •  More than 60% of the funcLonality is rarely or never used, yet

unfilled needs and commitments conLnue to build up while the current release is being delivered.


But, many organizaLons instead have …

Source: Advanced Development Methods, Inc.

Waterfall!

Plan Analyze Design Code Test Release

Plan for the entire project up-front, including requirements of all value. Nothing can be used until project is over.

29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0 6

TradiLonal Development Processes Are Not Agile

Scrum!

Waterfall!

Plan Analyze Design Code Test Release

Short, high value iterations that deliver valuable, opportunistic pieces of functionality.!


Scrum Is Just TradiLonal More Quickly

Plan

Analyze Design Code Test

Release

Plan

The same work, but processed differently and on fewer requirements.!

Scrum!Short, high value iterations that deliver valuable, opportunistic pieces of functionality.!


Scrum Is a Tool You Use To Become Agile

Plan

Analyze Design Code Test

Release

Plan

Work done by self-organizing, cross-functional teams that are highly productive, creative, and build high quality product.!

Scrum Team

Scrum (n): (1) framework within which people can address complex problems, and producLvely and creaLvely develop products of the highest possible value; (2)A tool you can use to become Agile!


May I recommend Scrum?

Image source: codecentric.de

Agile Overtakes Waterfall

Source: December 2008 Global Agile Company Online Survey

Waterfall %

Agile %

29 March 2011 10 © ADM 1983-‐2010 All Rights Reserved v2.0

Improve things with Scrum

Remove waste •  Technical debt •  Unnecessary documentaLon

•  Unnecessary requirements

•  Unused requirements •  Architecture that must be reworked

Improve producLvity •  Collocated, self-‐organizing teams

•  Cross-‐funcLonal teams •  FTF communicaLons •  Improved decision making



The first thing that Agility requires is empiricism

Empirical (adjective) 1) Derived from or guided by experience or

experiment.

The modesty to admit that you don’t know all the answers, and that is okay. The best soluLon emerges from collaboraLon with the team.

A thermostat for soEware development


5 MINS

Purpose: Understand the power of empiricism

Situa<on: You are in charge of keeping a 20 x 40 room in this building at a constant 22C temperature through the day. The room does not have a thermostat.

At the start of the day, 8:00 am, you have to set the heaLng, air condiLoning, venLng, and blinds so that they will adjust themselves at the appropriate Lmes to maintain this temperature throughout the day.

Ques<on: What variables will you have to take into account to know the senngs? (hint: number of people in the room will be one variable).

Time People Event 7:00 -‐ 8:00 5 Room setup

8:00 -‐ 9:00 50 Breakfast, ConLnental buffet style, Lyzure Amalgamated

9:00-‐ 10:30 55 MeeLng -‐ Lyzure Amalgamated

10:30-‐ 11:00 55 Coffee break

11:00-‐ 12:30 55 MeeLng -‐ Lyzure Amalgamated

12:30-‐ 1:00 5-‐20 Setup and next meeLng arriving

1:00-‐ 3:00 50 MeeLng -‐ Rexxus Ltd.

3:00-‐ 3:30 50 Coffee break

3:30-‐ 5:30 70 MeeLng -‐ Rexxus Ltd.

Variables might include, for any Lme during the day: •  number of people in room •  metabolism of each person •  acLvity of each person •  opening/closing of doors •  weather: including sun, clouds, and outside temperature •  temperature of adjoining rooms •  construcLon material of the building •  floor of the room •  will food be served, when, what type, and how much •  temperature of food brought into room


Controlling temperature isn’t that complex, but there are a lot of things to plan for!

Dimensions Of Complexity W

eath

er

Patte

rns

Building Construction

Simple: Everything is known

Complicated: More is known than unknown

Complex: More is unknown than is known

Chaotic: Very little is known

Source: Ralph Stacey, University of Herfordshire


Empirical processes adapt to the future

•  Variables are ignored. Actual temperature drives senng of air condiLoning, heaLng, blinds.

•  Frequent inspecLon & adaptaLon (JIT) rather than predicLve planning

•  Based on “actuals” rather than predicLons

•  Requires transparency


The first thing empiricism needs is transparency

Transparency (adjective) 1) Easily seen through, recognized, or

understood. 2) All aspects are equally and commonly

understood by all observers

Most organizaLons struggle with transparency. It requires trust, courage and a lot of collaboraLon.


Quality: A Developer’s POV

•  I can readily understand the soEware and where & how things happen;

•  When I change or add to part of the soEware, there are no unintended or poorly designed dependencies;

•  I can read the code without looking for tricks or poorly defined and labeled variables or data;

•  I don’t need the person(s) that wrote the code to explain it to me; •  There are a full set of (automated) tests to check that the funcLon

works as expected; •  When I change something and add to the tests, I can check that the

enLre change and product conLnues to work; •  How things work and hang together is tranparent; and, •  Standard, well-‐known design principles have been adhered to.


Green Field SoEware

Time

Product Backlog (work)

Velocity (done work over time)


Exercise The SituaLon: •  You are a developer at xyz co,

building life-‐criLcal products. •  Your Scrum team is one of seven

working on a new release of one product.

•  Your team is going to select product backlog to turn into something done (no more work remains, potenLally shippable) within a two-‐week iteraLon.

•  Each team has all the skills to fully develop the requirements into a “done increment.”

The Assignment: •  What work would you have to do

to turn the requirements into a “done” increment?

•  If you were developing a “done”, potenLally shippable increment, what would your definiLon of “done” be? Would it include, for example, refactoring? What else?

20 29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0

Exercise (Cont.) Did your definiLon of “done” include these? Why not?

•  Performance tesLng •  Stability tesLng •  Refactoring •  Immunological response tesLng •  IntegraLon with the work of the other six teams •  IntegraLon tesLng with the work of the other six teams so the increment

is the totality of all seven teams •  Release notes •  InternaLonalizaLon to the six cultures where the product will be sold •  User acceptance tesLng •  Regression tesLng •  Code reviews


Plan Plan Develop Plan Develop Plan Develop Stabilize

Plan Plan Develop Plan Develop Plan Develop Stabilize

Undone

Undone Undone

22

StabilizaLon: What Undone Gets You

29 March 2011 © ADM 1983-‐2010 All Rights Reserved v2.0

Case Study: TransCanada Pipelines •  After three Sprints, Product Owner was delighted.

She wanted us to continue, but she wanted us to implement the first three increments so her department could start using them.

•  We told her that she couldn’t. She asked why not. We said that we weren’t done. She said that it looked done. We said, yes, but not that type of done. She asked how long it would take to go from our type of done to the done that would be usable by her.

•  Transparency was not present and trust was lost.


StabilizaLon: Plan Vs. Reality Plan!9 Sprints, 3 release candidates and then release.!800-person development organization.!

RC P P P D D D RC P P P D D D RC P P P D D D Release

Actual!The release candidates were presentation of partially working functionality from the code branch for each team. A five+ month stabilization was required prior to release.!“Inadequate performance” was a bug logged in the first Sprint.!

RC P P P D D D RC P P P D D D RC P P P D D D Release Stabilization!


Impact Of Integrated “Done” • 120 people, 18 teams!• Release 1: !

• Each team produced “done” increments each Sprint, but they were not integrated or integration tested until “code complete.”!

• Release 2: !• All teams produced an

increment of integrated, integration tested code every Sprint. !

25

Time!

# Defects!

Release 1!

Planned!Release!Date!

Release 2!


New Baseline Of “Undone” Work

Product Backlog

Undone Work

Perceived Work

Time

Actual Work Perceived Baseline

Actual Baseline Perceived Work + Undone Work

Actual Work


27

Work Item Usual Rec. start Done Requirements analysis 25 25 25

Design of architectural components (UI, System, Data 15 15 15

Design review 0 5 5

Design of tests (system, user acceptance, integration) 0 10 10

Design review 0 3 3

Design of documentation 0 2 2

Design Review 0 1 1

Refactoring of existing design 0 0 8

Design of unit tests for new code 0 3 3

Design of unit tests for code to be refactored 0 3 3

Writing new code 10 7 7

Writing refactored code 6 3 3

Code review (or pair programming) 0 4 4

Write functional tests 8 4 4

Write integration tests 0 4 4

Write documentation 4 4 4

Unit test code 0 2 2

Identify and rectify defects 0 2 2

Subsystem/team build 6 2 2


Unit test for subsystem/team code 0 2 2


System/integration build 1 1 1


System, functional tests 1 2 2


Integration tests 0 0 2


Performance tests 0 0 1


Security tests 0 0 1


Regression test 0 2 2


Documentation test 0 1 2


Total work expended requirement 78 118 148 Work remaining per requirement 65 30 0


SoEware W/Low Value To Developers Core FuncLonality •  Most significant new

funcLonality builds on it; •  Also called infrastructure

and legacy soEware; •  Is fragile, doesn’t have

complete test harnesses, and few people sLll know how to or are willing to touch it; and,

•  Requires more Lme to work on; velocity working on it is less than new work.


Time

Product Backlog

Core Functionality

New Functionality

Gradual Impact Of Reduced Quality

NPQ - Normal Product Quality RPQ - Reduced Product Quality


Reduced Velocity Puts OrganizaLon In Corner

6 5 7

Release 10


Exercise •  Your CEO comes to your development group. She tells you it is

mandatory to deliver three new pieces of funcLonality within three Sprints. Otherwise, compeLtors will decimate the company.

•  Planned work consists of: –  FuncLon 1: 20 units of work, 15 new, 5 core –  FuncLon 2: 40 units of work, 25 new, 15 core –  FuncLon 3: 30 units of work, 20 new, 10 core

•  Velocity for new funcLonality is 15 units of work per Sprint per team.

•  Velocity for core funcLonality is 5 units of work per Sprint total. •  You need a release with all three funcLons in three months. •  Can do you do? Can you save the company?


How Does Design-‐Dead SoEware Smell?

0

5

10

15

20

25

30

35

1 2 3 4 5

Mainten

ance Cost

Release


Maintenance/Velocity/Features CorrelaLon


PSTM (Professional Scrum Team

Member)

PSM (Professional Scrum Master)

PSPO (Professional Scrum Product

Owner)

29 March 2011 © 1993-‐2011 ADM, All Rights Reserved Slide 35

Filling In Scrum’s Holes

Successful SoAware Development

PSD (Professional

Scrum Developer)

Agenda •  Basics of Agility •  Value Driven Development

•  Product Management •  Plan a Release •  Managing Requirements •  Planning Releases •  Managing Releases •  Managing Products


Professional Scrum Product Owner course

•  Teaches Product Owner how to achieve Agility.

•  Complete course rewrite.

•  For product managers, program managers, and development managers.

•  Assessments and certification.

When Course April 11-‐12

Professional Scrum Product Owner course taught by ken Schwaber in Amsterdam

April 6-‐7 Professional Scrum Master course taught by Ken Schwaber in Brussels


Next Step for You!

Register hvp://courses.scrum.org/ Visit hvp://www.scrum.org/

QuesLons?


39

Thank you!

Ken Schwaber •  [email protected] •  www.scrum.org


path to agility, ken schwaber

Technology