The Mythical Team-Month

Video of this talk (as presented at KalX 2012): https://vimeo.com/42861260
Screencast w/ audio of this talk: http://vimeo.com/38321427
If you think we could help your organization, contact us! http://test-double.com

Transcript

1. the Mythical team-month
2. FIRST first things
3. @searls
4. http://test-double.com @testdouble
5. this isn't Management
6. Small teams go Faster
7. but claiming that Small teams go Faster requires definitions
8. but claiming that Small teams go Faster requires definitions
9. but claiming that Small teams go Faster requires definitions
10. let's start with small
11. scrum says +/- 7 2
12. amazon says
13. small is having nowhere to hide
14. If I can get away with not focusing not trying not caring the team is not small {
15. defining
16. write a line of code? is faster taking less time to
17. is faster taking less time to release a feature?
18. earn a dollar? is faster taking less time to
19. Answer a Question faster is taking less time to
20. questions like, Is this feature possible?
21. Are we able to build it? questions like,
22. Will customers use it? questions like,
23. Will customers use it? Pay For ^ questions like,
24. Can it handle 1 million visits each day? questions like,
25. Which design achieves a higher conversion rate? questions like,
26. Why does adding a feature take so long? questions like,
27. the answers are feedback telling us where we are
28. the answers are feedback suggesting where to go next
29. Small teams go Faster
30. let's talk about 1. projects 2. teams 3. developers
31. let's talk about 1. projects 2. teams 3. developers
32. 25% of projects fail
33. of projects fail [warning: made up on the spot] 25%
34. ohnoes!
35. ohnoes! that's way too low!
36. would you wager 75% of projects are Good Ideas?
37. plenty of ideas Ought to Fail
38. so you may as well Fail Quickly
39. but
40. but we're conditioned to Avoid Failure
41. How to Avoid Project Failure Through Project Planning and Effective Project Recovery Avoiding Project Failure: It's Not Rocket Science Real-Life Project Management Strategies that Fail and How to Prevent Project Failure To Avoid Failure, First Define Success CIO.com Avoid these common causes for project failure | TechRepublic Control Risk and Avoid Failure in Organisational Projects 5 ways to prevent IT failure | ZDNet Avoid Failure – Facilitate Effective Communications Avoiding software development failure not-made-up headlines
42. In order to avoid failure, we'll add more people
43. push back dates In order to avoid failure, we'll
44. sacrifice scope In order to avoid failure, we'll
45. limp into production In order to avoid failure, we'll
46. move the goalposts In order to avoid failure, we'll
47. therefore, succeed! In order to avoid failure, we'll
48. minimizing failure is a Poor Optimization
49. what does project Success Mean?
50. ostensibly, success is Return on Investment
51. but hardly anyone measures ROI
52. instead, success is Delivered On Time
53. instead, success is Delivered On Scope
54. instead, success is Delivered On Budget
55. but those are internal Arbitrary Metrics
56. they presume we Know what we Need
57. what if such a success were Never Purchased?
58. what if such a success were Disliked by Users?
59. what if such a success were Costly to Maintain?
60. why not optimize for Faster Feedback?
61. incentivize projects to Fail Faster
62. incentivize projects to Fail Faster everything v
63. with fast failure we can Try More Things
64. increasing our odds of Finding a Success
65. let's talk about 1. projects 2. teams 3. developers
66. big teams not all bad
67. successful big teams GET THEIR START as successful small teams
68. but why?
69. any new endeavor yields Lots of Questions
70. to answer those questions You Need Feedback
71. a feedback loop 1. get idea 2. implement idea 3. give it to users 4. learn from usage
72. the faster the loop the Sooner you Fail
73. the faster the loop the Sooner you Succeed
74. mature, successful endeavors Raise Fewer Questions
75. so they can survive with Slower Feedback
76. but regarding that New Venture of yours...
77. you should respect Communication Cost
79. 2 people 1 Connection
80. 3 people 3 Connections
81. 4 people 6 Connections
82. 5 people 10 Connections
83. 6 people 15 Connections
84. 7 people 21 Connections
85. 8 people 28 Connections
86. 9 people 36 Connections
87. 10 people 45 Connections
88. 11 people 55 Connections
89. 12 people 66 Connections
90. 13 people 78 Connections
91. 14 people 91 Connections
92. 15 people 105 Connections
93. 16 people 120 Connections
95. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 0 50 100 150 200 250 300 350 400 450 500
96. that's O(n2) 2 (and it's often called the handshake problem)
97. it slows down this loop 1. get idea 2. implement idea 4. learn from usage 3. give it to users
98. I believe agile Exacerbates all this
99. “ .” Ron Jeffries Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage.
100. xp values waterfall values communication follow the plan courage follow the plan feedback follow the plan simplicity follow the plan
101. healthy agile teams run on consensus
102. but the handshake problem suggests consensus doesn't scale
103. consensus corrects for the team's needs
104. feedback corrects for the users' needs
105. sadly, time spent gaining consensus costs you in feedback
106. because Consensus and Feedback compete for the same Resources
107. deliberation + communication introspection + + correction
108. it's easy to Confuse the Two
110. THIS BIG how can we build something with a small team?
111. is exactly the wrong question
112. This Small how can we build something and start failing or succeeding?
113. if Small Thing™ is wildly successful, then a team can grow organically
114. if Small Thing™ is a spectacular failure, then at least it was a small thing
115. how do you find a Small Thing?
116. one person can build it simplify the idea so much
117. any idea worth its salt can be simplified into one new thing
118. it took 8 years for the iPod to get an FM tuner
119. one person can build it simplify the idea so much
120. because great software is possible without a team
121. - Facebook for iPhone, Joe Hewitt - DNSimple, Anthony Eden - Instapaper, Marco Arment - Delicious Library, Wil Shipley - Redis, Salvatore Sanfilippo - The Hit List, Andy Kim - Alfred, Andrew Pepperrell - nginx, Igor Sysoev - Tweetie, Loren Brichter all solo acts
122. building a small thing has never been easier
123. if you require a team to build something small you've got bigger problems
124. ideally the idea person and the developer are the same person
125. because is faster than
126. so convince the developer to adopt the idea and then let him or her run with it
127. the trick is often Finding a Developer
128. let's talk about 1. projects 2. teams 3. developers
129. “ .” Fred Brooks Study after study shows that the very best designers produce structures that are faster, smaller, simpler, clearer, and produced with less effort. The differences between the great and the average approach an order of magnitude.
130. well, why didn't you say so! just hire one of the great ones!
131. "I'd like one great developer, please!"
132. "Awesome, I know HTML and some ActionScript!"
134. if you can find one, yay for you!
135. if you can find one, how are you sure you did?
136. validating someone is, in fact seems hard 10 times better
137. starting with just 1 developer can guide the search
138. generalists that means > specialists
139. well-rounded and > intelligent
140. succeed independently look for developers who can
141. succeed without you look for developers who can frankly,
142. traits observable of great developers
143. empathetic defends users by adopting their perspective
144. analytical breaks down large problems into smaller ones
145. visionary identifies a great idea and aggressively simplifies it
146. scientific methodically attacks problems, reducing paths of inquiry
147. creative dreams up new ideas continuously & asynchronously
148. professional invests in long-term value & maintainability of their work
149. entrepreneurial kills failing projects before over-investing in them
150. hungry relentlessly improves through learning, practicing, and sharing
151. ☐empathetic ☐analytical ☐visionary ☐scientific ☐creative ☐professional ☐entrepreneurial ☐hungry
152. non-technical folk Can Identify These
153. ☑ empathetic ☑ analytical ☐ visionary ☐ scientific ☑ creative ☑ professional ☐ entrepreneurial ☑ hungry I'd only entrust my big ideas with developers that embody most of these
155. we talked about 1. projects 2. teams 3. developers
156. let projects Fail
157. Communication is Critical
158. Communication is Critical but it isn't free
159. great developers are Willing to wear any hat
160. twitter: @searls email: searls@gmail.com github: https://github.com/searls blog: http://searls.test-double.com