Victor Villaseñor Lopez Victor Villaseñor Lopez IBM SWG – Rational IBM SWG – Rational Mexico Software Laboratory Mexico 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.
29
Embed
From Firefighters to Swiss clockwork, an Agile transformation … · 2019-12-16 · 10 Transformation : Planning Meetings & Backlog Management Key factors – Keep your Planning meetings
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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!
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.
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....