The Mythical Team-Month

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

E6c6e133e74c3b83f04d2861deaa1c20?s=128

Justin Searls

April 21, 2012
Tweet

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: searls@gmail.com github: https://github.com/searls blog: http://searls.test-double.com

  161. None