Nimble Thoughts by Dexter Baga

What is Mob Programming?

“Mob Programming” is simply a name we coined to describe/define what we do in our daily development tasks that allows us to be agile. We are a “Mob” since the entire team are always together, in the same room, walking together to meet a customer, making decisions together – essentially doing things together every time.

What it’s Not.

A large part of Mob Programming is about a mindset of making it easier to innovate and as a result we come up with good solutions. Mob Programming is not a set of processes that anybody can just adapt and expect the same “great” results. It would be hard to even come up with a specific set of advice to another team to duplicate the success of our team by our so called “Mob Programming” approach. Just like what most investment firms say, “Past performance does not guarantee future results”.

The right thing to do is not to sell you a solution.

All that we can do is share our experiences, and describe how we achieved the successes that our team had for the last 2 years.

What I really want to say is….

Yes, its helpful that everybody are good team players, everybody tries to contribute, that each member treats everybody with respect, members are open minded, willingness to share knowledge or learn, and good technical skills. For our team, the most important skill that got us to become “Mob Programmers” is being attentive and observant on how we are doing our work, reflect on them, and take actions to improve/remedy items that are blocking the team from becoming an effective team – keyword : “Retrospectives”.

It is through retrospectives that our team discovered what was wrong in how we were doing things, what was holding us back from becoming an effective team. The team was committed at getting better, we setup action items, and continued doing our work with those items in mind. What’s interesting is that those “problem” items will not show up in the next retrospective session, everybody had done their part to make those problems go away organically and that nobody even brought it up anymore. And if it does resurface, somebody in the team recognizes it and will immediately bring it up to “nip it in the bud”.

Everybody is in the same boat!

Your team can do “Mob Programming” too! But it would be a journey for the whole team. Take it one day at a time, don’t plan what you will be doing in the next 6 months to become true “Mob Programmers”. Perform retrospectives weekly, bi-weekly – its a team decision. Your retrospectives should show the most important things in the mind of each team member, vote which one to tackle, get the great, good, and could be better items, make action items for the team – but I would suggest just trying to tackle 1 or 2 at most to allow the team members a better handle on the action items given that you will probably have another retrospective in another week or two. Actually, do a just-in-time retrospective as well. If the team feels like they have something that needs to be discussed then don’t wait for the week to end, do it as soon as possible – nip it in the bud.

Recommended Reading : Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen