The document discusses strategies for measuring and reducing "pain" or friction in software development projects. It describes tracking sources of unexpected behavior and long troubleshooting times to identify the biggest problems causing pain. Common causes of pain include human errors and factors that make code harder to understand over time. The document advocates measuring and categorizing specific pain points, identifying the largest problems, becoming a risk translator to communicate issues to managers, and refactoring organization structures to improve feedback when problems arise.

1. Business Pressure
Stop Getting CRUSHED
by
Janelle Klein
openmastery.org @janellekz

2. , Developer, Consultant, CTO @
Specialized in Statistical Process Control (SPC)
and Supply Chain Optimization from Lean Manufacturing (data geek)
Continuous Delivery infrastructure, automation strategy & technical mentorship
Janelle Klein
Who Am I?
How to Measure the PAIN
in Software Development
Janelle Klein
Author of “Idea Flow”
leanpub.com/ideaflow
Founder of
newiron.com

3. This is a HARD Problem.
What is this talk about?

4. “Better”
“Better”
What if we could get managers and developers
all pulling the same direction?
Managers
Developers

5. Quick Recap

6. Great Team
Disciplined with Best Practices
Constantly Working on Improvements+
Project FAILURE
In the Last Talk…

7. The Retrospective
“What are we supposed to do?!”
Our biggest problem
“Well, if we don’t understand
a problem, we should
collect data.”

8. The Retrospective
Our biggest problem
“What data would help us
understand the problem?”
“What are we supposed to do?!”

9. Technical Debt Mistakes
I thought the main obstacle was
Technical Debt

10. ?
Most of our mistakes were in the
most well-written parts of the code.
Mistakes

11. We made significantly more mistakes
in code that we didn’t write ourselves.
Lower
Familiarity
More
Mistakes=
There had to be more to the story...

12. Unexpected
Behavior
Problem
Resolved
Tracking Painful Interaction with the Code (Friction)
Troubleshooting
Progress
5 hours and 18 minutes of troubleshooting...
PAINFUL

13. What Causes Unexpected
Behavior (likeliness)?
What Makes Troubleshooting
Time-Consuming (impact)?
Semantic Mistakes
Stale Memory Mistakes
Association Mistakes
Bad Input Assumption
Tedious Change Mistakes
Copy-Edit Mistakes
Transposition Mistakes
Failed Refactor Mistakes
False Alarm
Non-Deterministic Behavior
Ambiguous Clues
Lots of Code Changes
Noisy Output
Cryptic Output
Long Execution Time
Environment Cleanup
Test Data Creation
Using Debugger
Most of the pain was caused by human factors.
What causes PAIN?

14. What Causes Unexpected
Behavior (likeliness)?
What Makes Troubleshooting
Time-Consuming (impact)?
Non-Deterministic Behavior
Ambiguous Clues
Lots of Code Changes
Noisy Output
Cryptic Output
Long Execution Time
Environment Cleanup
Test Data Creation
Using Debugger
What causes PAIN?
Most of the pain was caused by human factors.
Semantic Mistakes
Stale Memory Mistakes
Association Mistakes
Bad Input Assumption
Tedious Change Mistakes
Copy-Edit Mistakes
Transposition Mistakes
Failed Refactor Mistakes
False Alarm

15. What Causes Unexpected
Behavior (likeliness)?
What Makes Troubleshooting
Time-Consuming (impact)?
Non-Deterministic Behavior
Ambiguous Clues
Lots of Code Changes
Noisy Output
Cryptic Output
Long Execution Time
Environment Cleanup
Test Data Creation
Using Debugger
What causes PAIN?
Semantic Mistakes
Stale Memory Mistakes
Association Mistakes
Bad Input Assumption
Tedious Change Mistakes
Copy-Edit Mistakes
Transposition Mistakes
Failed Refactor Mistakes
False Alarm
Most of the pain was caused by human factors.

