SlideShare a Scribd company logo
The 
Impact 
Agile 
of 
Quantified 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Lean-Agile city. 
This place runs on 
folklore, intuition, and anecdotes. 
If you want to know the truth 
about this town, stick with me. I’ll 
give you a tour you’ll never forget. 
But if you don’t want your beliefs 
challenged with facts, you’d better 
beat it, kid. I don’t want to upset 
you. 
@LMaccherone | Larry@Maccherone.com @Tasktop |
My sidekick down there? That’s 
Larry Maccherone. He’s worked in 
this town his entire professional life. 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Credits 
Many thanks to my friends at Rally Software 
and their customers whose non-attributable 
data is the source for much of this research. 
Much of this material was previously 
published when I was Director of Analytics 
and Research at Rally Software, and much of 
that is derived from my PhD work at 
Carnegie Mellon, while other aspects come 
from collaboration with the Software 
Engineering Institute. 
@LMaccherone | Larry@Maccherone.com @Tasktop |
I’m going to give you the tools to find the real-world 
numbers that can help you make the 
economic case to get the resources you need 
and get your people to commit to change. 
Really. 
- 
@LMaccherone | Larry@Maccherone.com @Tasktop |
The Seven Deadly Sins of Agile Measurement 
1 Manipulating 
Others 
2 Unbalanced 
Metrics 
3 Quantitative 
Idolatry 
4 Overpriced 
Metrics 
5 Lazy 
Metrics 
6 Bad 
Analysis 
7 Linear 
Forecasting 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Sin #1 
Manipulating 
Others 
Using metrics as a 
lever to drive 
someone else’s 
behavior 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Heavenly Virtue #1 
Self 
Improvement 
Using metrics to 
reflect on your own 
performance 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Linear 
Sin #7 
Forecasting 
Forecasting without 
discussing 
probability and risk 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Heavenly Virtue #7 
Probability 
Tools 
Using the proper 
tools to predict the 
likelihood of results 
@LMaccherone | Larry@Maccherone.com @Tasktop | 
(Not likely)
Monte 
Carlo 
Simulation 
@LMaccherone | Larry@Maccherone.com @Tasktop |
CAUTION: 
Correlation 
does not 
necessarily mean 
causation 
@LMaccherone | Larry@Maccherone.com @Tasktop |
CAUTION: 
There are no 
best practices 
Only good 
practices in 
context 
@LMaccherone | Larry@Maccherone.com @Tasktop |
The investigation continues with ... 
Iteration length 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Crowd wisdom or shared delusion? 
Iteration length Teams 
using 
1 week 6.2% 
2 weeks 59.1% 
3 weeks 23.4% 
4 weeks 9.8% 
5+ weeks 1.5% 
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
SDPI current dimensions 
Productivity 
(Throughput) 
Predictability 
(Stability of 
Throughput) 
Responsiveness 
(Time in Process) 
Quality 
(Defect Density) 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Future SDPI dimensions 
Customer/ 
Stakeholder 
Satisfaction 
(Late 2014) 
Build-the- Right- 
Thing metric 
(2015) 
Employee 
Engagement/ 
Satisfaction 
(Late 2014) 
Code Quality from 
Static Analysis 
(2015) 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Raw metrics → Percentiles = Index 
@LMaccherone | Larry@Maccherone.com @Tasktop |
The investigation continues with ... 
Iteration length 
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
Facts Discovered: 
● Teams using two-week 
iterations have the best 
balanced performance 
● Longer iterations correlate 
with higher Quality 
● Shorter iterations correlate 
with higher Productivity and 
Responsiveness 
● However, some teams are 
acting like “tough guys” by 
pretending to operate at one-week 
iterations when they 
can’t back it up 
@LMaccherone | Larry@Maccherone.com @Tasktop |
The investigation continues with ... 
Ratio of testers to 
developers 
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
Facts Discovered: 
● More testers lead to better 
Quality 
● But they also generally lead 
to worse Productivity and 
Responsiveness 
● Interestingly, teams that self-identify 
as having no testers 
have: 
o The best Productivity 
o Almost as good Quality 
o But much wider variation 
in Quality 
@LMaccherone | Larry@Maccherone.com @Tasktop |
The investigation continues with ... 
Retrospectives 
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
The investigation continues with ... 
Motive 
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
Evidence Found: 
● Motive has a small but statistically 
significant impact on performance 
● Extrinsic motivation does not have 
a negative impact on performance 
● Executive support is critical for 
success with Agile 
● Teamwork is not the dominant 
factor; talent, skills, and 
experience are 
● Those motivated by quality 
perform best 
@LMaccherone | Larry@Maccherone.com @Tasktop |
The investigation continues with ... 
Co-location 
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
Evidence Found: 
● Teams distributed within the 
same time zone have up to 
25% better productivity. 
● Is distraction a problem? 
@LMaccherone | Larry@Maccherone.com @Tasktop |
One year earlier ... 
rallydev.com/agilemetrics 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Teams with low WiP have up to: 
● 4x better Quality 
● 2x faster Time to market 
● But 34% worse productivity 
Stable teams result in up to: 
● 60% better Productivity 
● 40% better Predictability 
Dedicated teams: Teams made up of 
people who only work on that one 
team have double the Productivity 
Smaller teams have better Productivity 
Larger teams have better Quality 
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop | 
Future research
 Tasktop Data 
