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

Under Pressure

Under Pressure

This talk is an exploration of how we react to pressure on our software projects to GO FASTER!
Originally presented at Agile and Beyond 2017

Todd Kaufman

May 04, 2017
Tweet

More Decks by Todd Kaufman

Other Decks in Programming

Transcript

  1. Under
    Pressure
    Resisting the urge to GO FASTER

    View Slide

  2. My name is Todd Kaufman
    Tweet away @toddkaufman
    Say [email protected]

    View Slide

  3. Disclaimer: The stories you
    are about to hear are strictly
    HYPOTHETICAL

    View Slide

  4. The Team

    View Slide

  5. The Team

    View Slide

  6. The Team

    View Slide

  7. Iterations
    Points Remaining

    View Slide

  8. Iterations
    Points Remaining

    View Slide

  9. Iterations
    Points Remaining

    View Slide

  10. Iterations
    Points Remaining

    View Slide

  11. “We need to
    add more
    people!”

    View Slide

  12. “Let’s work
    weekends
    until we’re
    back on track!”

    View Slide

  13. “I’ll just skip
    tests for this
    feature and
    come back to
    do them later”

    View Slide

  14. Will we
    SPEED UP?

    View Slide

  15. Faster
    10%
    Slower
    90%
    Results

    View Slide

  16. and the cycle
    continues…

    View Slide

  17. How do we react
    to PRESSURE

    View Slide

  18. How can we avoid
    PRESSURE

    View Slide

  19. More People

    View Slide

  20. View Slide

  21. Does adding developers
    resources to a project,
    that is already late,
    speed it up?

    View Slide

  22. Nope

    View Slide

  23. View Slide

  24. Why is
    this?

    View Slide

  25. 1. Ramp up
    2. Communication
    3. Separation of work
    4. Integration
    5. Dysfunction

    View Slide

  26. “Adding manpower to
    a late software project
    makes it later.”
    Brook’s Law

    View Slide

  27. “Adding people to a
    dysfunctional software
    environment makes it
    even more inept.”
    Todd’s Law

    View Slide

  28. Instead

    View Slide

  29. Fix existing
    issues

    View Slide

  30. View Slide

  31. View Slide

  32. View Slide

  33. Remove
    negativity and
    waste

    View Slide

  34. More
    Commitment

    View Slide

  35. PMs like per
    sprint
    estimation

    View Slide

  36. Predictable
    outcomes

    View Slide

  37. Time
    1x
    .25x
    4x
    Cone of
    uncertainty

    View Slide

  38. Realistic cone
    of uncertainty

    View Slide

  39. Time
    1x
    .25x
    8x

    View Slide

  40. “When will
    we be done?”

    View Slide

  41. “We don’t
    know”

    View Slide

  42. One cannot simply
    change an estimate
    to a commitment

    View Slide

  43. #noestimates

    View Slide

  44. 3 possible
    outcomes

    View Slide

  45. 1. Nailed it!

    View Slide

  46. 2. Early

    View Slide

  47. 3. Late

    View Slide

  48. How does that
    affect the next
    estimation session?

    View Slide

  49. View Slide

  50. Instead

    View Slide

  51. #noestimates

    View Slide

  52. Cycle Time

    View Slide

  53. Quick
    Sizing

    View Slide

  54. More Stress

    View Slide

  55. Does applying
    pressure work?

    View Slide

  56. Stress
    Performance
    Fatigue
    Exhaustion
    ILL - Health
    Breakdown
    Comfort
    Zone

    View Slide

  57. What about
    creativity?

    View Slide

  58. Creativity
    Under the Gun

    View Slide

  59. Mon Tues Wed Thur Fri
    Creativity

    View Slide

  60. Mon Tues Wed Thur Fri
    Creativity

    View Slide

  61. Mon Tues Wed Thur Fri
    Creativity
    Planning
    Meeting

    View Slide

  62. Mon Tues Wed Thur Fri
    Creativity
    Planning
    Meeting

    View Slide

  63. Mon Tues Wed Thur Fri
    Creativity
    Planning
    Meeting

    View Slide

  64. Are developers
    lazy?

    View Slide

  65. not when
    properly
    motivated

    View Slide

  66. View Slide

  67. But we aren’t
    saving lives…

    View Slide

  68. Focus less
    on stress

    View Slide

  69. Instead

    View Slide

  70. Focus more
    on Why

    View Slide

  71. Cut
    Corners

    View Slide

  72. Do we reduce
    QUALITY in order
    to speed up?

    View Slide

  73. What is
    quality?

    View Slide

  74. “low Cyclomatic
    Complexity”

    View Slide

  75. “SOLID”

    View Slide

  76. “High Test
    Coverage!”

    View Slide

  77. Quality
    How easily
    and safely we can
    change a codebase

    View Slide

  78. Do we reduce
    QUALITY in order
    to speed up?

    View Slide

  79. Less
    Tests

    View Slide

  80. Less
    Refactoring

    View Slide

  81. More
    Complexity

    View Slide

  82. Less
    Comprehension

    View Slide

  83. More
    Defects

    View Slide

  84. More
    Rework

    View Slide

  85. Less Quality

    View Slide

  86. Less Speed

    View Slide

  87. Instead

    View Slide

  88. Resist!

    View Slide

  89. Make Debt
    Visible

    View Slide

  90. Pair More

    View Slide

  91. Estimation

    View Slide

  92. #noestimates

    View Slide

  93. Are there cases
    where we should
    estimate?

    View Slide

  94. “Is there
    a ROI?”

    View Slide

  95. $150k

    View Slide

  96. $150k
    $780k

    View Slide

  97. Left with only
    this data…

    View Slide

  98. We need
    estimation

    View Slide

  99. We need
    to get better at
    estimation

    View Slide

  100. Why is
    ESTIMATION
    so difficult?

    View Slide

  101. 1. Optimism
    Bias

    View Slide

  102. Other
    5%
    Programming
    95%
    Workday
    as we
    estimate it

    View Slide

  103. Other
    10%
    Cukes
    15%
    Meetings
    25%
    Work
    50%
    Workday
    as we
    live it

    View Slide

  104. 2. No two
    things are alike

    View Slide

  105. 3. Requirements
    suck

    View Slide

  106. “The ability to
    report on data”

    View Slide

  107. Instead

    View Slide

  108. Team Level
    Cycle Time

    View Slide

  109. Resist
    Change

    View Slide

  110. Leverage
    Spikes

    View Slide

  111. Adjust
    Fidelity

    View Slide

  112. Is it just a Lack
    of trust?

    View Slide

  113. Yes

    View Slide

  114. Have we
    earned it?

    View Slide

  115. No

    View Slide

  116. Discipline and
    Accountability

    View Slide

  117. Objectives
    Constraints
    Fidelity

    View Slide

  118. Communication
    Impediments
    Organization

    View Slide

  119. Estimation
    Quality
    Resistance

    View Slide

  120. Predictable
    over
    Quick

    View Slide

  121. Thank you!

    View Slide

  122. References:
    https://www.amazon.com/Exit-Voice-Loyalty-Responses-Organizations/dp/0674276604
    https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/
    0201835959
    http://dilbert.com/strip/2010-04-29
    https://hbr.org/2015/04/why-some-men-pretend-to-work-80-hour-weeks
    https://hbr.org/2002/08/creativity-under-the-gun
    http://www.construx.com/Resources/White_Papers/Managing_Technical_Debt/
    Icons:
    Dice by Hopkins from the Noun Project
    Clamp by Tomas Knopp from the Noun Project
    Quality badge by Gregor Cresnar from the Noun Project
    Communication by Oksana Latysheva from the Noun Project
    options by Bernar Novalyi from the Noun Project
    Unicorn by Lele Saa from the Noun Project
    Tshirt by Edward Boatman from the Noun Project
    Lock by Aleksandr Vector from the Noun Project

    View Slide

  123. View Slide