Mob Programming is a development practice where the whole team works on the same thing, at the same time, in the same space, and on the same computer. It is a whole-team approach to doing all the work the team does including designing, coding, testing, and working with the customers, users and other stakeholders.

This is an evolutionary step beyond pair programming, and accentuates face-to-face communication, team alignment, collaboration, and self-organizing team concepts of the Agile approach to software development.

Using techniques and ideas such as the "Driver/Navigators" collaboration practice, one-piece flow, sustainable work habits, continuous learning, and a philosophy of "getting along", Mob Programming can be a highly effective approach to software development. Whether done "all day, every day", or in a more limited way for special problems, kick-offs, and learning sessions, it can be a fun way to get work done.

Companies and teams all over the world are using this team-based approach to sofware development. Please join me for this introductory presentation as I share how the concept got started, some of the benefits, some techniques we use, and some of the problems we've faced.


Outline/Structure of the Talk

This will be an introduction to Mob Programming, what it is, and the basic concepts.  This will mostly be a presentation with some audience interaction.

I'll share how we discovered Mob Programming, some basic principles and practices we use, and answer some common questions such as how we can be productive with 5 or 6 people at one computer, how to deal with some problems that might arise.  

There will be enough information so you can try this at your workplace if you think you would like to.

Learning Outcome

  • How 5+ people can be effective working on just one thing
  • Heuristics for team size
  • Guidelines for successful collaboration
  • Handling competing solutions and ideas to a coding problem
  • Encouraging politeness and kindness of team members
  • Reducing or eliminating harmful conflicts
  • Mobbing Mechanics
  • Tools for team coding
  • Workspace setup

Target Audience

All team roles, executives

schedule Submitted 5 years ago

  • Nancy Van Schooenderwoert

    Nancy Van Schooenderwoert - The Addiction Game

    90 Mins


persistently engaging in compulsive behavior which the addict knows to be harmful.

    Even the smartest teams and organizations can have addictions. It’s about habits and practices over time, not intelligence. And there is plenty you can do about it.

    The Addiction Game’s playing board is a diagram of the way addiction works – a quick feedback path for short-term relief, coupled with a slower feedback path for destructive consequences of the addictive behavior. Players nominate an addictive pattern, then take turn placing cards to identify its triggers, rewards, and painful effects. Addictive behaviors can include skipping tests, placing blame, writing long methods, and many more. Any destructive behavior that is self-reinforcing is a fair target for this game.

    Using prohibition - “Just say no” – to stop an addiction merely compounds the problem. An organization demanding ever higher velocity numbers from its Agile teams (addicted to the illusion of control) will find the teams redefining the meaning of story points to give bigger numbers.

    Prohibition is a static solution to a systemic problem. That’s why it doesn’t work. Using the game board we will play out Jerry Weinberg’s 3-step addiction cure:

    1. Stop doing X.

    2. Find an alternative solution Z that really works (and doesn’t create long term problems).
    3. Soften the short term pain, if necessary, but not with X.