Mob Programming and Personal Satisfaction
Solo Coding vs Mob Programming
On a team that has started Mob Programming and succeeding with it, "Several developers are feeling a lack of personal satisfaction, and miss solo-coding." Have you experienced this and what do you do about this issue?
When we started mobbing for the first time I found myself in a similar place. I could not put my finger on it but there was something missing that was there when I was programming by myself. I did a lot of soul searching during the early days of mobbing and I feel like I came up with two primary difficulties I was having with staying super happy with my situation. The first was the sense of a triumph over adversity I felt when solving code related problems by myself. The second was a feeling of boredom that arose when writing code that felt "easy".
As we became experienced at Mob Programming, the general consensus was that everyone believed we as a team produced more valuable software to production on a regular interval. This meant that regardless of how I felt, I should find out what was bothering me and how to overcome it. Mob Programming will never be Solo Coding. Therefore, is the joy I felt while programming by myself the fact that I was alone or is there something that no longer occurs in the mob setting to make me feel that feeling again?
Joy in a Mob
Personal satisfaction can be experienced in many ways. During my introspection while mobbing, I had a few ideas of what was going on. over time most of these problems went away. As a solo developer, I had those moments of conquering a problem and cheering because I did it. I also had times where it was satisfying to support another developer with something I was expressly responsible for. The more complex the system was that I contributed to, the better about myself I felt.
Fiero
The first time I learned the term Fiero was in the book "Reality is Broken" by Jane McGonigal.
This is the definition in the book: "Fiero is what we feel after we triumph over adversity. You know it when you feel it – and when you see it. That’s because we almost all express fiero in exactly the same way: we throw our arms over our head and yell."
This is a feeling I would get often while programming alone. When I was in a mob for the first time however it seemed to happen less frequently. After thinking about it in depth there was a period of time where the team had to reach a technical skill level baseline. During that time we were all figuring out what we each knew and how we could contribute. I believe software developers experience fiero when we get stuck on a problem for a long time and then overcome that problem. When a new mob forms it feels like this happens less and I expect the reason is there is a sort of technical Satir change model happening. When a mob forms the most technically experienced people will likely be spending a majority of their time mentoring, and the least experienced people will spend a lot of time learning. Once we reach the teams new technical norm, in my experience this feeling of fiero comes back. Only now you have people to high five and yell with!Complexity of the problem related to personal satisfaction
Sometimes when mobbing, it is a shock to see how quickly problems seem to fade away in the code. Having more than 2 people looking at the problem leads to conversation, drawing architecture, and leading by example. These are all things that are less likely to happen when developing software by yourself. The problems you were solving sometimes quickly become trivial and less interesting. One time I was feeling frustrated while mobbing. I thought to myself what is bothering me about this? After careful consideration I settled on the idea that the problems we were solving were too simple in nature. In fact a large portion of what we were doing could be automated with enough thought put into it. I brought it up with the team and we developed new abstractions, code generators, and snippets to automate away a large portion of the work. After this all was done, I realized I was enjoying myself much more. The complexity of the problem we were solving increased, and the amount of trivial code being written was minimized. This result was exciting and increased our overall development speed.
Solving systematic problems vs. code problems related to personal satisfaction
There was one thing that drove a lot of personal satisfaction for me during the early days of mobbing and even now. As a software engineer, I feel better about what I do when I am optimizing systems. For me, before mobbing that meant creating clean, well structured code that accomplished a lot in the domain it was in. I was able to keep that form of personal satisfaction by shifting my focus from the code to team over-all systems involved. Having good ideas voted for in retrospectives as action items, and pointing out systematic issues that we ended up solving made the whole team work better and faster. This created a virtuous loop for myself and the team, as we contributed to optimizing the process, we felt better about the work we were doing. My personal satisfaction with the work being done increased as we reduced the pain we experienced from many of the issues plaguing other software development teams.
In team sports, often having an all-star player is worse then having a good well rounded team. I suspect that the mob works this way as well. Spending time thinking about how you can optimize your team and then working to contribute as a team player can increase the personal satisfaction you receive when working in a mob. A common question I get is how can 4 people be working on the same thing and still be engaged? I like to point to Willem Larsen's Mob Programming Role Playing Game to answer. When Willem started making the game we realized it was a great way to create a taxonomy for the "roles" in a mob as a sort of anthropology activity. Specifically the "Automationist" role is the role that I fell into when ever I felt like the code could be more interesting.
Boredom
Repetition
Minimizing the routine and maximizing useful conversation
New with Mob Programming
Since Mob Programming is so different from Solo Coding, what are the new ways to tap into personal satisfaction you can feel when in a mob that are not possible programming by yourself? When writing software with multiple people, it becomes a much more creative and social process. Ideas are thrown out and discussed, then the mob reaches a consensus on direction and movement happens. In this environment a lot of unintentional mentoring happens. Very much like the Satir Change Model, the system as a whole begins at its lowest point and increases in productivity as the mob matures. This means there are many opportunities to experience "Vicarious Pride". Solo developers are often very separate from their team from technical practices to process and even culturally. The other new thing that teams develop is a unified culture and high level of investment in continuous improvement processes.
Personal Satisfaction and Vicarious Pride
Pulling once more from the "Reality is Broken" book, the section on Vicarious Pride describes the positive emotion one feels when seeing someone they have mentored succeed. I have experienced this emotion in the context of mobbing many times. I have seen others experience this as well. The combination of dedicated learning session time and Mob Programming creates the opportunity for vicarious pride to be experienced continuously. Event a less experienced developer can learn something new in their learning session that no one else on the team knows. They then have the opportunity to mentor others on the team in exploiting this technology. I has seen this lead to junior level developers mentoring senior developers. In many cases they are proud they were able to mentor up and have been prideful of the accomplishments of their team when the technologies were taught to everyone.
Unified Culture & Belonging
Life as a software developer outside of a mob environment can feel very lonely. It can also seem like others do not understand you or you are working on separate projects even though you are not. Mob Programming allows a team to create a higher level of interpersonal interaction which can then lead to a deeper sense of community. Retrospectives and continuous improvement processes lead the team to conquer the Satir Change Model quickly and reach new levels of performance. Experimentation becomes a natural part of the day. Treating everyone with Kindness, Consideration, and Respect allows the team to create high levels of psychological safety. The team then creates and accepting community that helps promote the personal satisfaction gained from belonging to a group.
Tips
- Lacking Joy? Find the Fiero Moments.
- Bored? Automate, Abstract, Generate. Reduce repetition.
- Seeking Personal Accomplishment? Optimize the team not the code.
- Need fulfillment? Create Vicarious Pride in yourself and others.
- Need Acceptance? Retrospect and develop your culture and sense of belonging.
Thanks Jon for being my sounding board!
Thanks to Lori, Mrinalani, Shawn, Lauren, and Aaron for helping with photos!
Nice to hear your experience of and encouragement for mobbing.
ReplyDeleteHey James, I appreciate it! I want people to see that they can actually get rid of that chronic pain most software teams experience.
DeleteHello Chris!
ReplyDeleteI'm Atsushi Nagata from Cybozu.
We started mob programming 4 years ago, and now most of our development is mob programming.
In one of our products, we have seven teams doing mob programming.
Right now, we are facing a similar problem in our mob team.
Some people lost confidence and left the team, saying they wanted to do it solo, because they felt they were not contributing to the team or that they did not feel a sense of accomplishment. When we brought this up in the retrospective, we found that there were other people who felt the same issue.
When one team decided that the backlog was not worth doing as a mob programmings, some of the team members tried to do it solo.
We all understand and feel the good things about mob programming, but we are struggling with the same things.
So, I'd like to introduce this prog.
Thank you for the comment Atsushi! It also helps to automate the simple work if the work seems too "easy". I hope you can find the right balance. We wont make everyone happy, but we can make the environment better through retrospectives and a focus on improving the team and not the individual.
Delete