Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Justin Searls

April 21, 2012
Tweet

More Decks by Justin Searls

Other Decks in Technology

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

    View Slide

  161. View Slide