– Provides a single aggregated stream of Data from connected tools: 
• ALM, Build, SCM, Support, Sales, etc. 
– Operates in real time. 
– Maintains complete history. 
– Normalizes data models. Resolves users and projects. 
– Supports analytics and reporting tools. 
– Does not directly provide visualization or analysis. 
 Get insights like the ones in this talk for your teams
A fact without a theory 
is like a ship without a sail, 
is like a boat without a rudder, 
is like a kite without a tail. 
A fact without a figure 
is a tragic final act. 
But one thing worse 
in this universe 
is a theory without a fact. 
~ George Schultz 
@LMaccherone | Larry@Maccherone.com @Tasktop | 
©2014 Larry Maccherone
Tasktop booth 
• Your questions 
• Extracting insights from 
your data 
Panel discussion 
• 4:30pm Grand Ballroom 
• Dave West – Tasktop 
Chief Product Officer 
• Ken Pugh 
• Mike Cottmeyer 
• Steve Davis 
• Jeff Estill 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Additional 
slides 
@LMaccherone | Larry@Maccherone.com #RallyON14 @Tasktop |
The investigation continues with ... 
SDPI dimensions 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Productivity = Throughput 
Throughput is simply the count of User Stories completed in a given time period. 
Productivity (by default) is the percentile scoring of the raw Throughput metric for User 
Stories normalized by team size. 
@LMaccherone | Larry@Maccherone.com @Tasktop | 
©2014 Larry Maccherone
Predictability = Stability of Throughput 
Predictability measures how consistent you are at producing the same amount of work 
each month as measured by the Coefficient of Variation (CoV) of Throughput. 
Predictability (by default) is the percentile scoring of the raw CoV of Throughput. 
@LMaccherone | Larry@Maccherone.com @Tasktop | 
©2014 Larry Maccherone
Responsiveness = Time in Process 
TiP shows how long it takes to get one work item through your system. It's the work 
days that a User Story spends in development and testing. Similar to lead time or cycle 
time. 
Responsiveness (by default) is the percentile scoring of the raw Time In Process (TiP) 
metric for User Stories. 
@LMaccherone | Larry@Maccherone.com @Tasktop | 
©2014 Larry Maccherone
Quality = Defect Density 
Defect Density is a representation of the number of defects found in your code. It's the 
count of defects found in a given time period, normalized by team size. 
Quality (by default) is the percentile scoring of the raw defect density metrics for both 
defects found in test as well as those found in production. 
@LMaccherone | Larry@Maccherone.com @Tasktop | 
©2014 Larry Maccherone
The investigation continues with ... 
Team time together 
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
The investigation continues with ... 
Controlling WiP 
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
Facts Discovered: 
Teams that most aggressively 
control WiP: 
● Have ½ the Time in Process 
(TiP) 
● Have ¼ as many defects 
● But have 34% lower 
productivity 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Recommendations: 
● If your WiP is high, reduce it 
● If your WiP is already low, 
consider your economic 
drivers 
○ If Productivity drives your 
bottom line, don’t push 
WiP too low 
○ If time to market or 
quality drives your 
bottom line, push WiP as 
low as it will go 
@LMaccherone | Larry@Maccherone.com @Tasktop |
The investigation continues with ... 
Estimating process 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Estimating process 
Process Type Teams Using 
No Estimates 3% 
Full Scrum 79% 
Lightweight Scrum 10% 
Hourly-Oriented 8% 
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
Facts Discovered: 
● Teams doing Full Scrum 
have 250% better Quality 
than teams doing no 
estimating 
● Lightweight Scrum performs 
better overall, with better 
Productivity, Predictability, 
and Responsiveness 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Recommendations: 
● Experienced teams may get 
best results from Lightweight 
Scrum 
● If new to Agile or focused 
strongly on Quality, choose 
Full Scrum 
@LMaccherone | Larry@Maccherone.com @Tasktop |
The investigation continues with ... 
Team stability & 
Dedication to one team 
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
Another Fact Discovered: 
One out of four team members 
changes every three months! 
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
Facts Discovered: 
Stable teams result in up to: 
● 60% better Productivity 
● 40% better Predictability 
Another Fact Discovered: 
One out of four team members 
changes every three months! 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Recommendations: 
● Dedicate people to a single 
team 
● Keep teams intact and stable 
@LMaccherone | Larry@Maccherone.com @Tasktop |
The investigation continues with ... 
Team size 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Balance your team’s Performance 
Agile recommends that the ideal team size is 7± 2. How ideal is that when we actually look at the data? 
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
Facts Discovered: 
Small teams (of 1-3) people have: 
● 17% lower Quality 
● But 17% more Productivity 
than teams of the recommended 
size. 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Recommendations: 
● Set up team size of 7±2 
people for the most balanced 
performance 
● If you are doing well with 
larger teams, there’s no 
evidence that you need to 
change 
@LMaccherone | Larry@Maccherone.com @Tasktop |
The investigation continues with ... 
Geography 
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
Israel-based teams 
● Find more defects overall 
● But find fewer in production 
● Theory: May correlate with 
high use of static analysis tools 
India-based teams 
● Find more defects overall 
● Released and unreleased 
● Theory: May correlate with 
high use of static analysis tools 
● Theory: Could be recording 
bias 
@LMaccherone | Larry@Maccherone.com @Tasktop |
Facts Discovered: 
● Differences are slight but 
statistically significant. 
● Australia has the best overall 
performance. 
● India the worst. However, 
there could be a reporting 
bias for defects. 
● Israel seems to catch the 
most defects before 
production. Heavy use of 
static analysis? 
@LMaccherone | Larry@Maccherone.com @Tasktop |
The investigation continues with ... 
Geography: US and Europe 
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |
@LMaccherone | Larry@Maccherone.com @Tasktop |

