In a LeSS adoption the teams self-organised some time ago into end-to-end feature teams. Some of these teams need to find ways to share knowledge on a tool called PEGA. One of the PEGA experts approached us with the question on how to do this. We suggested to facilitate a session to introduce them to MOB-programming. After the session they should be able to do more mobbing by themselves if they think it was valuable.
Preparation
The subject matter expert had no idea what MOB programming actually looks like. I explained: “The primary goal of mobbing is to share knowledge. The principal idea is to use one computer to do all the work on. There will be two roles: a driver and a navigator. It’s like a rally car team: the navigator tells the driver where to go. When programming, the driver operates the computer keyboard and the navigator is the knowledgeable person who will tell the driver what to code. The code must go through two people’s heads. The team members will rotate to occupy the driver seat every 5 minutes. When you operate in the role of the navigator, ensure that you communicate respectfully. Remember the goal for the driver is to learn. Accommodate the level of abstraction of your instructions to the level of experience of the driver.”
There are some guidelines to help us making the session successful. Firstly, the group should not be too big (max 8) and secondly should be co-located. If there are remote participants, then everybody should be remote. The team is located in Belgium and the Netherlands. We agree the Belgian people will travel and come to Amsterdam. I get to know we need to involve 6 engineers in Pune India too. Although this is not according to guidelines and far from ideal, we decide to give it a try using one workstation in each location.
Setting up
The session starts with setting up the communication. This is a painful journey. Due to bank infrastructure restrictions and policies an a multitude of connection variations it takes us more than 1,5 hours to set up this configuration:
In each location, we have a big screen where we can see the IDE (the tool developers do their programming in). We need one or more laptops as cameras so we can all see each other from various angles. A Jabra is connected for sound. There is one remote participant who is not within the bank network. This complicates things a lot. There is no better connection for him than audio over phone. We agree to not involve him in the session at this time
Once the connections are finally up and running, our energy is pretty low. A small energizer does the trick to get us all back in the game. I collect the names of all participants (14), their years of programming experience and for fun a personal odd detail they want to share with us. This list serves as the schedule of driver rotation.
Round One
The drivers are alternating between locations every 5 minutes. We decide to start the session with an experienced developer to get into the mood. People are rather quiet and focused, curious for what is going to happen. Things get smoother after a couple of drivers have changed turns and we all understand the process. Then the Amsterdam navigator asks one of the devs in Pune to take over the navigator role. Surprisingly it works like a charm. Swapping the navigator role between locations keeps everybody highly engaged. One hour and twenty minutes later we have collectively built a basic feedback form and everybody understands how we did it.
After returning from lunch, I initiate a small retro. We focus on how we can improve what went well. Working in four small groups (diverge), all attendees find improvement proposals and we merge the findings. The overall impression is that MOB programming is a great approach to share knowledge and create learning. The improvement experiments we discovered in our session were:
- more time per driver
- stick to one location longer
- have a explanation session on solution first
- have a purpose/design session first
- work on real backlog work instead of fake functionality
- less participants in the session would be better
- do not mix mac and windows in the setup
- enable personal settings (eg use usb keyboards)
- navigator also needs to say why we do things
- make advanced and beginner groups
We decide to do another round expanding our first MVP, immediately implementing two improvements:
- Group drivers per location to not alternate all the time (we expect this to create more flow)
- Explain functionality before we start coding.
Round two
Sticking to one location longer (multiple drivers in one location and then swith to multiple drivers in the other location) speeds up and creates more flow. My fear that people would detach proves to be ill-founded. When we switch driver location, we cross-switch the navigator too so the driver and navigator are always in opposite locations. This works out very well. It requires the new navigator to know exactly what we are driving for to be able to continue the narrative. Not unimportant: to prevent energy drain, we had some refreshments and snacks brought in. The people are now used to the format and feel relaxed, they crack a joke and discuss and explain things among each other when not driving.
We wrap up with navigating from Pune through the whole solution with a non-developer driver in Amsterdam. This creates a double teach-back: We see that the remote participant understands how we constructed this solution and we see that a business person knows how to navigate through the code and knows how to operate the IDE
Conclusion
Although people spend a small amount of time being actually on the keyboard (in our case 10 minutes in a three hour session), the learning is very noticeable: during the second round, people navigate smoothly through the IDE when hearing the navigator instructions. I noticed that debugging is less effective in this setup than entering code. I think this is because the navigator is in unknown territory too and leads the driver into several dead end streets before finding the cause of a bug. This is confusing for non-developer drivers.
In our case, business people with no programming experience at all could contribute. The nature of the PEGA programming environment is very suitable for non-programming people to learn. They can collaborate easily because this is a Business Modelling language; i.e. the work is more configuring-like than coding-like. There is no steep learning curve caused by the syntax of some programming language.
When a very experienced person gets in the driver seat, the navigator can suffice with more high level instructions. The driver can then support the navigator by describing the things he is doing. It’s like in a car: the driver can speak as well.
People who are not in the driver seat learn by hearing the instructions and seeing what is being entered. An interesting side effect is the learning other very experienced developers get from listening how an experienced developer in the role of navigator approaches a problem. There are multiple ways to solve a problem and by crawling into another developer’s brain, they are forced to learn new approaches.
Key findings
I strongly recommend to use the mobbing approach to help teams become more multi-skilled and to reduce differences in levels of experience. During the session we all know who is experienced and who is not, this creates a safe space for learning. The high degree of collaboration is fun and brings positive energy to the team
Existing descriptions of MOB programming strongly suggest co-location or all remote setups. We discovered that working with two co-located locations works very well too. To keep all attendees connected, we ensured that drivers and navigators are always cross-location.
You can find more recommendations in this MOB programming document via google: “Zuill.MobProgrammingExperienceReport.pdf”.
Leave a Reply