Llewellyn Falco has visited our Mob Programming team many times. I asked Llewellyn if he could write a guest article for us about his experience with Mob Programming, and here it is. Thanks Llewellyn!
I have had a different experience.
I sat with a team that was happy, joyful even. They were hopeful, energetic and engaged. There was a high level of trust and respect for everyone in the team. People felt safe to voice ideas and suggestions, and when weakness were shown, they were acknowledged without ridicule. The team even set aside time each day to help other members of the team become stronger in the areas they needed improvement in.
Meetings are great. I’m pretty sure that we would all prefer to have meetings all day if we could. But life isn’t perfect.
Ooops. Did I say Meetings are great? I meant to say meetings are mostly USELESS. Note I said mostly – not all, just mostly. To clarify (so people won’t complain too much): In my experience meetings are typically not an effective way to get things done. Seems like they should be, but they AIN’T. Mostly.
Andy Warhol – Exposing Himself (Using a Polaroid. Remember those?)
Perhaps the title of this post is a bit misleading. It should probaby be titled, “Mob Progamming: You will be exposed”. That’s exactly what happens to members on a Mob Programming team. The interesting part is that it isn’t all that bad and if you are working on a real team it is beneficial.
If you are part of a team that is practicing Mob Programming, every aspect of your interaction with the team will be exposed and on display. Everything from personal hygiene to technical expertise. When you get stuck on a problem and use Google to search, the team will see exactly how you think when coming up with search terms. There is no where to hide, but is there really any reason to hide?
Individuals are pretty much the smallest chunk of humanity available for doing software development, and probably for a lot of other things too. Individuals are a key part of software development. Regardless of what we disagree about, we can hopefully agree that at some point an individual has to do something, or we end up with no development – no new software.
You ever watch The IT Crowd? There is a nice little skit in an early episode where the boss [Denholm] fires a whole floor of workers who can’t work as a team, and then he prepares to fire the security team if they can’t work as a team.
Here is a quote from Denholm just after the firings:
“Team! Team, team, team, team, team. I even love saying the word ‘team’. You probably think this is a picture of my family? No! It’s a picture of The A-Team. Bodie, Doyle, Tiger, the Jewellery Man.”
As a mob we put a lot of effort into increasing our productivity and capabilities. In other companies I have worked, the improvement of capability seemed to be a second class citizen to “getting work done”. When looking at the number of repetitive tasks a typical dev team does you may find that the potential for improvement has been completely ignored in favor of the continuous manufacturing of software. Templating, Code generation, easy configuration, and automation of typical maintenance tasks are key factors in eliminating waste in software development.
Several people have asked about how we chose the name “Mob Programming” for our practice.
Here is my memory of it:
It seems we naturally give names to anything nameable
Once we started working using this practice, we found ourselves wanting to call it something. We started calling it different things: Crowd programming, Pair ++, Team Programming, Teaming, Mobbing, and Mob Programming are the ones I remember. I imagine there were others.
A week ago I did a Coding Dojo demonstration with Llewellyn Falco at a conference, and showed the Mob Programming video. One of the audience members sent me an email to ask a few questions about what we’ve been doing, and I responded with my answers. It seems that others might be wondering about the same things, so here they are:
Question: Thinking in a group setting doesn’t seem productive or even possible. I assume that when you are stuck on a design some people may go to their cubicles to ponder it. Is this correct?
Answer: We pretty much work and think all day, every day, in a group setting. However, every team member is free work alone, take a walk… whatever it takes.
Most of our work is done sitting together in the group work area. We try to make it as comfortable as possible. There is plenty of room and we can easily have others join us whenever needed.
Our work area is configured out of some standard cubicle walls, and is about 16ft x 18ft. It works pretty nicely, although earlier we worked in a separate room for a while and found that to be even better.
Mob Programming may seem to be counter intuitive at first, however it quickly becomes evident that the ability to transfer knowledge to your whole team at the same time quickly outweighs the perceived loss in efficiency that you would normally otherwise think would result in a period of time all of your developers are sitting at one keyboard.
Imagine programming as a large puzzle that someone must assemble, some pieces are lost under the bed and some are at your neighbors house from the last time you got together to assemble a puzzle. The puzzle pieces represent the individual bits of information you would need to actually write the code. The finished puzzle being the written and complete code. Now picture having your friends with you to help you with the puzzle. Each person found all the pieces before hand or at least know where to look for a specific piece. The act of assembling the puzzle is much like the typing of the code, it does not take a lot of time and once it is complete everyone can agree that it looks good and move on. Completing the puzzle is much faster and this is why:
If 5 people work on 5 separate puzzles at the same time and each have to spend time looking for the pieces they will collectively spend that much time performing the act of looking instead of assembling. Conversely if 5 people work on 5 puzzles together they will find the correct pieces and assemble them with little to no time spent looking.
Mob Programming is an obvious path to take using this example. The technical minded often get stuck on minor things because they have to find out how to accomplish a goal. With 5 programmers looking at how to solve a problem, the answers to that problem come into focus without any wasted time. 5 programmers working together can complete work faster than 5 working apart or even in pairs.
Thanks for Reading!
In our experiences in the mob we work in, this has been extremely evident especially in regard to domain knowledge, technical knowledge and platforms used for development and business practices. The pieces are all over and each person has a piece.