$30 off During Our Annual Pro Sale. View Details »

To pair, or not to pair

To pair, or not to pair

A talk about pair programming, an agile development practice that still has only relatively patchy adoption across the industry. I talked about a few of the top benefits, then highlighted the challenges, and talked about why I believe those challenges are worth the hassle.

Presented at ThoughtWorks events in Munich and Hamburg, November 2018

Birgitta Boeckeler

November 27, 2018
Tweet

More Decks by Birgitta Boeckeler

Other Decks in Technology

Transcript

  1. To Pair, or not to Pair
    Birgitta Böckeler | @birgitta410

    View Slide

  2. 1940s: The first programmers

    View Slide

  3. “Betty Snyder and I, from the
    beginning, were a pair. And I believe
    that the best programs and designs
    are done by pairs, because
    you can criticise each other,
    and find each other’s errors,
    and use the best ideas.”
    Jean Bartik
    http://www.computerhistory.org/revolution/birth-of-the-computer/4/78/2258
    1940s: The first programmers

    View Slide

  4. 30-40 years later
    https://twitter.com/MrAlanCooper/status/1060553914209071106

    View Slide

  5. Another 10-20
    years later

    View Slide

  6. View Slide

  7. View Slide

  8. 1
    IT’S A
    LONG
    GAME.

    View Slide

  9. https://martinfowler.com/bliki/PairProgrammingMisconceptions.html

    View Slide

  10. 2
    ONE DOES
    NOT SIMPLY
    PAIR
    PROGRAM.

    View Slide

  11. IS IT WORTH
    THE HASSLE?
    CHALLENGES
    BENEFITS

    View Slide

  12. BENEFITS

    View Slide

  13. View Slide

  14. 1 + 1 > 2

    View Slide

  15. 1 + 1 > 2
    Knowledge sharing
    Combine 2 modes of thinking:
    Tactical and strategic
    Helps you get unstuck
    Onboarding

    View Slide

  16. !

    View Slide

  17. AVOID WASTE

    View Slide

  18. „THE 7 WASTES OF SOFTWARE DEVELOPMENT“
    Mary & Tom Poppendieck: „Implementing Lean Software Development: From Concept to Cash“

    View Slide

  19. Partially Done Work
    Extra Features
    Relearning
    Handoffs
    Delays
    Task Switching
    Defects
    „THE 7 WASTES OF SOFTWARE DEVELOPMENT“ *
    Mary & Tom Poppendieck: „Implementing Lean Software Development: From Concept to Cash“

    View Slide

  20. Partially Done Work
    Extra Features
    Relearning
    Handoffs
    Delays
    Task Switching
    Defects
    „THE 7 WASTES OF SOFTWARE DEVELOPMENT“ *
    Mary & Tom Poppendieck: „Implementing Lean Software Development: From Concept to Cash“

    View Slide

  21. Partially Done Work
    Extra Features
    Relearning
    Handoffs
    Delays
    Task Switching
    Defects
    „THE 7 WASTES OF SOFTWARE DEVELOPMENT“
    Mary & Tom Poppendieck: „Implementing Lean Software Development: From Concept to Cash“

    View Slide

  22. Partially Done Work
    Extra Features
    Relearning
    Handoffs
    Delays
    Task Switching
    Defects
    „THE 7 WASTES OF SOFTWARE DEVELOPMENT“ *
    Mary & Tom Poppendieck: „Implementing Lean Software Development: From Concept to Cash“

    View Slide

  23. 1 handoff 2 handoffs 3 handoffs 4 handoffs 5 handoffs
    Knowledge lost in handoffs
    Mary & Tom Poppendieck: „Implementing Lean Software Development: From Concept to Cash“

    View Slide

  24. Seen on https://devops.com/dark-side-infrastructure-code/

    View Slide

  25. FLOW

    View Slide

  26. FLOW
    Focus

    View Slide

  27. Kathy Sierra, „Your brain on multitasking“
    https://headrush.typepad.com/creating_passionate_users/2005/03/your_brain_on_m.html

    View Slide

  28. FLOW
    Focus
    Reduced team WIP

    View Slide

  29. Kathy Sierra, „Your brain on multitasking“
    https://headrush.typepad.com/creating_passionate_users/2005/03/your_brain_on_m.html

    View Slide

  30. TRUE CONTINUOUS
    INTEGRATION

    View Slide

  31. TRUE CONTINUOUS
    INTEGRATION
    Code review “on-the-go”
    Collective code ownership
    >>Trunk-based development

    View Slide

  32. CHALLENGES
    BENEFITS
    1+1>2
    AVOID WASTE
    CONT. INTEGRATION
    FLOW

    View Slide

  33. ENERGY

    View Slide

  34. ENERGY
    Don’t pair 8 hours a day
    Take breaks
    Switch roles and modes

    View Slide

  35. COLLABORATION

    View Slide

  36. COLLABORATION
    Feedback
    Exchange “READMEs”
    Awareness of your differences

    View Slide

  37. IT’S PERSONAL

    View Slide

  38. “To pair requires vulnerability.
    It means sharing all that you know
    and all that you don’t know.
    This is hard for us.”
    Tom Howlett, “The Shame of Pair Programming”
    https://diaryofascrummaster.wordpress.com/2013/09/30/the-shame-of-pair-programming/

    View Slide

  39. “you can criticise each other
    and find each other’s errors”

    View Slide

  40. IS IT WORTH
    THE HASSLE?
    CHALLENGES
    ENERGY
    INTENSE COLLAB.
    IT’S PERSONAL

    BENEFITS
    1+1>2
    AVOID WASTE
    CONT. INTEGRATION
    FLOW

    View Slide

  41. Concentration
    Giving & Receiving
    Feedback
    Task organisation
    Time management
    Empathy
    Communication

    View Slide

  42. Pia Nilsson, “Knowing Me, Knowing You - Growing teams to continuously deliver”
    https://www.youtube.com/watch?v=S92vVAEofes

    View Slide

  43. Pia Nilsson, “Knowing Me, Knowing You - Growing teams to continuously deliver”
    https://www.youtube.com/watch?v=S92vVAEofes
    Diversity

    View Slide

  44. https://hbr.org/2016/09/diverse-teams-feel-less-comfortable-and-thats-why-they-perform-better
    “Homogeneous teams feel easier – but
    easy is bad for performance”
    Fluency Heuristic

    View Slide

  45. Pia Nilsson, “Knowing Me, Knowing You - Growing teams to continuously deliver”
    https://www.youtube.com/watch?v=S92vVAEofes

    View Slide

  46. IT’S FUN!

    View Slide

  47. View Slide

  48. EMBRACING CHANGE
    += EMBRACING FRICTION

    View Slide

  49. To Pair, or not to Pair
    Do something today that your future self will thank you for.
    Birgitta Böckeler | @birgitta410

    View Slide