This document discusses mob programming and ways to reduce feedback loops in coding. It describes the author's experience with mob programming on different projects involving 3-5 co-located programmers and sometimes remote members. Key aspects of mob programming discussed are strong-style pairing with designated driver and navigator roles, increased ownership and resilience from the whole team working on the same thing, and benefits like more just-in-time design discussions. The author also notes some challenges of mob programming including less flexibility and that it can look unusual to outsiders. Overall mob programming is presented as an effective way to continuously learn through reflection on shared work.

1. Mob Programming for
Continuous Learning
Mike Clement
@mdclement
mike@softwareontheside.com
http://blog.softwareontheside.com

2. My journey

4. “Review every line of code. A code review typically involves the
programmer and at least two reviewers. That means that at least three
people read every line of code. Another name for peer
review is "peer pressure." In addition to providing a safety net in case
the original programmer leaves the project, reviews improve code
quality because the programmer knows that the code will be read by
others. Even if your shop hasn't created explicit coding standards,
reviews provide a subtle way of moving toward a group coding
standard—decisions are made by the group during reviews, and over
time the group derives its own standards.”

5. “Review every line of code. A code review typically involves the
programmer and at least two reviewers. That means that at least three
people read every line of code. Another name for peer
review is "peer pressure." In addition to providing a safety net in case
the original programmer leaves the project, reviews improve code
quality because the programmer knows that the code will be read by
others. Even if your shop hasn't created explicit coding standards,
reviews provide a subtle way of moving toward a group coding
standard—decisions are made by the group during reviews, and over
time the group derives its own standards.”

6. Code Reviews

7.  


 



8. Benefits of Code Reviews
• Help from others
• Redundancy
• Readability
• Coding standards

11. How to reduce the length of the
feedback loop?

12. Informal Pairing

13.  




14. Informal pairing
• “On demand” collaboration
• Started to spend more time together

15. Randori

16. 


  


18. Utah Software Craftsmanship

20. How to reduce the length of the
feedback loop?

21. Pairing Time with Pairing Stations

22.  




24. Caves and Commons

25. Agile Software Development: The
Cooperative Game by Alistair Cockburn
Figure 3.1-1. Completed office layout
(Courtesy of Ken Auer, RoleModel
Software).

26. One navigator, many drivers

27. 
  
  
  
  

28. How to reduce the length of the
feedback loop?

29. Persistent, promiscuous pair
programming

30. 




31. 




32. Whole team ownership?

33. “You should really
talk to Woody Zuill.
You need to see
what they’re doing
at Hunter Industries”

34. http://mobprogramming.org/

36. All the brilliant people,
working on the same thing,
at the same time,
in the same space…

37. All the brilliant people,
working on the same thing,
at the same time,
in the same space,
and at the same computer.

39. How to reduce the length of the
feedback loop?

40. “Let’s try mob programming”

41. My experience

42. Mob #1

43. Mob #1
•3 co-located + 1 remote
•Pairing station

44.  
 

  

45. Whole team ownership of code!

46. Then we added a team member…

47.  
 

  

48. And the remote member moved
to be co-located…

49.  



50.  

 



51. A trip to San Diego

52. https://twitter.com/ChristophLucian/status/482651109173895168

53. Mob #2

54. Mob #2
•4 co-located including team lead
•2 80 inch TVs on the wall

55.   



58. Discoveries!

59. Physical space

61. Strong-style pairing

62. "For an idea to go from your head
into the computer, it MUST go
through someone else's hands"

63. Strong-style pairing
Driver
• At the keyboard
• “Smart keyboard”
• Trust your navigator
• Think the computer of the
Enterprise
Navigator
• Give verbal instructions to the
driver
• Talk at the highest level of
abstraction

64. Location
Detail

66. The hard work is when you’re
NOT at the keyboard

67. No standups!

68. More JIT code design

69. Increased “Bus Factor”

70. Resilient

71. Working on the right thing

72. Get things done and delivered

74. Downside?

75. Less worktime flexibility

76. Looks funny from the outside

77. And then product management…

78. Mob #3

80. Ways we use forms of Mobbing
•Large onsite with client workshops
•Workshops at our location
•Everyday work

81. One navigator, many pairs

82.   

  
  
  

84. One navigator, many mobs

85. 


 

89. Experience != Learning

90. Experience + Reflection =>
Learning

92.   



98. https://github.com/willemlarsen/mobprogrammingrpg

100. It’s not solo programming with a
group

101. It’s fun!

103. Mike Clement
• @mdclement
• mike@softwareontheside.com
• http://blog.softwareontheside.com
• https://github.com/mdclement
• http://agilecodegames.com
• Greater Sum
• @thegreatersum
• http://www.greatersum.com
• Software Craftsmanship Atlanta
• Find us on meetup.com

104. Resources
• http://mobprogramming.org/mob-programming-time-lapse-video-a-day-
of-mob-programming/
• Updated video: https://www.youtube.com/watch?v=dVqUcNKVbYg
• http://llewellynfalco.blogspot.com/2014/06/llewellyns-strong-style-
pairing.html
• Timer: https://github.com/MobProgramming/MobTimer.Python
• Mob Programming Conference:
http://agilegamesnewengland.org/index.php/mob-programming-
conference
• RPG: https://github.com/willemlarsen/mobprogrammingrpg
• Mobster Timer with RPG: https://github.com/dillonkearns/mobster