The Mythical Team-Month

Transcript

1. the
   Mythical
   team-month
   

   View Slide

2. FIRST
   first things
   

   View Slide

3. @searls
   

   View Slide

4. http://test-double.com
   @testdouble
   

   View Slide

5. this isn't
   Management
   

   View Slide

6. Small teams
   go Faster
   

   View Slide

7. but claiming that
   Small teams
   go Faster
   requires definitions
   

   View Slide

8. but claiming that
   Small teams
   go Faster
   requires definitions
   

   View Slide

9. but claiming that
   Small teams
   go Faster
   requires definitions
   

   View Slide

10. let's start with
    small
    

    View Slide

11. scrum says
    +/-
    7 2
    

    View Slide

12. amazon says
    

    View Slide

13. small is
    having
    nowhere
    to hide
    

    View Slide

14. If I can get away with
    not focusing
    not trying
    not caring
    the team is not small
    {
    

    View Slide

15. defining
    

    View Slide

16. write a line of code?
    is faster taking less time to
    

    View Slide

17. is faster taking less time to
    release a feature?
    

    View Slide

18. earn a dollar?
    is faster taking less time to
    

    View Slide

19. Answer a
    Question
    faster is taking less time to
    

    View Slide

20. questions like,
    Is this
    feature
    possible?
    

    View Slide

21. Are we
    able to
    build it?
    questions like,
    

    View Slide

22. Will
    customers
    use it?
    questions like,
    

    View Slide

23. Will
    customers
    use it?
    Pay For
    ^
    questions like,
    

    View Slide

24. Can it handle
    1 million visits
    each day?
    questions like,
    

    View Slide

25. Which design
    achieves a higher
    conversion rate?
    questions like,
    

    View Slide

26. Why does adding
    a feature take
    so long?
    questions like,
    

    View Slide

27. the answers are
    feedback
    telling us where
    we are
    

    View Slide

28. the answers are
    feedback
    suggesting where
    to go next
    

    View Slide

29. Small teams
    go Faster
    

    View Slide

30. let's talk about
    1. projects
    2. teams
    3. developers
    

    View Slide

31. let's talk about
    1. projects
    2. teams
    3. developers
    

    View Slide

32. 25%
    of projects fail
    

    View Slide

33. of projects fail
    [warning: made up on the spot]
    25%
    

    View Slide

34. ohnoes!
    

    View Slide

35. ohnoes!
    that's way too low!
    

    View Slide

36. would you wager
    75%
    of projects are
    Good Ideas?
    

    View Slide

37. plenty of ideas
    Ought to Fail
    

    View Slide

38. so you may as well
    Fail Quickly
    

    View Slide

39. but
    

    View Slide

40. but we're conditioned to
    Avoid Failure
    

    View Slide

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
    

    View Slide

42. In order to avoid failure, we'll
    add more people
    

    View Slide

43. push back dates
    In order to avoid failure, we'll
    

    View Slide

44. sacrifice scope
    In order to avoid failure, we'll
    

    View Slide

45. limp into production
    In order to avoid failure, we'll
    

    View Slide

46. move the goalposts
    In order to avoid failure, we'll
    

    View Slide

47. therefore, succeed!
    In order to avoid failure, we'll
    

    View Slide

48. minimizing failure is a
    Poor Optimization
    

    View Slide

49. what does project
    Success Mean?
    

    View Slide

50. ostensibly, success is
    Return on Investment
    

    View Slide

51. but hardly anyone
    measures ROI
    

    View Slide

52. instead, success is
    Delivered On Time
    

    View Slide

53. instead, success is
    Delivered On Scope
    

    View Slide

54. instead, success is
    Delivered On Budget
    

    View Slide

55. but those are internal
    Arbitrary Metrics
    

    View Slide

56. they presume we
    Know what we Need
    

    View Slide

57. what if such a success were
    Never Purchased?
    

    View Slide

58. what if such a success were
    Disliked by Users?
    

    View Slide

59. what if such a success were
    Costly to Maintain?
    

    View Slide

60. why not optimize for
    Faster Feedback?
    

    View Slide

61. incentivize projects to
    Fail Faster
    

    View Slide

62. incentivize projects to
    Fail Faster
    everything
    v
    

    View Slide

63. with fast failure we can
    Try More Things
    

    View Slide

64. increasing our odds of
    Finding a Success
    

    View Slide

65. let's talk about
    1. projects
    2. teams
    3. developers
    

    View Slide

66. big teams
    not all bad
    

    View Slide

67. successful big teams
    GET THEIR START
    as successful small teams
    

    View Slide

68. but why?
    

    View Slide

69. any new endeavor yields
    Lots of Questions
    

    View Slide

70. to answer those questions
    You Need Feedback
    

    View Slide

71. a feedback loop
    1. get idea
    2. implement
    idea
    3. give it
    to users
    4. learn
    from usage
    

    View Slide

72. the faster the loop
    the Sooner you Fail
    

    View Slide

73. the faster the loop
    the Sooner you Succeed
    

    View Slide

74. mature,
    successful
    endeavors
    Raise Fewer
    Questions
    

    View Slide

75. so they can survive
    with Slower Feedback
    

    View Slide

76. but regarding that
    New Venture
    of yours...
    

    View Slide

77. you should respect
    Communication Cost
    

    View Slide

78. View Slide

79. 2 people
    1 Connection
    

    View Slide

80. 3 people
    3 Connections
    

    View Slide

81. 4 people
    6 Connections
    

    View Slide

82. 5 people
    10 Connections
    

    View Slide

83. 6 people
    15 Connections
    

    View Slide

84. 7 people
    21 Connections
    

    View Slide

85. 8 people
    28 Connections
    

    View Slide

86. 9 people
    36 Connections
    

    View Slide

87. 10 people
    45 Connections
    

    View Slide

88. 11 people
    55 Connections
    

    View Slide

89. 12 people
    66 Connections
    

    View Slide

90. 13 people
    78 Connections
    

    View Slide

91. 14 people
    91 Connections
    

    View Slide

92. 15 people
    105 Connections
    

    View Slide

93. 16 people
    120 Connections
    

    View Slide

94. View Slide

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
    

    View Slide

96. that's
    O(n2)
    2
    (and it's often called the
    handshake problem)
    

    View Slide

97. it slows down this loop
    1. get idea
    2. implement
    idea
    4. learn
    from usage
    3. give it
    to users
    

    View Slide

98. I believe agile
    Exacerbates all this
    

    View Slide

99. “
    .”
    Ron Jeffries
    Extreme Programming is
    a discipline of software
    development based on
    values of simplicity,
    communication,
    feedback, and courage.
    

    View Slide

100. xp values waterfall values
     communication follow the plan
     courage follow the plan
     feedback follow the plan
     simplicity follow the plan
     

     View Slide

101. healthy agile teams
     run on consensus
     

     View Slide

102. but the
     handshake
     problem suggests
     consensus
     doesn't
     scale
     

     View Slide

103. consensus corrects for the
     team's needs
     

     View Slide

104. feedback corrects for the
     users' needs
     

     View Slide

105. sadly,
     time spent
     gaining consensus
     costs you in
     feedback
     

     View Slide

106. because
     Consensus
     and
     Feedback
     compete for the same
     Resources
     

     View Slide

107. deliberation
     +
     communication
     introspection
     +
     +
     correction
     

     View Slide

108. it's easy to
     Confuse the Two
     

     View Slide

109. View Slide

110. THIS BIG
     how can we build something
     with a small team?
     

     View Slide

111. is exactly the
     wrong question
     

     View Slide

112. This Small
     how can we build something
     and start failing or succeeding?
     

     View Slide

113. if Small Thing™ is
     wildly successful,
     then a team can
     grow organically
     

     View Slide

114. if Small Thing™ is
     a spectacular failure,
     then at least it
     was a small thing
     

     View Slide

115. how do you find
     a Small Thing?
     

     View Slide

116. one person
     can build it
     simplify the idea so much
     

     View Slide

117. any idea worth its salt
     can be simplified
     into one new thing
     

     View Slide

118. it took 8 years
     for the iPod to
     get an FM tuner
     

     View Slide

119. one person
     can build it
     simplify the idea so much
     

     View Slide

120. because
     great software
     is possible
     without a team
     

     View Slide

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
     

     View Slide

122. building a small thing
     has never been easier
     

     View Slide

123. if you require a team
     to build something small
     you've got bigger problems
     

     View Slide

124. ideally
     the idea person
     and the
     developer
     are the
     same person
     

     View Slide

125. because
     is faster than
     

     View Slide

126. so convince the developer to
     adopt the idea
     and then let him or her
     run with it
     

     View Slide

127. the trick is often
     Finding a Developer
     

     View Slide

128. let's talk about
     1. projects
     2. teams
     3. developers
     

     View Slide

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.
     

     View Slide

130. well, why didn't you say so!
     just hire one of the great ones!
     

     View Slide

131. "I'd like one great
     developer, please!"
     

     View Slide

132. "Awesome, I know
     HTML and some ActionScript!"
     

     View Slide

133. View Slide

134. if you can find one,
     yay for you!
     

     View Slide

135. if you can find one,
     how are you
     sure you did?
     

     View Slide

136. validating someone
     is, in fact
     seems hard
     10 times better
     

     View Slide

137. starting with just
     1 developer
     can guide the search
     

     View Slide

138. generalists
     that means
     >
     specialists
     

     View Slide

139. well-rounded
     and
     >
     intelligent
     

     View Slide

140. succeed independently
     look for developers who can
     

     View Slide

141. succeed without you
     look for developers who can
     frankly,
     

     View Slide

142. traits
     observable
     of great developers
     

     View Slide

143. empathetic
     defends users by
     adopting their perspective
     

     View Slide

144. analytical
     breaks down large problems
     into smaller ones
     

     View Slide

145. visionary
     identifies a great idea
     and aggressively simplifies it
     

     View Slide

146. scientific
     methodically attacks problems,
     reducing paths of inquiry
     

     View Slide

147. creative
     dreams up new ideas
     continuously & asynchronously
     

     View Slide

148. professional
     invests in long-term value &
     maintainability of their work
     

     View Slide

149. entrepreneurial
     kills failing projects before
     over-investing in them
     

     View Slide

150. hungry
     relentlessly improves through
     learning, practicing, and sharing
     

     View Slide

151. ☐empathetic
     ☐analytical
     ☐visionary
     ☐scientific
     ☐creative
     ☐professional
     ☐entrepreneurial
     ☐hungry
     

     View Slide

152. non-technical folk
     Can Identify These
     

     View Slide

153. ☑ empathetic
     ☑ analytical
     ☐ visionary
     ☐ scientific
     ☑ creative
     ☑ professional
     ☐ entrepreneurial
     ☑ hungry
     I'd only entrust
     my big ideas
     with developers
     that embody
     most of these
     

     View Slide

154. View Slide

155. we talked about
     1. projects
     2. teams
     3. developers
     

     View Slide

156. let projects
     Fail
     

     View Slide

157. Communication
     is Critical
     

     View Slide

158. Communication
     is Critical
     but it isn't free
     

     View Slide

159. great developers are
     Willing
     to wear any hat
     

     View Slide

160. twitter: @searls
     email: [email protected]
     github: https://github.com/searls
     blog: http://searls.test-double.com
     

     View Slide

161. View Slide