Remote Mob Programming Set Up

Mob programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer. This is similar to pair programming where two people sit at the same computer and collaborate on the same code at the same time.

A lot of things are being said on the benefits of mob programming and in my opinion they are probably all true. Given a team with similar values and individuals with the ability to put aside their personal preferences in order to move forward* you’ll see interesting results when you adopt it.  Sure, you might feel you’re going slower but you’re being the turtle, not the hare.

I’m not going to dive into the benefits, plenty of people do that. I just want to present my team’s set up for remote mob programming. We’ve had one person permanently remote for the past 3 months and I sometimes call in from home as well. Our team is The Perfect Size of 4.

 

We’ve got a mob station which is an adjustable standing desk, one stationary computer with two monitors, a really good microphone, a headphone splitter, one keyboard and one mouse.

The ergonomics

Having an adjustable desk means that you can switch between sitting and standing. If you have tried standing at work, you’ll know that you’re feeling more awake and that after a while your back will be stronger. We’re happy to have the option to stand while we’re working.

The visual

The monitors are mirroring each other so that it’s easier for everyone to see regardless of where you are standing around the table. There is less of a need to have a huge font size and some programs don’t even give you the option to increase the font size on the menus so having the monitor closer makes it a bit easier.

The coding

We use Teamviewer to share our mob station’s screen and it also lets the remote party have control of the mouse and keyboard. This makes for seamless rotation when switching driver. When you’re the one remote, it’s almost as typing live.

The audio hardware

Our microphone is a Blue Yeti which is a good quality usb microphone. It has a recording pattern which picks up sound primarily from the front of the microphone (and not all the way around) which helps a bit when you’re remote and the rest of the office is chatty.

We used to not use headphones but because of sound quality we would crank up the volume on the speakers to hear the remote party properly and that would disturb the rest of the office. So we wanted to switch to headphones.

In order to do so we started using a headphone splitter which allows us to connect up to five people to the same computer.

The Blue Yeti offers the ability to hook your headphones into the microphone which means that you can hear yourself speak as well.

This is very important because if you’re three people around a table all wearing good headphones, you actually won’t hear what the two others next to you are saying. You’ll only hear the remote party. By hooking in your headphone splitter into the microphone, you’ll hear everyone equally well.

To get this to work, make sure that the Yeti is both the recording device and the audio output in your call settings.

The audio software

Being a .Net shop we’ve switched from Slack to Microsoft Teams :O

It’s working well for us and we create a Teams meeting whenever someone uses the mob station and remote people can join the meeting if they want. It’s basically Skype but embedded in Teams and it does its job.

Summary

It’s taken us some time to find our set up. We started off with working on someone’s machine and each day had a bit of set up time to get things correct. The microphone had to be moved around, etc. Getting the headphone splitter made a huge difference for us (and the office) and getting the mob station also made a big impact.

By now, getting started is quick and easy and being remote for whatever reason isn’t an obstacle for team work.

PS. The Cucumber team is another remote team doing mob programming, here’s a article about their set up: https://cucumber.io/blog/2015/12/21/the-mob-rules-ok

 

*  in one team the first conflict to arise was “-that’s not way you write nice code! – yes, it is! – no, it isn’t! – yes it is!” kindergarten style… and no one budged.

Experience report: testing dojo with entire dev team

Last spring I worked as a test lead/quality coach for 3 teams that did their own testing. I experimented with different techniques to help them further improve their testing skills. I wrote this experience in March but I didn’t get around to publishing it then which I’m doing now.

I want to share with you another way of combining testing, learning and fun

At the Agile Testing Days in Potsdam/Berlin I accidentally ended up in a testing dojo session. For an hour, 4 pairs of testers tried their skills at a buggy piece of software and received feedback about their testing. It became immediately clear to me that this was a great opportunity to improve testing skills and I decided to try it at home with my teams.

I work as the sort of test lead who provides inspiration and encouragement for 3 teams of programmers who do their testing themselves. For our domain, web development, this works well. We have developed a testing strategy together and I also help them improve their testing skills. They are awesome, committed to continuously delivering value to our customers and eager to do a good job.

I planned a testing dojo of an hour and promised candy and laughs. The response was, to my relief, positive. I wasn’t sure that they would want to spend an hour of precious programming time doing testing. I chose an hour so that it wouldn’t be too long and it was easier to find a room and a time slot.

The preparations took a while because I needed to decide on a suitable piece of software and read up on dos and don’ts for testing dojos.

Finally, the software I picked was the one I had tested in Potsdam. It was crawling with bugs and this meant that everyone would find some. I thought this would be good for a first session to make everyone comfortable. It was also small enough to be constraining but big enough to allow people to try different areas. I also wanted to have something which no one in the teams had written themselves so that there wouldn’t be any awkward situations. This meant finding external software.

The parking rate calculator – object under test http://adam.goucher.ca/parkcalc/index.php

Format for the dojo
We had the 3 roles described in the testing dojo document. Every 5 minutes we rotated. We ended with a 10 minute debrief to discuss what we observed and what was good. http://www.testingdojo.org/tiki-index.php?page=Roles

Setting up the environment
I created a few posters which I put up on the walls. They detailed the format of dojo and the parking rates for everyone to see.

I explained carefully the purpose of the dojo. I put the emphasis on the fact the purpose was to learn from each other. This means that both observers and testers learn and we should be gentle to each other. It’s not easy to sit down a new computer and start testing in front of everyone, there needs to be humility from the audience for this. And on the other hand, active and good observers are key for learning.

How was it?
First of all, we had fun! The overwhelming buginess of the software created a lot of reactions: surprise, confusion, entertainment, frustration and joy.

The programmers were a bit overwhelmed by the amount of bugs. This is the downside of using this test object. In a normal situation I would just send it back after 2 minutes, but this isn’t a normal situation. I encourage splitting the debrief into two parts: “what did you think of the software?” and “what did you observe about the testing that we did?” or even say “let’s agree that the software is crap, but what did you observe about the testing?”.

It was clear that this was an ad hoc session. There was no plan and a lot of randomness. A few people started trying to be systematic but bugs caused them to lose focus. We tried a bit of everything, here and there.

This was a good thing though. For the group to observe this randomness was interesting. It shows well of you can spend an hour testing without knowing much more than when you started. When answering the question “what would you do differently if you did it again?” the group answered that they would be more systematic or organized. We also tried to highlight some of the things that the participants had done successfully.

What now?
We will do it again. This time I want to start with creating a plan together and see the difference in an organized approach. After this I think we’re ready for code closer to our domain or maybe even our own code.

Conclusion
I strongly recommend doing this kind of exercise with your team or your peers. It’s fun, interesting and a great opportunity to pick up new skills.

 

30 day experiment: tools for reading more easily and therefor more

In order to succeed with my 30 day experiment of reading every day, I spent a bit of time setting up. I created an Instapaper account and bought the android app for my phone, I downloaded some audiobooks with Audible and their android app and I made sure had something to read on my Kindle.

Instapaper is an awesome tool which helps you deal with all of those interesting articles your friends send to you or you find on Twitter but you don’t have the time to read right now. Instead you click “read later” and Instapaper will save a copy in an easy to read format for you. At some other time, when you have time to read, you can bring up your list of articles and read them.

Audible is a site where you can purchase audiobooks, it allows you to access your books on a mobile phone, an ipod, your kindle, etc. I prefer the android app and I find that it works very well.

For me, I use audible when watching my kid play in the playground or when riding my bike to work. Instapaper and Kindle I use on the subway.

I also tried sending my Instapaper articles to my Kindle but I don’t recommend it. Instapaper sends articles periodically (daily, weekly, etc) and the title of the document in Kindle is the date on which it was sent. This makes it hard to find a specific article.

Having these things set up, I had prepared for success and I don’t think I would have met my goal without the preparations.

Try something new for 30 days

At the Agile Sweden (Agila Sverige) conference which I participated in organizing there was a talk about making changes stick. The presenter had been inspired by Matt Cutts’ TED talk and had tried out a few things for 30 days. He gave some tips to succeeding, for example only take on one challenge at the time and let people know that you are doing a challenge.

This is me letting you know that my 30 day challenge (started on May 2nd) is to read something every day! It’s not a big change from daily life but/there fore I think that it’s a good step for a first challenge.

I’ve charged my Kindle, downloaded an Audible book to my mobile phone and created an instapaper account. I’m setting myself up for success by making sure there will always be something to read.

I highly recommend Matt’s TED talk which is only 3½ minutes and really inspiring.

And also, if you want to try it but need a few good ideas, Matt writes about his challenges on his blog.