More Related Content

PDF
いままでのJaSSTnanoLT動画を振り返る&おススメしたいの! / Looking back and recommend on the JaSSTna...
PPTX
QA組織立ち上げ奮闘記 〜はじめに行ったこと、それは、理念を広めること〜
PPTX
探索的テストはじめの一歩 #wacate
PPTX
FriendlyによるWindowsアプリテスト自動化手法 基礎技術編
PDF
Agile requirements management
PPTX
Scrum Product Owner
PDF
DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜
PDF
Agile Scrum Training (+ Kanban), Day 2 (2/2)
いままでのJaSSTnanoLT動画を振り返る&おススメしたいの! / Looking back and recommend on the JaSSTna...
QA組織立ち上げ奮闘記 〜はじめに行ったこと、それは、理念を広めること〜
探索的テストはじめの一歩 #wacate
FriendlyによるWindowsアプリテスト自動化手法 基礎技術編
Agile requirements management
Scrum Product Owner
DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜
Agile Scrum Training (+ Kanban), Day 2 (2/2)

What's hot (20)

PDF
探索的テスト入門
PDF
What should you shift left
PPTX
A11y user stories csun 2018
PDF
Re-collection of embedded software qa in the last decade
PPTX
Writing test cases from user stories and acceptance criteria
PPTX
Scrumban Demystified
PPTX
Smart artサンプルv2
PPTX
Unplanned Work: Options for managing the inevitable
PDF
What is quality engineer? Is it something tasty?
PDF
DeNA QA Night #1 DeNA part
PPTX
Kanban India 2022 - Keynote - Todd Little | Turbocharge your Scrum with Kanban
PPTX
SCRUM Estimation
PDF
LINE Developer Meetup in Tokyo #39 Presentation (modified)
PDF
Projects, Personas, and Stakeholders
PPTX
テスト設計技法の適用・・・その前に
PDF
Introduction to Lean and Kanban
PPTX
Backlog Refinement 101 & 202
PPTX
Webサイト改善提案書
PDF
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
PDF
Effect Mapping: A Better Way to Get Really Usable Results Out of IT Projects
探索的テスト入門
What should you shift left
A11y user stories csun 2018
Re-collection of embedded software qa in the last decade
Writing test cases from user stories and acceptance criteria
Scrumban Demystified
Smart artサンプルv2
Unplanned Work: Options for managing the inevitable
What is quality engineer? Is it something tasty?
DeNA QA Night #1 DeNA part
Kanban India 2022 - Keynote - Todd Little | Turbocharge your Scrum with Kanban
SCRUM Estimation
LINE Developer Meetup in Tokyo #39 Presentation (modified)
Projects, Personas, and Stakeholders
テスト設計技法の適用・・・その前に
Introduction to Lean and Kanban
Backlog Refinement 101 & 202
Webサイト改善提案書
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
Effect Mapping: A Better Way to Get Really Usable Results Out of IT Projects
Ad

