Mob programming .. really ? Where does that name come from?

Thinking of an angry mob couldn’t be more counterintuitive of what you would want from a successful programming session. Mobs are disorganised, prone to rash decisions, angry and unwilling to compromise. Mob programming however is none of these things.

What defines Mob Programming ?

Strictly speaking, mob programming is when 3 (or more) developers use only one keyboard.

The driver is the person with the keyboard and mouse, the driver is the only person allowed to modify the code.

Everyone else takes the role of the ‘Navigator’. The Navigator has all the time they need to think, review, discuss, describe and do quick lookups.

People take turns taking the driver role.

The setting

This is a summary of learnings in a real case study of a team starting with Mob programming. Keep in mind, this is just a way to do it. Not -the- way to do it. It will depend on your team and organisation.

A new team is created with a mission to create an MVP in one month. Since the team is new, there will be a lot of time invested in sharing knowledge, setting standards, agreeing on where to go.. The only thing known at that moment is a UX design. The team and the PO rapidly discover a shared understanding .. there will be no programming of anything that does not bring value. This understanding will be crucial in the first weeks. Even though the design looks really great, the team rapidly decides to create something that can show how it might look and not spend time in trying to create the exact same design.

First day of mob programming

We try not to focus on the strictness of 1 keyboard for the team.

The teams does however agree on working on one single item only.

As the whole development environment needs to be set up, each person takes up driver role and explains his environment (front-end / back-end) while the whole team syncs their environment.

A kanban board is created, no sprint planning is done as we don’t know what stories to build yet. Since everyone will work on the same thing, typical kanban lanes like ‘in review’ , ‘in test’ are not needed. The work item being worked on will move from.. To do -> In Progress -> Done. In general, the less lanes in a kanban board means more collaboration.

As there is no production environment yet the starting definition of done means : code has test coverage, the team tested the functionality on working software.

Quickly the first rules are set..

Team members can call others when they are not actively participating in the same thing.

A parking lot is created for small work that can be done outside mob programming while not all the team is together. Some people arrive sooner and can start working on parking lot items until the whole team is ready to start mob programming.  

After 4 hours a first retro is held:

Focus is increased, there’s no time to wander off to do something not related to the task at hand.  

Safety, the team feels very quickly as a real team, people with limited knowledge that are in the driver seat are being guided to what they should write and how.

The team realises the advantages of being able to see what everyone does and is specialised in.

By working together on features, good questions are raised as to why we are building it, how we are building it.

The parking lot is appreciated and will stay

The team feels they won’t be able to keep this intensity every day.

There need to be more breaks. Focus is tiring. And without breaks the attention evaporates. The team decides to option to take the possibility to break more often when they switch driver.

After two days, the team feels really empowered. Working like this has very quickly created a great team spirit. The biggest drawback : Its energy draining, working like this ends up being exhausted at the end of the working day.

It’s not mob programming !

The team realises that what they do is not strictly mob programming and we decide to not focus on the strictness but on what mob programming is about: Single piece workflow. The whole team works on one item only.

We introduce supporting roles that work in parallel on the same story : QA works in parallel on the same work item to define tests and write automated tests while the main driver is writing the functionality, helped by the navigators. When the story is ready to be tested the full team switches to testing and creating automated tests until all tests are green and the item is marked as done.

It’s not Scrum! .. Are we still agile ?

The team doesn’t do daily standups and doesn’t do sprint planning. There still is a two week cadence, a ‘sprint’ review and retrospective. Most disturbingly :  There is no sprint commitment.

On the other hand, there is a goal: Creating as soon as possible an MVP that can be shown to the users. After two weeks that goal is reached. A demo is given of the first product.

Adaptive Architecture

The end users never realised that the first demo didn’t have a back-end that stored the results. As the concept of what has to be built was far from clear, the team took the decision to focus on showing functionality rather than creating a full blown architecture.

At this moment the product loses all its data when restarted, but its goal is to have end users and concept leads see and think about the product.

Finding a place

The team finds free meeting rooms with a big screen and start a travelling presence in meeting rooms.  They are seldom seen on the large floor where other teams are.

Some important insights after 2 weeks

No loose ends : Stories are built from start to finish. There are no loose ends like code reviews that have not been done, not code that is not tested and no story deployed without test by the whole team.

Chaos:  the experience still feels chaotic.

Whole team focus loss: if focus is lost, the whole team loses focus.

The feeling over all is that very little waste has been created in achieving the current product state.

Getting to speed

The velocity is calculated on how many stories and story points are created every two weeks

The velocity chart is quite stable.

On the Cumulative flow diagram, the In progress state of 1 item is barely visible.

What becomes visible during Mob Sessions is how much time is gained by working together on the same thing. For most individuals, Software development isn’t about spending time at the keyboard. The main activity is searching, thinking, and translating ideas into code.. Which goes a lot faster with multiple people helping in the search.. Where you can observe a much more steady flow in productivity for the driver.

Reaching Maturity

In the first weeks, Quality assurance and testing was considered a supportive role and was happening in parallel while development was being done. The tester didn’t feel at ease taking the driver seat when programming was done.

However, after a month, the tester started taking the role as driver as well. The whole team supporting him to take up programming and helping him code. This was a major shift into full Mob programming.

Taking up The Driver/ Navigator style

The Driver sits at the keyboard and types. The Navigators discuss and guide the Driver in writing. This means the Driver is not actively looking at how to code. He listens to the Navigators while focusing on the typing/coding. The Navigators are expressing their ideas in a way so the Driver only has to focus on the next thing to type at any given time.

Is Mob programming and Scrum compatible ?

Scrum is an empirical process that relies on three main ideas of transparency, inspection, and adaptation. Mobbing is an extension of it. Transparency is greatly increased as everyone sees what the others are doing. Inspection remains the same, there are still backlog refinement sessions and a sprint goal can be set. The daily standup is not needed as the whole teams moves from one work item to the next having a continuum of short, very short transparency – inspect – adapt cycles. Upon picking the next item, the team can reflect on how this will help reaching the sprint goal. Adaptation remains the same as the team continues to do sprint reviews and retrospectives.

Who shouldn’t do mob programming ?

With Mob Programming everyone is in almost constant communication with everyone else.  This is not something most software programmers are used to, and not everyone can adapt to this.

• If people are not open minded to learn other skills..  because the whole team becomes cross functional
• If people need private space and silence to be able to work
• If people are not confident in their skills, because their code becomes transparent
• If people like to use a job to improve their own skills because the team decides to keep things simple
• If people hold a grudge for a long time.. The closeness of the work needs the ability to say what’s on your mind and move on
• If people like gold-plating or building architectural masterpieces for the sake of it
• If your team members have very different work schedule, it limits the time to be able together