Leading up to the tour stop, it was specifically requested that I would facilitate a team new to mob programming. As it would happen, this would be the start of a month of primarily spreading some mob programming love to no less than seven different teams. But I digress.
Arriving on Monday morning, I was greeted by the team and did a brief introduction to the concept. At this point I had yet to put together some suitable introductory material to mob programming, but I began by comparing and contrasting it to pair programming. The team didn't practice pairing a great deal, but it was a familiar enough concept to highlight the common pitfalls of it and how mob programming alleviates some of them.
With that done, we got to work. The task at hand was to continue building on a new fund market system. Avanza is moving towards a microservice architecture. Unlike many other organisations doing the same, only a single programming language, Java, in conjunction with an internally developed framework, Astrix, is to be used. That said, there's still plenty of legacy code to maintain and to gradually replace over time.
Personally, I decided on doing things a little bit differently than how I usually introduce mob programming. This time around, I would remain a facilitator, not diving into the mob rotation as I usually do. Pleasingly enough, they had set aside four consecutive days for getting into mob programming so we would have ample time to go through the motions. It also allowed me to start with the basics and add concepts over time.
For example, whereas the first two days were used to get into the habit of rotating the driver and taking micro-pauses when needed, on the third day I handed over the time-tracking to the mob and asked for a clear goal for the team to strive for during the day. On the final day, I purposefully arrived after the designated start time. Just as I had hoped, the mob had already setup and wasn't waiting for me. To my even greater delight, Tobias asks if anyone wants to change something about the workflow. Unanimously, the mob decides to shorten the naming discussions they had run into the previous day.
Not waiting for a bi-weekly retrospective to address concerns about the way you work? Nice!
Speaking of retrospectives, apart from the usual five minute retros held at the end of each day, the last day saw a longer mob retro in the afternoon. To keep it short and focussed on turning up the good, I asked four questions.
- What was the best?
- What was most difficult?
- What would you like to change or improve?
- What surprised you the most?
As with most team's I've facilitated, knowledge sharing was a clear winner. And as with most other teams, the fact that mob programming works, more precisely works for our team, tended to be the greatest surprise though that question tends to be answered less unanimously. The team seemed interested in doing more mob and pair programming in the future.
Later it would turn out that the team decided to schedule mob programming for at least a day at every sprint start where they tackle the toughest task together. I find it especially warming to know that I've had some form of lasting impact during my brief journeyman tour stops.
Overall, I was greatly impressed by how quickly the team got used to mob programming and how well they worked together. Clearly, this is a group of people that like one another!
Thanks Avanza and Team Extrahandel for having me!
With the main story behind us, I've a few more remarks to make.
Total eclipse of the editor
As with many other teams I've worked with, everyone's not using the same editor. In this case the team was split down the middle between Eclipse and IntelliJ. As a compromise, we decided on using Eclipse the first two days and then switching to IntelliJ. Doing so, I hoped would lower the barrier for driving at another team member's computer during pair programming in the future. Also, it immediately showcased the knowledge sharing aspects of mob programming when some of the first questions raised where of the sort of how do I do this thing I can do in IntelliJ in Eclipse or straight admissions of not being all-knowing, e.g. you'll have to help me with Eclipse. When the time came to switch to IntelliJ, a few essential keyboard shortcuts were written on a whiteboard to get the Eclipse users going.
I'm certainly not of the opinion that a team only can use a single editor. I do believe that it's in a team's best interest to be able to comfortably use each other's development environments so that the risk of avoiding an active role in a pair or mob programming session is minimised. In this case, I believe the team excelled in handling the situation.
Low resolution, high resolve
Throughout my stay, we often had to change rooms one or twice per day, inadvertently mimicking the experience the very first mob had a Hunter Technologies years ago. The quality of the displays in the different rooms varied widely. Running Eclipse on a 1024x768 display is interesting to say the least. The mob wasn't deterred by this though and most rooms had decent displays in one form or the other.
Still, it's yet another example of how most modern offices aren't really made to support mob programming. Open office landscapes are especially atrocious as they actively counters collaboration by encouraging developers to create their own bubbles using noise-cancelling headphones. Avanza's offices are far from the worst I've seen in this regard. Actually, there are a decent amount of conference rooms throughout the building and if a team really wanted to, workstations could be rearranged to support more permanent mob programming setups. Not all offices I've visited are quite so fortunate. If you're looking at a new office for your company, keep the notion of enabling team rooms in mind.
Git over here
An interesting pain point we ran into had to do with the way version control is used in combination with releases.
Every ten days the release train leaves the station. This means that whatever is in the Subversion trunk will be tagged and released the next week. This entails that the trunk must always be buildable. To enforce this, the automatic build system will lock the trunk, hindering further commits to be made if a build fails. Unlocking it requires for someone to acknowledge the build error and take it upon them self to sort it out.
Now, so far there's nothing too surprising about this. After all, keeping the main branch of your code base functional at all times is the standard modus operandi no matter what version control system you're using. However, couple this with generally avoiding the use of branches, partly by mandate, partly by Subversion not being nearly as good as Git at handling branches, and you run into the situation of sitting on more and more uncommitted code only kept locally at your development machine. This is clearly not an ideal situation and I know the larger Avanza development team is aware of it. I fully appreciate that moving from a huge Subversion repository to Git is not something done with a flick of your wrist, but from what I've seen, I'd highly recommend investing the time and effort required to do so.