Viewers also liked (19)

PPTX
You want it when? Probabilistic forecasting and decision making
PPTX
Using metrics to influence developers, executives, and stakeholders
PDF
The Impact of Agile Quantified - Agile Australia 2014
PPTX
"What?", "So what?", "NOW WHAT?" How to influence people and accomplish change
PPTX
Impact of agile quantified: 2014 edition - A de-mystery thriller
PPTX
The BEST agile process
PPTX
M2 update 11 21
PDF
Beyond estimates - Reflection on the state of Agile Forecasting
PDF
EInführung in Lean Forecasting
PDF
Kanban Improvements - Emergent Behavior
PDF
Agile Metrics: Velocity is NOT the Goal - Agile 2013 version
PPTX
Unlocking Excellence with Agile Metrics
PDF
Why Product Management Matters
PDF
Agile Metrics : A seminal approach for calculating Metrics in Agile Projects
PPT
Agile Metrics That Matter
PDF
AgileLIVE Webinar: Measuring the Success of Your Agile Transformation - Part 2
PPT
Agile Metrics V6
PPTX
AgileChina 2015: Agile Estimation Workshop
PPTX
Agile Metrics: It's Not All That Complicated
You want it when? Probabilistic forecasting and decision making
Using metrics to influence developers, executives, and stakeholders
The Impact of Agile Quantified - Agile Australia 2014
"What?", "So what?", "NOW WHAT?" How to influence people and accomplish change
Impact of agile quantified: 2014 edition - A de-mystery thriller
The BEST agile process
M2 update 11 21
Beyond estimates - Reflection on the state of Agile Forecasting
EInführung in Lean Forecasting
Kanban Improvements - Emergent Behavior
Agile Metrics: Velocity is NOT the Goal - Agile 2013 version
Unlocking Excellence with Agile Metrics
Why Product Management Matters
Agile Metrics : A seminal approach for calculating Metrics in Agile Projects
Agile Metrics That Matter
AgileLIVE Webinar: Measuring the Success of Your Agile Transformation - Part 2
Agile Metrics V6
AgileChina 2015: Agile Estimation Workshop
Agile Metrics: It's Not All That Complicated
Ad

Similar to Impact of Agile Quantified - Late 2014 Edition (20)

PDF
DevOpsDays - Pick any Three - Devops from scratch
PPTX
Tom Capper Mozcon 2021 - Core Web Vitals - The Fast & The Spurious
PDF
19 creamer et workshop-agile2019-wash_pp_16-9_1
PDF
Unicom Devops Summit 2018 Melbourne
PDF
Larry Maccherone: "Probabilistic Decision Making"
PPTX
Tools Won't Fix Your Broken DevOps
PDF
Pick Any Three: Good, Fast, or Safe - Devops from Scratch
PPTX
Escaping the Feature Factory with OKRs Atlassian Melb UG Nov 2018
PPTX
TechSEO Boost 2017: Fun with Machine Learning: How Machine Learning is Shapin...
PDF
The Role of Analytics in Talent Acquisition
PPTX
Tips for Writing Better Charters for Exploratory Testing Sessions by Michael...
PPTX
The 7 Habits of Highly Effective Performance Teams [PerfNow 2019]
PDF
Please stop modernizing lightning 10m - agile dc - 2018-10-15
PDF
Adapting Agile for MERL
PPTX
Software Craftsmanship - It's an Imperative
PDF
Leading Your DevOps Enterprise Journey
PDF
How to Work with Software Engineers (strtupboost 10/18/18)
PPTX
Agile Truths and Misconceptions Exposed
PDF
Continuous Delivery: Making DevOps Awesome
PDF
DevOps and the Bottom Line
DevOpsDays - Pick any Three - Devops from scratch
Tom Capper Mozcon 2021 - Core Web Vitals - The Fast & The Spurious
19 creamer et workshop-agile2019-wash_pp_16-9_1
Unicom Devops Summit 2018 Melbourne
Larry Maccherone: "Probabilistic Decision Making"
Tools Won't Fix Your Broken DevOps
Pick Any Three: Good, Fast, or Safe - Devops from Scratch
Escaping the Feature Factory with OKRs Atlassian Melb UG Nov 2018
TechSEO Boost 2017: Fun with Machine Learning: How Machine Learning is Shapin...
The Role of Analytics in Talent Acquisition
Tips for Writing Better Charters for Exploratory Testing Sessions by Michael...
The 7 Habits of Highly Effective Performance Teams [PerfNow 2019]
Please stop modernizing lightning 10m - agile dc - 2018-10-15
Adapting Agile for MERL
Software Craftsmanship - It's an Imperative
Leading Your DevOps Enterprise Journey
How to Work with Software Engineers (strtupboost 10/18/18)
Agile Truths and Misconceptions Exposed
Continuous Delivery: Making DevOps Awesome
DevOps and the Bottom Line

