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.
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.
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?
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.
Hi Chris,
ReplyDeletevery 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 ?
Thanks,
Nicolas
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.
DeleteHi Chris -
ReplyDeleteI'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?
Hi Marsha,
DeleteI took this opportunity to write another blog :)
http://www.chrislucian.com/2016/05/documentation-in-mob.html
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.
Hi Chris,
ReplyDeleteanother 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,
Nicolas
Hey Nicholas! Sorry for the long delay in response. I was at the #Agile2016 conference before this so I am finally catching up.
DeleteI wrote a new blog as a response to your questions: http://www.chrislucian.com/2016/08/mob-programming-q-product-owners.html
Thanks for asking and let me know if you have more!