Victor Villaseñor LopezVictor Villaseñor Lopez

IBM SWG – RationalIBM SWG – RationalMexico Software LaboratoryMexico Software Laboratory

From Firefighters to Swiss clockwork, an Agile From Firefighters to Swiss clockwork, an Agile transformation story, the hurdles behind it and transformation story, the hurdles behind it and measuring progress.measuring progress.

02/16/12 2

Agenda

•Introduction•From Firefighters to Swiss Clockwork

• Defining a Story Point.• 2 weeks? 3 weeks? Iteration Length.• Sizing the stuff that really matters.• Planning Meetings and Backlog Management.• Predicting Velocity & Planning

•Agile Adoption Metrics• What do we need and what to watch out for?• Scope• Time• Pace• Risks

•Alright, got it! (What now?)•Open Forum

02/16/12 3

Introduction

4

Introduction

✗ Missed deadlines✗ Never ending releases✗ No Requirements management

✗ Low Quality ✗ Unmanageable backlog

✗ Nonexistent test plans✗ Inconsistent test execution✗ No code reviews✗ No documentation✗ No automated tests

✗ Firefighters (lack of planning, etc.)✗ Fire everywhere!✗ Best Guesstimates✗ Mandatory work weekends

✔Releases on Time✔ Always on time✔ Clear definition of Release Contents

✔ Focus on Quality✔ Reduced defect backlog

✔ Within one year: reduced 90%✔ Within two years: reduced 65%

✔ Continuous test plans✔ Dedicated test team✔ Code reviews and Stakeholder review.✔ Documented dev processes and tests✔ Automated critical test cases

✔ Nightly runs

✔ Swiss Clockwork ✔ Risks and mitigations clearly defined✔ Predictable Velocity✔ 40 hours weeks

02/16/12 5

From Firefighters to Swiss ClockworkTransformation

6

Transformation : Defining a Story Point

The cornerstone for transformation, a clearly defined and team wide Story Point definition is key for the whole effort, problems here will echo all the way up to reporting and planning.

Refresher: A Story point is a unit of effort.

7

Transformation : Defining a Story Point

Key factors– Core task that the whole team understands, and all of its Core task that the whole team understands, and all of its

dependencies and related processes.dependencies and related processes.– Consider all the steps to count your SP as Done.Consider all the steps to count your SP as Done.

Key Pitfalls– Testing? What testing?Testing? What testing?

● Unit testingUnit testing● Verification effort Verification effort

Example of SP:– The effort needed to get a file (and its properties), add it in The effort needed to get a file (and its properties), add it in

to the product, test its correctly deployed / undeployed, and to the product, test its correctly deployed / undeployed, and the effort needed by a tester to verify the change..the effort needed by a tester to verify the change..

8

Transformation : Iteration Length

Key factors– Any automation present? Frequency of integration builds?Any automation present? Frequency of integration builds?– How soon do you release to market?How soon do you release to market?– Testing team or Testing team or Dev'sDev's gone testing? gone testing?

Key pitfalls– Testing only once during the iteration.Testing only once during the iteration.– Frequent changes to iteration length.Frequent changes to iteration length.– No working product at the end of the Iteration.No working product at the end of the Iteration.

Example:– Quarterly releases, with daily integration builds, a Quarterly releases, with daily integration builds, a

dedicated test team and automation that provides dedicated test team and automation that provides continuous testing. 2 Week iterations continuous testing. 2 Week iterations

9

Transformation : Sizing

Key factors– Done Done Done! What needs to be done?Done Done Done! What needs to be done?– Focus on high priority items first.Focus on high priority items first.– Promote discussion.Promote discussion.– Use Planning poker to get started.Use Planning poker to get started.

Key pitfalls– Only part of the team estimating.Only part of the team estimating.– Non-atomic items.Non-atomic items.– TemptationTemptation Pressure to size items without enough information. Pressure to size items without enough information.– Influential sizersInfluential sizers– Size 'em all!Size 'em all!

10

Transformation : Planning Meetings & Backlog Management

Key factors– Keep your Planning meetings straightforward.Keep your Planning meetings straightforward.– Present an Iteration backlog and have the team pick.Present an Iteration backlog and have the team pick.– Focus on the most critical tasks first.Focus on the most critical tasks first.– Define your processes, do not add content to the Iteration Define your processes, do not add content to the Iteration

backlog without all the needed information.backlog without all the needed information.

Key pitfalls– Overloaded team members.Overloaded team members.– Daily Iteration backlog changes.Daily Iteration backlog changes.– Disconnect between stakeholders inputs and actual work.Disconnect between stakeholders inputs and actual work.– Everything goes in this iteration!Everything goes in this iteration!

11

Transformation : Velocity & Planning

Key factors– Understand the resources your team will have.Understand the resources your team will have.– Understand the resources your team will have.Understand the resources your team will have.– Agreement and understanding with stakeholders.Agreement and understanding with stakeholders.– Say No!Say No!– Daily Scrums, yes, but the timing is important too.Daily Scrums, yes, but the timing is important too.

Key pitfalls– What? Velocity changed?!What? Velocity changed?!– Everything is critical!Everything is critical!– Untidy backlogUntidy backlog– Insufficient headroomInsufficient headroom

02/16/12 12

Agile Adoption Metrics

02/16/12 13

What do we need?(And things to watch out for)

14

Agile Metrics : Requirements

Backlog management.– For Backlog behavior analysis & Planning purposes. For Backlog behavior analysis & Planning purposes.

Story Point & Sizing process– Cornerstone for defining effort needed & VelocityCornerstone for defining effort needed & Velocity

Velocity– Predictability of progress, will have, may have and wont Predictability of progress, will have, may have and wont

have.have.

Iterative Development & Planning.– Time boxed iterations, with known velocity, enabling Time boxed iterations, with known velocity, enabling

effective planning and assessmenteffective planning and assessment

15

Non continuous tracking– Its impossible to make use of the metrics if they are not Its impossible to make use of the metrics if they are not

consistently capturedconsistently captured

Levels must be defined carefully– The gate values of green, yellow and red are team specific, The gate values of green, yellow and red are team specific,

the whole team must define and agree on them, Team the whole team must define and agree on them, Team Leads can propose, based on schedules and commitments, Leads can propose, based on schedules and commitments, but the whole team must agree on them.but the whole team must agree on them.

Insufficient follow up on not ideal values– Team, management and stakeholders must take all Team, management and stakeholders must take all

available measures to correct a non ideal value (not green!)available measures to correct a non ideal value (not green!)

Agile Metrics : Pitfalls

16

Scope Management

Green: Actual is behind less than 1 Iteration.

Yellow: Actual is behind more than 1 Iteration, Less than 2 Iterations.

Red: Actual is 2 or more iterations behind.

Inputs needed:Estimated SP's completedActual SP's completedTeam Velocity

17

Scope Management

Example:

Aug 27Sep

3

Sep 10

Sep 17

Sep 24Oct

1Oct

8

Oct 15

Oct 22

Oct 30

Nov 5

Nov 12

Nov 19

Nov 26Dec

3

Dec 10

Dec 17

Dec 24Ja

n 7

Jan 1

4

Jan 2

1

Jan 2

8Feb 4

Feb 11

Feb 18

Feb 25

Mar 4

Mar 11

Mar 18

Mar 25Apr

1Apr

8

Apr 15

Apr 22

Apr 29

May 6

May 13

May 20

May 27Ju

n 3

Jun 1

0

Jun 1

7

Jun 2

4Ju

l 1Ju

l 8Ju

l 15

Jul 2

2Ju

l 29

Aug 5

Aug 12

Aug 19

0

50

100

150

200

250

Development burndown to 8.0 release

Est SP closedAdded SPActual SP rem.Target SP rem.

Sto

ry P

oin

ts (S

P)

Burndown Chart:

Target SP's: 150Actual SP's: 175

Team Velocity: 15 SP's

Formula:

(Actual - Target)Velocity

(175 – 150 )15

= 1.6 Iterations Behind

Scope Management status =

= Iterations Behind

Yellow

18

Time Management

Green: Less than 1 developer's work needed.

Yellow: More than 1, but less than 2 developer's work needed.

Red: More than 2 developer's work needed.

Inputs needed:Estimated VelocityActual VelocityNumber of Developers

19

Time Management

Example:

Target Velocity: 30 SPActual Velocity: 18 SP

Developers: 5

Formula:

(Target – Actual ) Target

Time Management status =

= Developers needed to meet commitments in time.

Red

* Developers

(30 – 18 ) 30

= 2

* 5

20

Sustainable Pace

Green: Pace is less than 110%

Yellow: Pace is more than 110% but less than 120% Red: Pace is 120% or more!

Inputs needed:Weekly hours worked (team-wide)Number of Developers

21

Sustainable Pace

Formula:

Hours Worked * 100% / Ideal Pace

Sustainable Pace status = Green

Example:Weekly hours worked (team-wide) = 210Number of Developers = 5Hours of work (Ideal pace) = Developers * 40 = 200

= Pace Percentage

210 * 100 / 200 = Pace of 105%

Pace deviation = 5%

22

Quality Management

Green: Less than 5% Quality Issues percentage

Yellow: More than 5% but less than 10% Of Quality Issues percentage

Red: 10% or more of Quality Issues percentage

Inputs needed:Percentage of backlog increase.Percentage of test cases failed.Sustainable Pace deviation percentage.

23

Quality Management

Formula:

Backlog Increase% + Test Case% + Pace Deviation%

3

Quality Management status =

Quality Issues

Yellow

(15.15 + 1.42 + 5 )

3 = 7.11 %

Example:March backlog: 33 items. April backlog: 38 items.

Percentage of increase: 15.15%

Failed test cases: 3, Total of test cases: 210, Percentage: 1.42%

Sustainable Pace: 105% Pace Deviation= 5%

= Percentage of Quality Issues.

24

Risks & Mitigations

Dependencies– Is there any work blocked due external dependencies?Is there any work blocked due external dependencies?– Are calendar slippages affecting expected progress?Are calendar slippages affecting expected progress?

Deadlines– Upcoming critical dates in the project.Upcoming critical dates in the project.

Lack of Skills– Is education needed?Is education needed?

Other may apply, this is project specific and all the team Other may apply, this is project specific and all the team must agree on them.must agree on them.

25

ScoreCard Summary

Here is the ScoreCard for our hypothetical team:Metric Value State

Scope Management 1.6 Iterations behind

Time Management 2 More developer's work needed

Sustainable Pace deviation Pace is at 105%

Quality Issues Percentage 7.11 %

Risk & Mitigations

1 Team member quited this month, other team members are trying to compensate for its load. Investigating staffing options with Management.Large number of incoming defects but low test case failure rate. QA is reviewing the incoming defects to update test cases and catch them early on the cycle.

Yellow

Red

Green

Yellow

02/16/12 26

Alright, got it!(What now?)

27

We're all Green, all the time! what now?

Adjust your levels – Challenge yourselves!– Can we have less than 5% of Pace deviation all the time?Can we have less than 5% of Pace deviation all the time?– Aim for increasing velocity and performance.Aim for increasing velocity and performance.

Communicate your new targets to the stakeholders.Communicate your new targets to the stakeholders.

Start adopting more Agile & Quality practices– Public Demo, Review & Planning SessionsPublic Demo, Review & Planning Sessions– User Stories, Burn down charts.User Stories, Burn down charts.– Automate Test Cases and ProcessesAutomate Test Cases and Processes– Collective code ownershipCollective code ownership– Eliminate Waste, kaizen hunting, etc....Eliminate Waste, kaizen hunting, etc....

02/16/12 28

Questions?

02/16/12 29

Thanks !