Recently uploaded (20)

PPTX
Qualitative Qantitative and Mixed Methods.pptx
PDF
Optimise Shopper Experiences with a Strong Data Estate.pdf
PPTX
(Ali Hamza) Roll No: (F24-BSCS-1103).pptx
PPTX
IMPACT OF LANDSLIDE.....................
PDF
168300704-gasification-ppt.pdfhghhhsjsjhsuxush
PDF
Transcultural that can help you someday.
PPTX
STERILIZATION AND DISINFECTION-1.ppthhhbx
PPTX
mbdjdhjjodule 5-1 rhfhhfjtjjhafbrhfnfbbfnb
PPTX
modul_python (1).pptx for professional and student
PPTX
AI Strategy room jwfjksfksfjsjsjsjsjfsjfsj
PDF
annual-report-2024-2025 original latest.
PPTX
Managing Community Partner Relationships
PDF
Introduction to Data Science and Data Analysis
PPTX
IBA_Chapter_11_Slides_Final_Accessible.pptx
PPTX
Topic 5 Presentation 5 Lesson 5 Corporate Fin
PPT
ISS -ESG Data flows What is ESG and HowHow
PPTX
A Complete Guide to Streamlining Business Processes
PPTX
CYBER SECURITY the Next Warefare Tactics
PDF
Global Data and Analytics Market Outlook Report
PDF
Business Analytics and business intelligence.pdf
Qualitative Qantitative and Mixed Methods.pptx
Optimise Shopper Experiences with a Strong Data Estate.pdf
(Ali Hamza) Roll No: (F24-BSCS-1103).pptx
IMPACT OF LANDSLIDE.....................
168300704-gasification-ppt.pdfhghhhsjsjhsuxush
Transcultural that can help you someday.
STERILIZATION AND DISINFECTION-1.ppthhhbx
mbdjdhjjodule 5-1 rhfhhfjtjjhafbrhfnfbbfnb
modul_python (1).pptx for professional and student
AI Strategy room jwfjksfksfjsjsjsjsjfsjfsj
annual-report-2024-2025 original latest.
Managing Community Partner Relationships
Introduction to Data Science and Data Analysis
IBA_Chapter_11_Slides_Final_Accessible.pptx
Topic 5 Presentation 5 Lesson 5 Corporate Fin
ISS -ESG Data flows What is ESG and HowHow
A Complete Guide to Streamlining Business Processes
CYBER SECURITY the Next Warefare Tactics
Global Data and Analytics Market Outlook Report
Business Analytics and business intelligence.pdf

Impact of Agile Quantified - Late 2014 Edition

Editor's Notes

  • #3: Replace folklore with facts. Upgrade intuition to insight. Swap anecdotes with evidence.
  • #10: “What could go wrong…?” (That statement reminds me of Mark) The assumption is that he’s going to jump from building A to the spire on top of building C in 1.5 seconds, with complete certainty. A perfectly reasonable assumption, right?
  • #11: “What could go wrong…?” (That statement reminds me of Mark) The assumption is that he’s going to jump from building A to the spire on top of building C in 1.5 seconds, with complete certainty. A perfectly reasonable assumption, right?
  • #14: “There are a couple of warning signs on the roads in Agile city… and you should really pay attention to them because they could save you a lot of trouble later..."
  • #58: We've been working on theory for too long now. It's time to start to replace folklore it with facts. Upgrade intuition to insight. Swap anecdotes with evidence.
  • #59: We've been working on theory for too long now. It's time to start to replace folklore it with facts. Upgrade intuition to insight. Swap anecdotes with evidence.
  • #60: Replace folklore with facts. Upgrade intuition to insight. Swap anecdotes with evidence.