Job Opening: Principal Software Engineer - Mob (US, CAN, MX)
Hunter Industries Careers

Mob Programming Q&A

As of 2016 I have been mob programming for about 4 and a half years. My teams are currently expanding the practice as we grow from about 5 people to about 24 mob programmers. Recently I was asked number of questions about mob programming, many of them have answered few times before so I decided to write a blog about it.

Recently I was asked number of questions about mob programming, many of them have answered few times before so I decided to write a blog about it.

Q: What development methodologies did you use before you started mob programming?

A: Before our group started mob programming we were primarily a more waterfall type Development Group. We had large specification documents, 6 months to yearlong delivery times. All of the developers worked in their own individual cubes and we had a bug tracker full of bugs.
The main agile practice that we adopted before we started mob programming was agile retrospectives. The Catalyst that caused us to make the transition was when a developer asked for help and we began to work with them. We then retrospective and found that it worked better for us than working alone.

Q: What are the size of applications that your team works on? How many users do your application support?

A: When we initially made the transition to mob programming we were working on applications that supported tens to hundreds of people. Now that Mom programming has proven to be so successful for us over time we have begun to work on applications for the company that will reach hundreds of thousands to hundreds of thousands.

The applications we develop are both internal and external.

What is your definition of done for a typical user story?

Q: What languages do you use? What tools are used for testing and development?

A: We’ve traditionally been a dot net shop however we’ve recently moved to working in Cloud Technologies the ad for stats away from dotnet Technologies. We are not working and both gotten it and node stacks.
We fully tdd all of our code and we have begun to use Behavior tests to enable us to do continuous integration. In the note environment we are currently using chimp, wallaby, cucumber, mocha, and Istanbul to do all of our Behavior driven front end testing. In the dotnet stock we are using coded UI test and gherkin to accomplish a similar goal. We are also using go CD which is a continuous integration and continuous delivery pipe lining tool.

Q: What is your definition of done for a typical user story? How much documentation do you produce? How do you handle documentation for a system that will be handled by a group who has not worked on the application before?

A: Definition of done is a feature that is tested and has run all the way through our pipeline and is deployed to our production or production like environment. We typically can see our automation tools run through the entire process.
We try and keep our documentation minimal however we do keep diagrams of high-level architecture. Our real documentation is the unit tests and Behavior test. We like to see that all of the functionality in the application can be expressed by the gherkin language.

Q: Do you have any metrics for the transition you experience between your old methodology and MOB programming?

A: I think the best metric that we got out of transitioning to mob programming was the fact that our release times I went from being six months to a year down to daily or even twice a day. The sheer amount of features we are able to release had increased dramatically with far fewer bugs. There was actually a year and a half long period in which we received no bug reports for new systems we developed.

Q: What type of Hardware do you use when you are mob programming? How do you handle different vision and ergonomic requirements?

What type of Hardware do you use when you are mob programming?

A: We currently have 2 Vizio 80-inch 4K televisions for each mob. They are mounted on Wheels mounts so we can move them around, and they are adjustable in height. We used two keyboards and two mice connected to the same computer. We use the approvals library in most of our code so we want to optimize for hard drive read speeds to make our tests run faster as we are doing the development process. A little bit more about our environment, all of our tables are on wheels and we’ve begun to have some standing keyboards that are at different stations. Also to note we use the Mob Programming timer to help us know when to switch people at the keyboard.

Please leave questions or comments I would love to address more questions here.


  1. Hi Chris,

    very interesting post. I've got one question about tests.

    Do you make your BBD tests only via coded UI tests ? The UI can be quite unstable when under development.
    Don't you make some of them below the UI ?
    Or do you consider that tests that are non UI tests are unit tests ?



    1. As of now we using Gherkin to describe UI tests only. We use unit tests (both assertions and approvals) to test everything under the UI. It is really a question of Integration vs Non Integration tests. Out Coded UI / Selenium tests are all at the integration level. Anything that is testing a single component by itself or a series of components not fully integrated we consider a unit test and do not describe them with Gherkin. We instead use the “Arrange / Act / Assert”, “Arrange Verify”, and “Describe / It (in node)” patterns for unit tests.

  2. Hi Chris -

    I'm scrum master on the team behind the email that prompted this blog entry. Thanks for the detailed answers!

    I'm interested in what sort of documentation you generate. Are the test cases described outside of the actual code? Are there any manual cases and are they documented at all? Do you contribute to any training or user guides?

    1. Hi Marsha,
      I took this opportunity to write another blog :)

      I hopefully have addressed those questions in the blog. We do welcome visitors as well and I expect we could have a great conversation in person.

  3. Hi Chris,
    another question comes to my mind. Mob Programming requires a great avaialability form the business, because they have to validate the many baby steps that you do.

    I have several questions in fact :
    1/ how is the business organized to work with the mob programming teams. Do you use the traditional scrum pattern : one Product Owner per product, that represents all the different business stakeholders and that is empowered to make all decisions about the product?
    Or do you have several business representatives for one product, that can come and validate what you are doing?

    2/ Are the business representatives co-located with the team all day long ?

    3/ Did you have to coach the business to have them working in a proper way with the programming team ? Did you ask them to follow some specific rules to communicate with the team ?

    4/ What did the team do to have a great communication with the businness ?

    Thanks in advance,


    1. Hey Nicholas! Sorry for the long delay in response. I was at the #Agile2016 conference before this so I am finally catching up.

      I wrote a new blog as a response to your questions:

      Thanks for asking and let me know if you have more!