27. Agile Manifesto
▪
Individuals and interactions over processes and tools
▪
Working software over comprehensive documentation
▪
Customer collaboration over contract negotiation
▪
Responding to change over following a plan
43. 1. not enough time to test
Risk: cost of bugs getting into production
44. 1. not enough time to test
Risk: cost of bugs getting into production
Assumptions:
45. 1. not enough time to test
Risk: cost of bugs getting into production
Assumptions:
• we know what our customers want
46. 1. not enough time to test
Risk: cost of bugs getting into production
Assumptions:
• we know what our customers want
• bugs are expensive
47. 1. not enough time to test
Risk: cost of bugs getting into production
Assumptions:
• we know what our customers want
• bugs are expensive
• testing takes a long time
48. 1. not enough time to test
Risk: cost of bugs getting into production
Assumptions:
• we know what our customers want
• bugs are expensive
• testing takes a long time
• all bugs can be found in test
49. 1. not enough time to test
Risk: cost of bugs getting into production
Assumptions:
• we know what our customers want
• bugs are expensive
• testing takes a long time
• all bugs can be found in test
50. 1. not enough time to test
Assume: we know what our customers want
testing: did we
build it right?
51. 1. not enough time to test
Assume: we know what our customers want
risk: did we build
the right thing?
52. 1. not enough time to test
Assume: we know what our customers want
$O
53. 1. not enough time to test
Assume: we know what our customers want
$O
(well, negative $ actually)
54. 1. not enough time to test
Assume: we know what our customers want
55. 1. not enough time to test
Assume: we know what our customers want
• we understand our customer’s needs
56. 1. not enough time to test
Assume: we know what our customers want
• we understand our customer’s needs
• our customers know what they want
57. 1. not enough time to test
Assume: we know what our customers want
• we understand our customer’s needs
• our customers know what they want
• our customers will still want what we
have when we give to them
58. 1. not enough time to test
Assume: we know what our customers want
validated learning
about customers
59. 1. not enough time to test
Assume: we know what our customers want
simplest solution
to validate
hypothesis
60. 1. not enough time to test
Assume: we know what our customers want
split test
61. 1. not enough time to test
Assume: we know what our customers want
“deliver fast enough that the
customer doesn’t have time
to change their mind”
62. 1. not enough time to test
Risk: cost of bugs getting into production
Assumptions:
• we know what our customers want
• bugs are expensive
• testing takes a long time
• all bugs can be found in test
63. 1. not enough time to test
Assumption: bugs are expensive
$ million bug
64. 1. not enough time to test
Assumption: bugs are expensive
= $10 billion
65. 1. not enough time to test
Assumption: bugs are expensive
= 120M users/day
66. 1. not enough time to test
Assumption: bugs are expensive
bugs are inevitable
67. 1. not enough time to test
Assumption: bugs are expensive
speed of response
68. 1. not enough time to test
Assumption: bugs are expensive
continuous
monitoring
69. 1. not enough time to test
Assumption: bugs are expensive
70. 1. not enough time to test
Assumption: bugs are expensive
71. 1. not enough time to test
Assumption: bugs are expensive
72. 1. not enough time to test
Assumption: bugs are expensive
73. 1. not enough time to test
Risk: cost of bugs getting into production
Assumptions:
• we know what our customers want
• bugs are expensive
• testing takes a long time
• all bugs can be found in test
74. 1. not enough time to test
Assumption: testing takes a long time
small changes
75. 1. not enough time to test
Assumption: testing takes a long time
continuous
integration
76. 1. not enough time to test
Assumption: testing takes a long time
continuous
testing
77. 1. not enough time to test
Assumption: testing takes a long time
test automation
78. 1. not enough time to test
Assumption: testing takes a long time
always releaseable
79. 1. not enough time to test
Risk: cost of bugs getting into production
Assumptions:
• we know what our customers want
• bugs are expensive
• testing takes a long time
• all bugs can be found in test
80. 1. not enough time to test
Assumption: all bugs can be found in test
= 40,000 photos/sec
81. 1. not enough time to test
Assumption: all bugs can be found in test
= 6 Pb of storage
82. 1. not enough time to test
Assumption: all bugs can be found in test
83. 1. not enough time to test
2. disruptive to users
3. too much overhead
86. 2. disruptive to users
Risk: new releases will annoy users
Assumptions:
87. 2. disruptive to users
Risk: new releases will annoy users
Assumptions:
• releases incur downtime
88. 2. disruptive to users
Risk: new releases will annoy users
Assumptions:
• releases incur downtime
• users will notice changes
89. 2. disruptive to users
Risk: new releases will annoy users
Assumptions:
• releases incur downtime
• users will notice changes
• changes are visible to all users
90. 2. disruptive to users
Risk: new releases will annoy users
Assumptions:
• releases incur downtime
• users will notice changes
• changes are visible to all users
94. 2. disruptive to users
Assumption: releases incur downtime
redundancy
95. 2. disruptive to users
Risk: new releases will annoy users
Assumptions:
• releases incur downtime
• users will notice changes
• changes are visible to all users
98. 2. disruptive to users
Assumption: users will notice changes
version?
99. 2. disruptive to users
Risk: new releases will annoy users
Assumptions:
• releases incur downtime
• users will notice changes
• changes are visible to all users
100. 2. disruptive to users
Assumption: changes are visible to all
users
big-bang release
101. 2. disruptive to users
Assumption: changes are visible to all
users
options
102. 2. disruptive to users
Assumption: changes are visible to all
users
103. 2. disruptive to users
Assumption: changes are visible to all
users
Options:
104. 2. disruptive to users
Assumption: changes are visible to all
users
Options:
• release to user subset (private beta)
105. 2. disruptive to users
Assumption: changes are visible to all
users
Options:
• release to user subset (private beta)
• rollout to some servers
106. 2. disruptive to users
Assumption: changes are visible to all
users
Options:
• release to user subset (private beta)
• rollout to some servers
• downgrade feature
107. 2. disruptive to users
Assumption: changes are visible to all
users
Options:
• release to user subset (private beta)
• rollout to some servers
• downgrade feature
• disable feature (feature darkmode)
108. 2. disruptive to users
Assumption: changes are visible to all
users
Options:
• release to user subset (private beta)
• rollout to some servers
• downgrade feature
• disable feature (feature darkmode)
• defer commit
109. 2. disruptive to users
Assumption: changes are visible to all
users
Options:
• release to user subset (private beta)
• rollout to some servers
• downgrade feature
• disable feature (feature darkmode)
• defer commit
• defer release
110. 2. disruptive to users
Assumption: changes are visible to all
users
options = $$$
111. 2. disruptive to users
Assumption: changes are visible to all
users
“release is a
marketing decision”
112. 2. disruptive to users
Assumption: changes are visible to all
users
bonus:
113. 1. not enough time to test
2. disruptive to users
3. too much overhead
115. 3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes
116. 3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes
Assumptions:
117. 3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes
Assumptions:
• high coordination overhead
118. 3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes
Assumptions:
• high coordination overhead
• releases are risky
119. 3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes
Assumptions:
• high coordination overhead
• releases are risky
• deployment takes a long time
120. 3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes
Assumptions:
• high coordination overhead
• releases are risky
• deployment takes a long time
121. 3. too much overhead
Assumption: high coordination overhead
functional silos
122. 3. too much overhead
Assumption: high coordination overhead
dev vs. ops
123. 3. too much overhead
Assumption: high coordination overhead
devs don’t know
prod
124. 3. too much overhead
Assumption: high coordination overhead
ops don’t know
code
125. 3. too much overhead
Assumption: high coordination overhead
shared
accountability
126. 3. too much overhead
Assumption: high coordination overhead
127. 3. too much overhead
Assumption: high coordination overhead
shared
accountability
128. 3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes
Assumptions:
• high coordination overhead
• releases are risky
• deployment takes a long time
129. 3. too much overhead
Assumption: releases are risky
“if it hurts, do it
more often”
130. 3. too much overhead
Assumption: releases are risky
incremental
change
131. 3. too much overhead
Assumption: releases are risky
more or less same
system
132. 3. too much overhead
Assumption: releases are risky
practice makes
perfect
133. 3. too much overhead
Risk: cost of a release is greater than the
benefit of its changes
Assumptions:
• high coordination overhead
• releases are risky
• deployment takes a long time
134. 3. too much overhead
Assumption: deployment takes a long
time
risk: manual steps
135. 3. too much overhead
Assumption: deployment takes a long
time
automated
deployment
136. 3. too much overhead
Assumption: deployment takes a long
time
one-step process
145. underlying risks
Risks:
• do we know what customers want?
• can we respond fast enough to
problems?
• can we detect problems when they
happen?
• can we limit the impact of changes?
• can we deploy without downtime?
• can we build production-ready
software?
