Mob Programming during the Explore Phase has demonstrated excellent results. In the following lines you’ll know more about Mob Programming and Geison Goes´s findings for utilizing it during the Explore Phase of a project.
About Mob Programming
Mob Programming is a technique that consists of putting all the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer.
Woody Zuill and Kevin Meadows’s Mob Programming e-Book details the whole process. But the main idea could be summarized in a few lines:
- Sit all member in a semicircle in front of a big screen
- Choose a “driver”: the one controlling the keyboard
- Change the driver from time to time, usually in a 15-minute interval
Before applying Mob Programming in the context of a project’s Explore Phase, Geison was unsure about this technique effectiveness. These were his two biggest concerns about Mob Programming:
- Should it work for large teams?
- Is it as efficient as pair programming?
After applying it for a while in his current project, he was able to answer these questions: It depends.
Even pair programming, a well-tested and consolidated software development practice, gives bad results when applied in the wrong situation, or by a team that is not prepared and really willing to apply it.
The perfect fit – Mob Programming for the Explore Phase
Mob Programming is an optimized practice for collective thinking, not for collective typing. So, with this in mind, Geison have been looking for a situation that suits it. Then, it happened to him! Currently, Geison is a developer on a project’s explore phase along with two other developers and two designers. He suggested Mob Programming, and it has been working nicely for his team.
According to the Lean Enterprise book, a project’s Explore Phase demands much more thinking than typing: it’s the phase to explore the uncertainties and to create the opportunities.
Thus, in order to explore uncertainties and create opportunities, his current team adopted the following two approaches:
These are the findings based on their experience with Mob Programming:
- Short stand up meetings.The stand up meetings are much shorter since all team members are working on the same thing.
- Anyone could go to any meeting. Since the whole team knew exactly what was going on with everything they did, any member of the team could represent the team in any meeting.
- Moving forward faster and making better informed decisions.Having members with different backgrounds and points of view working in the same problem gave them the ability to make faster and better-informed decisions.
- Work keeps moving, on a daily basis. Is someone home sick? Someone leaving early? Not a problem. The mob was always there, regularly moving the work.
- All learning are continuously shared across the team. Learning and sharing is imperative during the explore phase. There is no need to stop the work and schedule some sort of sharing sessions. Everyone was already learning and sharing together, all the time.
Unfortunately, life is not all rainbows and unicorns. The team had to agree upon some working core hours, in which everyone would be at the same place, during the same working hours. Also, the team had to agree upon some personal time for a few individual administrative activities that should be executed individually. These were the biggest arguments the team had for implementing Mob Programming.