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 full-size slide

  2. FIRST
    first things

    View full-size slide

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

    View full-size slide

  4. this isn't
    Management

    View full-size slide

  5. Small teams
    go Faster

    View full-size slide

  6. but claiming that
    Small teams
    go Faster
    requires definitions

    View full-size slide

  7. but claiming that
    Small teams
    go Faster
    requires definitions

    View full-size slide

  8. but claiming that
    Small teams
    go Faster
    requires definitions

    View full-size slide

  9. let's start with
    small

    View full-size slide

  10. scrum says
    +/-
    7 2

    View full-size slide

  11. small is
    having
    nowhere
    to hide

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  16. Answer a
    Question
    faster is taking less time to

    View full-size slide

  17. questions like,
    Is this
    feature
    possible?

    View full-size slide

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

    View full-size slide

  19. Will
    customers
    use it?
    questions like,

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  24. the answers are
    feedback
    telling us where
    we are

    View full-size slide

  25. the answers are
    feedback
    suggesting where
    to go next

    View full-size slide

  26. Small teams
    go Faster

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  29. 25%
    of projects fail

    View full-size slide

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

    View full-size slide

  31. ohnoes!
    that's way too low!

    View full-size slide

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

    View full-size slide

  33. plenty of ideas
    Ought to Fail

    View full-size slide

  34. so you may as well
    Fail Quickly

    View full-size slide

  35. but we're conditioned to
    Avoid Failure

    View full-size slide

  36. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  43. minimizing failure is a
    Poor Optimization

    View full-size slide

  44. what does project
    Success Mean?

    View full-size slide

  45. ostensibly, success is
    Return on Investment

    View full-size slide

  46. but hardly anyone
    measures ROI

    View full-size slide

  47. instead, success is
    Delivered On Time

    View full-size slide

  48. instead, success is
    Delivered On Scope

    View full-size slide

  49. instead, success is
    Delivered On Budget

    View full-size slide

  50. but those are internal
    Arbitrary Metrics

    View full-size slide

  51. they presume we
    Know what we Need

    View full-size slide

  52. what if such a success were
    Never Purchased?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  55. why not optimize for
    Faster Feedback?

    View full-size slide

  56. incentivize projects to
    Fail Faster

    View full-size slide

  57. incentivize projects to
    Fail Faster
    everything
    v

    View full-size slide

  58. with fast failure we can
    Try More Things

    View full-size slide

  59. increasing our odds of
    Finding a Success

    View full-size slide

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

    View full-size slide

  61. big teams
    not all bad

    View full-size slide

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

    View full-size slide

  63. any new endeavor yields
    Lots of Questions

    View full-size slide

  64. to answer those questions
    You Need Feedback

    View full-size slide

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

    View full-size slide

  66. the faster the loop
    the Sooner you Fail

    View full-size slide

  67. the faster the loop
    the Sooner you Succeed

    View full-size slide

  68. mature,
    successful
    endeavors
    Raise Fewer
    Questions

    View full-size slide

  69. so they can survive
    with Slower Feedback

    View full-size slide

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

    View full-size slide

  71. you should respect
    Communication Cost

    View full-size slide

  72. 2 people
    1 Connection

    View full-size slide

  73. 3 people
    3 Connections

    View full-size slide

  74. 4 people
    6 Connections

    View full-size slide

  75. 5 people
    10 Connections

    View full-size slide

  76. 6 people
    15 Connections

    View full-size slide

  77. 7 people
    21 Connections

    View full-size slide

  78. 8 people
    28 Connections

    View full-size slide

  79. 9 people
    36 Connections

    View full-size slide

  80. 10 people
    45 Connections

    View full-size slide

  81. 11 people
    55 Connections

    View full-size slide

  82. 12 people
    66 Connections

    View full-size slide

  83. 13 people
    78 Connections

    View full-size slide

  84. 14 people
    91 Connections

    View full-size slide

  85. 15 people
    105 Connections

    View full-size slide

  86. 16 people
    120 Connections

    View full-size slide

  87. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  90. I believe agile
    Exacerbates all this

    View full-size slide


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

    View full-size slide

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

    View full-size slide

  93. healthy agile teams
    run on consensus

    View full-size slide

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

    View full-size slide

  95. consensus corrects for the
    team's needs

    View full-size slide

  96. feedback corrects for the
    users' needs

    View full-size slide

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

    View full-size slide

  98. because
    Consensus
    and
    Feedback
    compete for the same
    Resources

    View full-size slide

  99. deliberation
    +
    communication
    introspection
    +
    +
    correction

    View full-size slide

  100. it's easy to
    Confuse the Two

    View full-size slide

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

    View full-size slide

  102. is exactly the
    wrong question

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  106. how do you find
    a Small Thing?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  111. because
    great software
    is possible
    without a team

    View full-size slide

  112. - 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 full-size slide

  113. building a small thing
    has never been easier

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  116. because
    is faster than

    View full-size slide

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

    View full-size slide

  118. the trick is often
    Finding a Developer

    View full-size slide

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

    View full-size slide


  120. .”
    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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  127. starting with just
    1 developer
    can guide the search

    View full-size slide

  128. generalists
    that means
    >
    specialists

    View full-size slide

  129. well-rounded
    and
    >
    intelligent

    View full-size slide

  130. succeed independently
    look for developers who can

    View full-size slide

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

    View full-size slide

  132. traits
    observable
    of great developers

    View full-size slide

  133. empathetic
    defends users by
    adopting their perspective

    View full-size slide

  134. analytical
    breaks down large problems
    into smaller ones

    View full-size slide

  135. visionary
    identifies a great idea
    and aggressively simplifies it

    View full-size slide

  136. scientific
    methodically attacks problems,
    reducing paths of inquiry

    View full-size slide

  137. creative
    dreams up new ideas
    continuously & asynchronously

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  142. non-technical folk
    Can Identify These

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  145. let projects
    Fail

    View full-size slide

  146. Communication
    is Critical

    View full-size slide

  147. Communication
    is Critical
    but it isn't free

    View full-size slide

  148. great developers are
    Willing
    to wear any hat

    View full-size slide

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

    View full-size slide