My team decided to do a MOB programming in one of our tickets.

New joiner: Perfect we did a mob yesterday .

Me: Great, that's good. How did it go?

New joiner: Well, we work together in the gaming room next to each other and trying to solve the issue. I think it's very productive.

Me: Awesome! Let's do it again today... When we started the MOB, all of them are using their own laptop. And I was like.. so, this is how you did the MOB yesterday?

New guy: Yes.

Me: This is not a MOB programming... MOB programming uses only 1 screen, 1 driver and everyone work together, will tell the driver what to do, we need to exchange the driver every 10 to 15 minutes, everyone can be a driver. (devs, qa, ux, product) and do a retro after.

New guy: ah.. wow! Interesting.

  • 3
    I've never heard of mob programming. Is it meant as a training tool or a larger version of xtreme programming
  • 1
    Brainstorming session? Cool. But this sounds like a horrid extension of the already horrid pair programming practice (a practice I personally despise but which some out there do like. But really, it does suck).
  • 0
    Be ready to deliver less. When a team starts to mob program, the amount of tasks completed per sprint will decrease – but the aim of practicing mob programming is not to deliver more or faster in anyway. The goals should be very clear to everyone:

    Preventing silos, no standup required, joined ownership

    Instant knowledge exchange and technical upskilling 

    New joiners can be productive from day one without domain knowledge

    Producing higher quality code and shared code styles

    Wisdom of the crowd, resolving blockers in one session and getting things finished

    Good to read some good example from this article: The more extreme pair programming

Add Comment