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

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