Download as PDF, PPTX
Uploaded byMike Clement
Mob Programming for Continuous Learning
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.
More Related Content
Similar to Mob Programming for Continuous Learning
Mob Programming for Continuous Learning
- 1. Mob Programming for ContinuousLearning Mike Clement @mdclement mike@softwareontheside.com http://blog.softwareontheside.com
- 2.
- 4. “Review every lineof 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 lineof 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.
- 7.
- 8. Benefits of CodeReviews • Help from others • Redundancy • Readability • Coding standards
- 11. How to reducethe length of the feedback loop?
- 12.
- 13.
- 14. Informal pairing • “Ondemand” collaboration • Started to spend more time together
- 15.
- 16.
- 18.
- 20. How to reducethe length of the feedback loop?
- 21. Pairing Time withPairing Stations
- 22.
- 24.
- 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, manydrivers
- 27.
- 28. How to reducethe length of the feedback loop?
- 29.
- 30.
- 31.
- 32.
- 33. “You should really talkto Woody Zuill. You need to see what they’re doing at Hunter Industries”
- 34.
- 36. All the brilliantpeople, working on the same thing, at the same time, in the same space…
- 37. All the brilliantpeople, working on the same thing, at the same time, in the same space, and at the same computer.
- 39. How to reducethe length of the feedback loop?
- 40. “Let’s try mobprogramming”
- 41.
- 42.
- 43. Mob #1 •3 co-located+ 1 remote •Pairing station
- 44.
- 45. Whole team ownershipof code!
- 46. Then we addeda team member…
- 47.
- 48. And the remotemember moved to be co-located…
- 49.
- 50.
- 51. A trip toSan Diego
- 52.
- 53.
- 54. Mob #2 •4 co-locatedincluding team lead •2 80 inch TVs on the wall
- 55.
- 58.
- 59.
- 61.
- 62. "For an ideato go from your head into the computer, it MUST go through someone else's hands"
- 63. Strong-style pairing Driver • Atthe 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.
- 66. The hard workis when you’re NOT at the keyboard
- 67.
- 68. More JIT codedesign
- 69.
- 70.
- 71. Working on theright thing
- 72. Get things doneand delivered
- 74.
- 75.
- 76. Looks funny fromthe outside
- 77. And then productmanagement…
- 78.
- 80. Ways we useforms of Mobbing •Large onsite with client workshops •Workshops at our location •Everyday work
- 81. One navigator, manypairs
- 82.
- 84.
- 85.
- 89.
- 90. Experience + Reflection=> Learning
- 92.
- 98.
- 100. It’s not soloprogramming with a group
- 101.
- 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/ • Updatedvideo: 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
Editor's Notes
- #18 Literally would look at the code from a different point of view
- #27 Guided katas at Ancestry Basically a traditional “code along with me” workshop
- #33 Everybody could contribute But didn’t get “pay off” at the end of something you started usually
- #39 Turn up the good
- #60 Additional monitors for build/electronic board Moved desk Switched to standing desk
- #66 Tried 8, 10, 12, 15 minutes Too short and don’t “feel” like you did much as driver Too long and you are away from keyboard too long Physical connection to work
- #71 Move in an out of mob fluidly Vacations didn’t require handoff planning Meetings might derail a pair
- #72 More AND less important to identify the right thing at any given moment
- #73 Don’t worry about release coordination (as much) Get small batches released quickly Cycle time was consistently lowest on our team Maybe not faster, but sooner
- #74 We focused on the work, not on the people
- #92 Highlight backgrounds