During my professional career I heard a lot of agile ways of working for developers. Think about the pair programming sessions or the Pomodoro way of working where you have work iteration of 25 minutes so you have a better focus during your workday. These things make totally sense if you are a developer, but if you are working in a scrum team where everyone is a T-shaped developer you can’t really use them unless you are working individual on something. If you have the approach where every team member is working individual, your pitfall can be that you are silently introducing the Waterfall model inside your nice eco system of your scrum team.
How? Well it’s easy: Imagine a sprint of two weeks, the first week you, as a developer wait until your BA, UX and designer come up with a solid solution for the new feature the team needs to work on. At that point you will build the approach, but there are some issues so you can’t fix them right away. At the end of the sprint just before the sprint review, you managed with the developers to implement a working solution. But your tester still needs to test it and of course he is the guy who can find that annoyingly bug which you can’t fix in this sprint. Sound familiar? Well you should discuss this in the retro to change.
The scrum framework is based on team members who can do all the work, yes I agree that you still need a tester and that a developer is not a tester and vica versa. But I believe in team members who are T-shaped. This means that they have a core knowledge which they can use during a phase in a sprint. Because a scrum team commits on a sprint, even when a specialist is sick or not available during the sprint, the other team members should be able to finish the sprint and burn those stories. So how can you easily transfer knowledge in a sprint of two weeks?
Meet the concept of Mob programming. When I first used this concept of working inside a scrum team, I had my doubts. It was really hard to explain developers work to a tester which hadn’t any code knowledge. But I learned fast, to get the benefits of this way of working, you need a team which is open to learn new stuff. You need developers who are willing to explain code stuff and testers who want to learn to code. So how does this mob programming work?
Well there are three things you should know about mob programming. First you have a navigator who is only allowed to tell and explain what the driver should do. The driver is the person who is only allowed to type or perform the necessary actions to accomplish the navigators intent. The rest of the group is the so called “mob”. They are only there to watch and to interfere when it is needed.
So when does the mob interfere the session? Well for example the navigator has an idea for an implementation and tells the driver how to achieve this. The driver is in this case a member with a test background and has little code knowledge so the navigator is explaining everything in detail so the driver can type the code in the editor. At this point somebody from the mob is asking a question why they are using method A instead of method B. The navigator explains his thoughts and the mob disagree with his statement and the discussion continues. In the end the navigator agrees with method B and instruct the driver to change the code. What you just witness is a live code review by several professionals.
So is the navigator always telling what to do? Nope, every 5 till 10 minutes (depends on the code knowledge inside a team, if you have 50/50 (dev/testers) I would say take 10 minutes for every session so you have plenty of time for explaining) you switch, the navigator becomes the driver, the driver goes back into the mob and someone from the mob becomes the navigator. Due to these switches everyone is involved in the development of the new feature and automatically knowledge is shared in between team members.
If you have for example a scrum team which has 2 iOS and 2 Android developers plus a tester, UX’er and business analyst you can already have a better understanding of the feature which you as a team should build. Also if you start in the mob session with Android, later on decide to work without a mob session, the iOS developers already know how the Android implementation is, so they can reuse this knowledge for the iOS counterpart. So in the end the implementation for iOS and Android are the same and if for example both iOS developers are sick during the sprint, the Android developers can understand their code easilier and maybe even continue to work on the iOS part as well.
As you can see, mob programming can be the way to go to improve communication in between members of your scrum team. I also discovered that mob programming is not always the best way to use during a sprint. If you use it on a daily base, your velocity will drop drastically. So what we did was to use mob programming only for situations where we thought it was needed. For example at the start of the sprint, where we wanted to set up a base for the new feature to implement, we made use of mob programming so we could align iOS and Android together. When this was finished we splitted up and did the work for iOS and Android isolated. Of course sometimes there were some questions and if we couldn’t agree upon an implementation we went back to a mob programming session to continue the work together.
Another benefit of this was that at some point our Android developers were out of office due to holidays and sickness. You would say that the Android part of the user story could not be finished, but we did finished it. Because the tester had some basic knowledge about the Android code he could pick up that part of the user story, but sometimes he got stuck and he asked to our iOS developers for a mob programming session to help him out. And that is the beauty of this way of working, helping each other out as a team.