16. What Causes Unexpected
Behavior (likeliness)?
What Makes Troubleshooting
Time-Consuming (impact)?
Non-Deterministic Behavior
Ambiguous Clues
Lots of Code Changes
Noisy Output
Cryptic Output
Long Execution Time
Environment Cleanup
Test Data Creation
Using Debugger
What causes PAIN?
PAIN is a consequence of how we interact with the code.
Semantic Mistakes
Stale Memory Mistakes
Association Mistakes
Bad Input Assumption
Tedious Change Mistakes
Copy-Edit Mistakes
Transposition Mistakes
Failed Refactor Mistakes
False Alarm

17. PAIN occurs during the process of
understanding and extending the software
Complex(
So*ware(
PAIN
Not the Code.
Optimize “Idea Flow”

18. My team spent tons of time working on
improvements that didn’t make much difference.
We had tons of automation, but the
automation didn’t catch our bugs.

19. My team spent tons of time working on
improvements that didn’t make much difference.
We had well-modularized code,
but it was still extremely time-consuming to troubleshoot defects.

20. The hard part isn’t solving the problems
it’s identifying the right problems to solve.
“What are the specific problems
that are causing the team’s pain?”

21. Then I got into consulting…
The Software Rewrite Cycle
Start%
Over%
Unmaintainable%
So0ware%

22. We Start with the Best of Intentions
High Quality Code
Low Technical Debt
Easy to Maintain
Good Code Coverage

23. Then This Happens!

24. Stages of Escalating Project Risk
Product Owner: “We’ve got more important things to do.”
Deferring(
Problems(

25. Deferring(
Problems(
Painful(
Releases(
Manager: “Good job everyone! Keep up that great work ethic!”
Stages of Escalating Project Risk

26. Deferring(
Problems(
Painful(
Releases(
Thrashing)
Manager: “We need to go faster! Let’s hire more developers.”
Stages of Escalating Project Risk

27. Deferring(
Problems(
Painful(
Releases(
Thrashing)
Project(
Meltdown(
Developer: “I give up. I don’t care anymore if the project fails.”
Stages of Escalating Project Risk

28. Our “Solution”
“We should just
quit our jobs.” “Yeah, it’s hopeless.”
What are we supposed to do?

29. Emergent Practice
Everything I’m showing today:
My Goal: Give You Hope

30. RESET
“A description of the goal is not a strategy.”
-- Richard P. Rumelt
What’s wrong with our current strategy?

31. Our “Strategy” for Success
High Quality Code
Low Technical Debt
Easy to Maintain
Good Code Coverage

32. RESET
“A good strategy is a specific and coherent response to—
and approach for overcoming—the obstacles to progress.”
-- Richard P. Rumelt
The problem is we don’t have a strategy...

33. What are the obstacles?
Obstacle 1:
Management doesn’t care about interest payments.
Obstacle 2:
Management would rather you shut up and do your job.
Obstacle 3:
The Problem is outside anyone’s control.

34. What are the obstacles?
Obstacle 1:
Your manager doesn’t care about interest payments.
Obstacle 2:
Management would rather you shut up and do your job.
Obstacle 3:
The Problem is outside anyone’s control.

35. “Let’s rewrite the software!”
My new project:
“Awesome in Disguise”
I had full control.

36. Continuous Delivery from day 1.

37. Then they announced “the plan”

38. My project was moved under
different management…

39. Crazy Deadlines

41. Constant
Urgency
Compromise
Safety for Speed

42. Time%
Pressure%
Compromise%
Safety%
for%
Speed%
Increase%
Number%&%
Severity%of%
Hazards%
%
More%Pain%
and%Higher%
Task%Effort%
Constant'
Urgency'
Cycle of Chaos
High-Risk Decision Habits

43. Time%
Pressure%
Compromise%
Safety%
for%
Speed%
Increase%
Number%&%
Severity%of%
Hazards%
%
More%Pain%
and%Higher%
Task%Effort%
Constant'
Urgency'
Cycle of Chaos
High-Risk Decision Habits

44. Time%
Pressure%
Compromise%
Safety%
for%
Speed%
Increase%
Number%&%
Severity%of%
Hazards%
%
More%Pain%
and%Higher%
Task%Effort%
Constant'
Urgency'
Cycle of Chaos
High-Risk Decision Habits

45. Time%
Pressure%
Compromise%
Safety%
for%
Speed%
Increase%
Number%&%
Severity%of%
Hazards%
%
More%Pain%
and%Higher%
Task%Effort%
Constant'
Urgency'
Cycle of Chaos
High-Risk Decision Habits

46. Time%
Pressure%
Compromise%
Safety%
for%
Speed%
Increase%
Number%&%
Severity%of%
Hazards%
%
More%Pain%
and%Higher%
Task%Effort%
Constant'
Urgency'
Cycle of Chaos
High-Risk Decision Habits

47. I Tried to Explain “Technical Debt”

48. “The project is already behind schedule!!”
Manager said:
“How can you possibly justify working
on anything other than the deliverables?!”
So we did what we were told.

49. We drank a lot.

50. Until we couldn’t take it anymore.

51. Explained the problem of Technical Debt
Business Coaching
“That doesn’t sound so bad.”
The Response:
?
?
?
?
WHAT?!

52. Loans are a Predictable Financial Tool
Revenue
- Cost
Profit + 10%
Increase Price?
Increase Sales?
Reduce Cost?
What makes investment decisions harder isn’t higher costs,
it’s lower predictability.
Investment Strategy

53. Obstacle 1:
Your manager doesn’t care about interest payments.
But… Managers care A LOT about RISK.
The gradual loss of predictability
is much scarier than the gradual increase in cost.

54. What are the obstacles?
Obstacle 1:
Your manager doesn’t care about interest payments.
Obstacle 2:
Management would rather you shut up and do your job.
Obstacle 3:
The Problem is outside anyone’s control.

55. What are the obstacles?
Obstacle 1:
Your Manager doesn’t care about interest payments.
Obstacle 2:
Your manager would rather you shut up and do your job.
Obstacle 3:
The System is setup to fail.

56. Another new project…
“Don’t ask for permission, ask for forgiveness.”

57. “Don’t ask for permission, ask for forgiveness.”
Another new project…

58. Then We Got New Management!
I put together “a plan”…

59. “What is Janelle trying to pull?!
Who does she think she is?!”
Management said (behind my back):
Get Back Inside Your Box! (or else)
Severe Violation of
SOCIAL PROTOCOL

60. SOCIAL PROTOCOL
Never talk to your manager’s boss about a problem.
Never suggest or imply your manager
can’t do their job effectively by
trying to get others to override their decisions.
Decision-making responsibilities are
assigned by management and not to be questioned.

61. Engineers: “We’re going to CRASH!”
Manager: “What do I do? We can’t miss these deadlines.”
Then I got into Consulting…

62. Developers
Manager
Consultant
“We’re going to hit the wall!”
Keynote
“We better invest
money in this!”
The Consulting World

63. The Job of a Consultant
Why do they need my help?!
Keynote

64. RESET
Consultants Bridge the Divide
Message comes through a “certified authority.”
Message comes in management-speak.

65. Obstacle 2:
Your manager would rather you shut up and do your job.
Follow
SOCIAL PROTOCOL
Stay (Mostly) Inside
Developer Box
Communicate
in Manager-Speak +

66. What are the obstacles?
Obstacle 2:
Your manager would rather you follow social protocol.
Lesson 3:
The system is setup to fail.
Obstacle 1:
Your manager doesn’t care about interest payments.

67. What are the obstacles?
Obstacle 1:
Your manager doesn’t care about interest payments.
Obstacle 2:
Your manager would rather you follow social protocol.
Obstacle 3:
The system is setup to fail.

68. The Challenge: Decision-Making is Distributed
Another Problem:
The Inability to Change Direction

69. What if our organization was a robot?
Fire x1
Dev Team
Management
Nothing’s happening…
Pain Sensor

70. What if our organization was a robot?
Fire x1
Dev Team
Management
Fire x10
Pain Sensor

71. Management
Dev Team
Fire x10
What if our organization was a robot?
If the feedback loop is broken, we burn.
Pain Sensor

72. Learn & Adapt
Role
Decision(
Type(
Required(
Knowledge(
Visibility and Decisions
Coupled
Visibility and Decisions
De-coupled
Role A
Required(
Knowledge(
Role B
Decision(
Type(
The Broken Feedback Loop is Baked into the Design

73. Manager
Alloca&on(
Decisions(
Knowledge(of(Risks(
Risk(Mgmt(
Decisions(
Developer
Communication
Breakdown
Broken Feedback Loop
(Manager Role)

74. Developer Product Owner
Actual'Risks'
interacts''
with'
Actual'Customers'
interacts''
with'
Knowledge'of'
Customers'
Trade9off'
Decisions'
depend'on'depend'on'
Knowledge'of'
Risks'
Communication
Breakdown
Broken Feedback Loop
(Product Owner Role)

75. Now we can steer!!
So#ware(Task(
Mi.gate(the(Risks(
Product(
Development(
Product(
Work(Queue(
Risk(Mgmt(
Work(Queue(
Product(Owner(
Product(
Decisions(
Knowledge(of(
Customers(
Technical(Risk(Manager(
Risk(Mgmt(
Decisions(
Knowledge(of(
Risks(
Dev$Team$Capacity$
Manager
Alloca.on(
Decisions(
Refactor the Organizational Architecture

76. This is the design that typically emerges
when we have:
Trust.

77. Role
Decision(
Type(
Required(
Knowledge(
Visibility and Decisions
Coupled
Visibility and Decisions
De-coupled
Role A
Required(
Knowledge(
Role B
Decision(
Type(
Obstacle 3:
The system is set up to fail.
We’ve got to fix the machine
(even though it’s not our responsibility)

78. What are the obstacles?
Obstacle 1:
Management doesn’t care about interest payments.
Obstacle 2:
Management would rather you follow social protocol.
Obstacle 3:
The system is setup to fail.

79. RESET
“A good strategy is a specific and coherent response to—
and approach for overcoming—the obstacles to progress.”
-- Richard P. Rumelt

80. What’s the Strategy?
2. Measure the Pain
4. Become a Risk Translator
5. Refactor the Organization
3. Identify the Biggest Problems
1. Make the Decision to Lead

81. What’s the Strategy?
2. Measure the Pain
4. Become a Risk Translator
5. Refactor the Organization
3. Identify the Biggest Problems
1. Make the Decision to Lead

82. Leadership is not a title, it’s a choice.

83. What’s the Strategy?
2. Measure the Pain
4. Become a Risk Translator
5. Refactor the Organization
3. Identify the Biggest Problems
1. Make the Decision to Lead

84. Your manager doesn’t care that your job “feels difficult”
“In God we trust, all others bring data.”
—Edwards Deming

85. PAIN occurs during the process of
understanding and extending the software
Complex(
So*ware(
PAIN
Not the Code.
Optimize “Idea Flow”

86. Idea Flow Mapping Tools
(Open Source, Supported GA ~June 2016)
github.com/ideaflow/tools

87. “Idea Flow Map”
“Friction”

88. “What caused the pain
in this case?”
Categorize the Problems with #HashTags
#ReportingEngine
#Hibernate
#MergeHell

89. 1. Problem A
2. Problem B
3. Problem C
Add up the Pain by Category
What’s the biggest problem to solve?

90. Tools Demo

91. Troubleshooting
Progress
Learning
7:070:00
0:00 19:52
12 year old project after all original developers left.
Case Study: Huge Mess with Great Team
70-90% of dev capacity on “friction”

92. The Team’s Improvement Focus:
Increasing unit test coverage by 5%
Case Study: Huge Mess with Great Team
1. Test Data Generation
2. Merging Problems
3. Repairing Tests
1000 hours/month
The Biggest Problem:
~700 hours/month generating test data

93. 18 months after a Micro-Services/Continuous Delivery rewrite.
Troubleshooting
Progress
Learning
40-60% of dev capacity on “friction”
0:00 28:15
12:230:00
Case Study: From Monolith to Microservices

94. The Architecture Looked Good on Paper
Team A Team B Team C
Complexity Moved Here
WTF?! WTF?!

95. We Don’t Have TIME To Fix It!

96. The Cost of Escalating Risk
0%
100%
Release 1 Release 2 Release 3
Troubleshooting
Progress
Learning
Percentage Capacity spent on Troubleshooting (red) and Learning (blue)
(extrapolated from samples)

97. 0%
100%
Release 1 Release 2 Release 3
Percentage Capacity spent on Troubleshooting (red) and Learning (blue)
Figure out what to do
Learning is front-loaded
Troubleshooting
Progress
Learning
The Cost of Escalating Risk

98. 0%
100%
Release 1 Release 2 Release 3
Percentage Capacity spent on Troubleshooting (red) and Learning (blue)
Rush Before the Deadline
Validation is Deferred
Troubleshooting
Progress
Learning
The Cost of Escalating Risk

99. 0%
100%
Release 1 Release 2 Release 3
Percentage Capacity spent on Troubleshooting (red) and Learning (blue)
Pain Builds
Baseline friction keeps rising
Troubleshooting
Progress
Learning
The Cost of Escalating Risk

100. 0%
100%
Release 1 Release 2 Release 3
Percentage Capacity spent on Troubleshooting (red) and Learning (blue)
Chaos Reigns
Unpredictable work stops
fitting in the timebox
Troubleshooting
Progress
Learning
The Cost of Escalating Risk

101. The Challenge:
How do I get my team to collect data??

102. Would you be willing to collect data if
you knew your management would give you
dedicated time to work on the biggest problems?

103. 1. Don’t ask for Permission
2. State your Goal
"I want to make the business case to management for fixing things around
here. No more chaos and working on weekends, this needs to stop. But I
need data to make the case so I need everyone's help."
3. State the Plan
"Here's what I'm thinking. I want to run an experiment to record data for one
month on all the time we spend troubleshooting. We can look at the data
together and identify our biggest problems, then I’ll write it up and present
the case to management to get things fixed.”
4. Enlist the Team
“Will you guys help me make this happen?”
Here’s What You Do:

104. 1. Don’t ask for Permission
2. Make the Goal Clear to Your Team
"I want to make the business case to management for fixing things around
here. No more chaos and working on weekends, this needs to stop. But I
need data to make the case so I need everyone's help."
3. State the Plan
"Here's what I'm thinking. I want to run an experiment to record data for one
month on all the time we spend troubleshooting. We can look at the data
together and identify our biggest problems, then I’ll write it up and present
the case to management to get things fixed.”
4. Enlist the Team
“Will you guys help me make this happen?”
Here’s What You Do:

105. 1. Don’t ask for Permission
2. Make the Goal Clear to Your Team
"I want to make the business case to management for fixing things around
here. No more chaos and working on weekends, this needs to stop. But I
need data to make the case so I need everyone's help."
3. State the Plan
"Here's what I'm thinking. I want to run an experiment to record data for one
month on all the time we spend troubleshooting. We can look at the data
together and identify our biggest problems, then I’ll write it up and present
the case to management to get things fixed.”
4. Enlist the Team
“Will you guys help me make this happen?”
Here’s What You Do:

106. 1. Don’t ask for Permission
2. Make the Goal Clear to Your Team
"I want to make the business case to management for fixing things around
here. No more chaos and working on weekends, this needs to stop. But I
need data to make the case so I need everyone's help."
3. State the Plan
"Here's what I'm thinking. I want to run an experiment to record data for one
month on all the time we spend troubleshooting. We can look at the data
together and identify our biggest problems, then I’ll write it up and present
the case to management to get things fixed.”
4. Enlist the Team
“Will you guys help me make this happen?”
Here’s What You Do:

107. What’s the Strategy?
2. Measure the Pain
4. Become a Risk Translator
5. Refactor the Organization
3. Identify the Biggest Problems
1. Make the Decision to Lead

108. Add up the Pain by Category
1. Test Data Generation
2. Merging Problems
3. Repairing False Alarms
1000 hours/month
What’s the biggest problem to solve?

109. Friction as a % of total capacity
What’s the biggest problem to solve?

110. Friction % versus Upcoming Demand
What’s the biggest problem to solve?

111. Friction % Grouped by Familiar vs Unfamiliar
What’s the biggest problem to solve?

112. What’s the Strategy?
2. Measure the Pain
4. Become a Risk Translator
5. Refactor the Organization
3. Identify the Biggest Problems
1. Make the Decision to Lead

113. The Constraints
Stay (Mostly) Inside
Developer Box
Communicate
in Manager-Speak +

114. Your Job is to Repair the Broken Feedback Loop
Risk Translator
Engineering
(Execution)
Management
(Coordination)
Risk is the bridge language.

115. Manager
Alloca&on(
Decisions(
Knowledge(of(Risks(
Risk(Mgmt(
Decisions(
Developer
Risk
Translator
Risk(
Summary(
Risk Translator Role
Fits Within
Developer Box

116. measures the time spent on:
Idea Flow
x
Troubleshooting
x
Learning
x
Rework
Quality Risk Familiarity Risk Assumption Risk

117. Quality Risk (Troubleshooting)
Likelihood)of))
Unexpected)
Behavior)
Cost)to)Troubleshoot)and)Repair)
High)Frequency)
Low)Impact)
Low)Frequency)
Low)Impact)
Low)Frequency)
High)Impact)
PAIN)

118. Familiarity Risk (Learning)
Likelihood)of))
working)with)
Unfamiliar)
Code)
Cost)to)Learn)
High)Frequency)
Easy)to)Learn)
Low)Frequency)
Easy)to)Learn)
Low)Frequency)
Hard)to)Learn)
PAIN)

119. Assumption Risk (Rework)
Likelihood)of))
making)a))
Bad)Assump4on)
Cost)to)Correct)Decisions)
High)Uncertainty)
Low)Delay)
Low)Uncertainty)
Low)Delay)
Low)Uncertainty)
High)Delay)
PAIN)

120. Decisions that
save a few hours
Side-effects that cost
several hours
Save 40 hours in direct costs
(leave the toy on the stairs)
Increase chances of losing 1000 hours by 20%
(tripping and falling)
Explain Problems in Terms of Risk (Gambling)

121. Distribution of Development Capacity
Over the long-term, probability wins.

122. Send “Project Visibility Updates”
Hi Larry,
I know it’s really hard to stay in the loop on all the different
project risks, so I wanted to send you a summarized update of
some of our recent findings.
Subject: Project Visibility Update
We started collecting data during development to track where
all of our time was going, and made some pretty frightening
discoveries.
See attached. Let me know if you’d like to talk.

123. Risk Translators build
Trust
by making sense.

124. What’s the Strategy?
2. Measure the Pain
4. Become a Risk Translator
5. Refactor the Organization
3. Identify the Biggest Problems
1. Make the Decision to Lead

125. Manager
Alloca&on(
Decisions(
Knowledge(of(Risks(
Risk(Mgmt(
Decisions(
Developer
Risk
Translator
Risk(
Summary(
Refactor Step 1: Risk Translator

126. So#ware(Task(
Mi.gate(the(Risks(
Product(
Development(
Product(
Work(Queue(
Risk(Mgmt(
Work(Queue(
Product(Owner(
Product(
Decisions(
Knowledge(of(
Customers(
Dev$Team$Capacity$
Alloca.on(
Decisions(
Manager2Translator$Partnership$
Risk(Mgmt(
Decisions(
Knowledge(of(Risks(
Refactor Step 2: Partnership

127. Now we can steer!!
So#ware(Task(
Mi.gate(the(Risks(
Product(
Development(
Product(
Work(Queue(
Risk(Mgmt(
Work(Queue(
Product(Owner(
Product(
Decisions(
Knowledge(of(
Customers(
Technical(Risk(Manager(
Risk(Mgmt(
Decisions(
Knowledge(of(
Risks(
Dev$Team$Capacity$
Manager
Alloca.on(
Decisions(
Refactor Step 3: Owner

128. Option 1 Option 2
Stay
the Course
Change
This is Safer (less risky)
or
Make the Case for Partnership
Focus on the Risks
(don’t negotiate schedule)
Key to Success:

129. 1. Explain Why You Decided to Collect Data
Saw this talk/read this book about…
How to Measure the PAIN
in Software Development
Janelle Klein
Consultant +1 Effect
(blame me)

130. Time%
Pressure%
Compromise%
Safety%
for%
Speed%
Increase%
Number%&%
Severity%of%
Hazards%
%
More%Pain%
and%Higher%
Task%Effort%
Constant'
Urgency'
“In the book, Janelle talks about this “Cycle of Chaos”…

131. “As the problems build, they introduce Quality Risk…
Likelihood)of))
Unexpected)
Behavior)
Cost)to)Troubleshoot)and)Repair)
High)Frequency)
Low)Impact)
Low)Frequency)
Low)Impact)
Low)Frequency)
High)Impact)
PAIN)
Likelihood
of
Mistakes
Cost
to
Recover
Quality Risk
Our application is more likely to be in a BROKEN state.

132. “We’re measuring the problems while we work…
Problems Measured in HOURS.

133. 2. Here’s What We Found…
Pick your WORST offending examples.
Use lots of RED.

134. Save time by
skipping diagnostic
tools
(~80 hours)
Side-effects of
Troubleshooting time
(~700 hours/month)
36h 25m0:00
Troubleshooting
Progress11 hours and 15 minutes of troubleshooting...
Creating a New Customer Report
“This is a timeline that shows all the time we spend troubleshooting…

135. Save time by
constantly rushing
(~20 hours/month)
Side-effects of
25 developers
down for 2 days
(~1000 hours/month)
“When the problems build up, they have a really big impact…

136. “When the application is broken,
these are the biggest problems in our way.
1000 hours/month
1. Test Data Generation
2. Merging Problems
3. Repairing False Alarms
Top Three Problems

137. “The deadline is coming either way…”
80% of features 100% done?100% of features 80% done?

138. “Here’s what we were thinking…”
3-Month Improvement Trial
Dedicated resources (1 or 2 developers)
Dev team identifies highest-leverage improvement
opportunities and prioritizes with management
Continue to share Project Visibility Updates each month
“Will you help us turn this project around?”

139. Summary

140. The Biggest Cause of FAILURE in our Industry:

141. “Better”
“Better”
We have an opportunity to do this across our industry:
Managers
Developers

142. Two Options:
Option 1
Stay
the Course
Option 2
Take
Responsibility
or
Let’s Do This
Here’s the Catch:
In order for us to change the status quo, we have to start
working together as a community.

143. Let’s
take responsibility,
learn how to get there,
then let’s help each other to succeed.

144. LEARN YOUR WAY TO AWESOME.
Free to Join Industry Peer Mentorship Network
openmastery.org

145. If you’d like to see our industry start
collaborating on solving these problems…
and you’re willing to Measure Your PAIN…
Let’s Make the PAIN Visible!
Next Talk:

146. #OpenDX
An Open Standard for Measuring PAIN
(Specification for Data Collection)
Developer
Experience

147. Community Analytics Platform
Idea Flow Mapping Tools
Team Mastery Tools
Team
Joe
Sally
Mark
Eric
Community Analytics
Anonymized
Data
(REST)
Shared Taxonomy
of Patterns & Principles
(with example data)
Project
Tiger
Project
Bear

148. This isn’t about me.
Janelle Klein
openmastery.org @janellekz
This is about ALL OF US.

149. This is about Ending this BULLSHIT:
Janelle Klein
openmastery.org @janellekz

150. If you BELIEVE…
Janelle Klein
openmastery.org @janellekz
Carry the Torch.

151. Courage.
Janelle Klein
openmastery.org @janellekz
Leadership.
Empathy.
Authenticity.
Respect.

152. Take
Responsibility
Janelle Klein
openmastery.org @janellekz
Two Options:
Option 1
Stay
the Course
Option 2
or
Let’s Make the PAIN Visible!

153. What do you see as the
biggest obstacle to success?
Discussion: