Experimenting with Focus Weeks and Mob Programming
At NEW WORK SE we love to gather new insights from experiments. Similar to researchers, we expect certain results for changes and based on them we decide where to go. On a technical level we use metrics like requests per second or compilation time, but also on the team level we are trying to measure if an experiment was successful. “Focus Weeks” and “Mob Programming” are two experiments we want to share in this article.
The Experiments
Our team is busy with different topics we work on. We offer QA tooling, dev tools, application frameworks and CI infrastructure to the company. Everybody can work on every topic, but everyone also has certain blind spots.
Focus Weeks are a way for the whole team to work together on one single topic to share knowledge and improve its implementation. All meetings are cancelled during the week, so we can work without distractions. We also just respond to urgent requests on our support channels. Before starting the week we plan what we want to achieve and after each day we reflect for half an hour, to see what went well and what we can improve. Many ideas to make Focus Weeks and Mob Programming better came from those reflections.
Mob programming is similar to pair programming, but you share the screen with a group of people. As with pair programming, one person is the driver (having control over the keyboard and writing code), and the others are the navigators (they keep their eyes on a wider view but also provide input on concrete code). Because everyone on the team has different skills and focus sets, it leads to better solutions as the problems are seen from different angles and the code and architecture is constantly being reviewed by the whole team. As you see, Mob Programming is not just about programming for us and we are often calling it Mob Engineering in our team.
We started the experiments with these hypotheses for Mob Programming:
- Learn about different approaches to given challenges
- Have a better mutual understanding about the code bases of our different products
- Have a better test coverage (i.e. by following TDD)
- In general: Improve our APIs by having “more eyes” on them
For Focus Weeks we had these ambitions:
We foster knowledge exchange within the team
- Colleagues feel more empowered to work in different domains
- We see more collaboration on topics that have been worked on in isolation before
- Bringing our different backgrounds together, we are able to tackle challenging issues in an efficient way
We bring the team together
- We see a positive tendency regarding the general mood in our team
- There is an increased sense of common ownership for the entirety of our products
Our Experiences
With those definitions given above, let’s see how we experienced our first two Focus Weeks. In our first Focus Week we worked on implementing the testing-library API for our Selenium based testing solution. At first we used TDD rotations to switch driver. With TDD rotations a test is written by one person, while another person writes the implementation. After some time we found that the rotation cycles varied widely in length. In some cases the implementation for a test was just a one liner, and in other cases the test could be mostly copy and pasted. As a solution to the different cycle lengths we came up with a Pomodoro approach, where we switch seats after a fixed time interval, in our case 20 minutes.
We found that architecture and code quality was improved after our first Focus Week, but at the same time you have to plan carefully together how to approach the challenge. We implemented many API methods, eager to try out Mob Programming, but in the end we found that essential parts for a full integration were missing. After our first Focus Week we found that early integration into the main branch can help to mitigate those problems. One result of this was that the second Focus Week contained a lot more planning.
Focus Weeks and Mob Programming are very intense. It is a lot of fun, but can be quite exhausting. In the first Focus Week we did all of our breaks together, which was not optimal for the different needs on the team. In the second Focus Week we decided that people who need a break can just “zone-out” to refresh their energies. This works well for us.
Another change we’ve made to our daily routine was to have one hour for everyone to work on daily support tasks. This prevented requests piling up during the week.
Our assumption that knowledge spreads very fast during Mob Programming and Focus Weeks was confirmed. From looking over the shoulders of the team members, everyone learned new approaches, tweaks, shortcuts and general insights. We also used the first Focus Week as an opportunity to on-board our latest hire, Robert:
“When I joined New Work we started with a full week of Mob Programming on our Selenium based testing framework. I was able to get to know everyone on the team well very fast and we had a lot of fun together. It was useful to find out how everyone works and to share knowledge within the team”
Our two experiments were fun and we think of them as successful. The idea is to have a Focus Week every six weeks. We already finished the second Focus Week and are looking forward to the next one!
Co-Authored-By: Robert Kowalski
