Mob Programming: Bring your own Mob
Mob Programming. Seems easy enough according to literature. Sit together somewhere, rotate roles, communicate. That on its own can quickly go south without following some core principles. But chances are, you're not optimizing this paradigm for your situation. Let me show you some good practices and how you can adapt Mob Programming to your individual needs. It's easy to get caught up in either following the literature too strictly or being too sloppy with the paradigm. Let me show you how to adapt Mob Programming to your needs without losing its core benefits. I can't hand you the one-size-fits-all solution, but I definitely can show you the right way to go and give you an advantage from the getgo, if you're completely new to it. From lots of experience I will talk about the Dos and Don'ts, and show you the Mob Programming ruleset I worked out together with my team. It gets even more interesting when you add someone, who doesn't develop, like a Tester, into mix. I will share with you the effects of that. Last, but not least, I want to briefly talk about resource considerations from a management perspective. A whole team is apparently working together on a single topic instead of parallelizing. Inefficient you might say. Or... is there more to discover behind the curtain?
