The Mythical Team-Month

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

78. None

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

94. None

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

109. None

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!"

133. None

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
154. None

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: [email protected] github: https://github.com/searls blog: http://searls.test-double.com

161. None