Mob programming, a software development practice to reduce release time

Mob programming, a software development practice to reduce release time

In this article we will describe what Mob programming is, what its rules are – from technical set up to roles – and what the goals and benefits of this practice are. We will find out how mob programming fosters effective work between team members, a shorter release time of a prioritised feature in the backlog and a reduction of waste.

Manuel Togni, developer at Intrè, shared with us his team’s experience of mob programming following a workshop on the subject held by Woody Zuill, one of the pioneers of the practice.

 

Mob Programming

Mob Programming, also called ensemble programming, is the software development practice that allows teams to work together on the same task at the same time, place and with a single computer.

It is considered to be an evolution of pair programming, so from working sessions in pairs to working sessions in groups.

The practical objective of mob programming sessions is to conclude the task described in the story provided by the product owner by reducing the release time.

 

How does it work? Technical set-up, roles and stories

Technical set-up

Successful mob programming is dependent on the technical set-up and the surrounding environment.

An ensemble programming session requires:

  • A quiet environment without distractions
  • A computer
  • A keyboard
  • A projector or large screen
  • Optional: a flipchart or blackboard

Roles

The session is also characterised by the presence of two main figures:

  • A driver, the one who writes the code and has his hands on the keyboard. The driver receives instructions from the navigators and focuses on translating them into code. The driver is considered an intelligent input device: it has the task of translating natural language into code.
  • The navigators, the other members of the team, are those who give instructions to the driver. The navigators carry the cognitive load of writing the code and can (and must) confront each other to find the best possible solution for implementing the functionality required by the task.

About every 15 minutes, there is a change of roles to encourage the involvement of the whole team and share the cognitive load between people.

The team, besides the developers, is composed of figures such as: the PO, who provides the story and its stakeholders; the designers; the experts of specific functionalities. The whole team can participate in the mob programming session as needed. Having a heterogeneous group with different skills tends to reduce the number of errors, especially those related to technical choices, thanks to the comparisons that take place simultaneously with the writing of the code.

Stories

As mentioned in the previous paragraph, the team works on a story.

The Product Owner has the task of writing and providing the team with stories that enable group work. By answering the questions “who asks”, “what asks”, “why asks” and “what are the acceptance criteria”, the scope of work is outlined. During the writing of the code, the team members make decisions based on the demands of the story and its acceptance criteria that guide the development.

 

What about remotely?

Mob programming can be done remotely, but it requires more rules. As we have all experienced, remotely you can easily lose focus and engagement on what you are doing.

smart working
To continue to be an active presence that brings value, work in small teams and require members to keep the camera on and possibly reduce the time for changing roles between driver and navigator. The sharing of the screen by the driver is constant. Through experiments, each team finds its own best practises for remote sessions with supporting technologies, and in particular it is necessary to have a shared repository for the codebase so that changes are always available to all parties involved in the mob programming session.

 

The objective of mob programming and the concept of waste

The aim of mob programming is to reduce waste, to minimise the time that elapses between the start of a sprint story and its conclusion.

waste

What do we mean by waste?

By waste, we mean all those activities or actions that do not bring value to the final customer in the typical forms of cost, time, labour and materials.

Some factors that slow down or destroy productivity and increase waste are:

  • Communication problems due to numerous exchanges of information and different messages at different times. The presence of all (or almost all) the team guides the developers thanks to clear and precise communication in real time.
  • Decision making issues for choosing the best solution. Different opinions may emerge in a session due to the variety of points of view of the team members. To avoid protracted discussion, it is best to move on to assessing the pros and cons, then proceed with the implementation that seems most valid and the observation of what emerges.
  • Trashing, so interruptions that cause drops in attention. Trashing costs not only time but also energy.
  • Politics, so pressures from the business side on the team. The presence of a business figure at times of alignment between the parties is ideal for reducing the time needed to close a work cycle on a task.
  • And many other reasons…

Returning to the analysis of the objectives of mob programming, we said that the main one is to reduce the time needed to complete a task.

How, then, does ensemble programming make this possible?

The story on which the effort is focused is closed and released in less time thanks to teamwork at the same time, in the same place and on the same computer and thanks to the involvement of colleagues with different skills and business-related figures.

Thanks to the collaboration of several parties in the execution, certain situations that could lead to slowdowns or errors are immediately addressed.

Mob programming is a tool that helps to focus all efforts towards a single goal: maximising the business value released as soon as possible.

misimising time

 

Does mob programming always make sense? Is it necessary to involve the whole team?
Criticism of mob programming

The classic criticism of mob programming is that it is possible to carry out several activities on one’s own, instead of just one. Why, then, involve the whole team in a single activity? Isn’t it a waste of resources?

We assume that the team works on the task identified after the prioritisation phase of the backlog stories and that the common need is to close the most urgent story. Mob programming helps to reduce processing times: the task is closed early, unifying tasks in a session where all parties are involved. If ensemble programming is used when the story is not a priority, the error lies upstream in the backlog analysis.

Furthermore, it is true that mob programming is more suitable for some situations than others. In complex tasks, mob programming is advantageous in that a single team member would spend much more time solving them, whereas simple tasks can be tackled individually. Thus, it is not always necessary to use mob programming. It is important to understand when it is appropriate to adopt it, bearing in mind the training value of this practice.

 

The Intré experience

Intrè experimented with mob programming and Manuel Togni, during his meetup on the topic, shared some suggestions on the most critical aspects that emerged from their experience. Here is the link to their article.

In mob programming sessions, social dynamics emerge and are amplified. This implies more attention to how the session evolves and how it is managed. Manuel stressed the importance of retrospectives, even short ones, to monitor the work done and to think about how the interaction between the people in the team was.

In the interactions between navigators, there can be a lack of discipline that leads to confusion, especially for the driver who is busy translating their conversations into code. In order to learn how to give the floor to everyone and to reflect on their interventions, the Intré team experimented with the Coding Dojo exercise with benefits.

As illustrated in the previous paragraphs, communication must be clear, especially between the driver and the navigator. They must find a balance and the right level of communication to allow the driver to have clear information to proceed with writing the code.

The herd effect must be avoided. If everyone has the same background and perspective, there is a risk of not seeing the various possibilities and technical solutions. It is preferable, therefore, to create mixed teams, thus encouraging greater sharing of knowledge.

 

The advantages

Mob programming has several advantages.

  • Knowledge sharing thanks to the involvement of people with different experiences, backgrounds and sensitivities.
  • Immediate feedback: if you don’t agree with a choice you immediately talk about it and not at the end of the work, avoiding the risk of having to review all the work done up to that moment.
  • Greater involvement of participants “because it’s fun!”.
  • Sharing the cognitive load.
  • Collective code ownership: everyone knows what has been done and the team is autonomous even in the absence of one person.
  • Self-management and empowerment of the team, allowing professional growth of people.
  • Reduction of bugs and errors;
  • Encouraging the inclusion of new people and non-technical people.
  • When it’s done, it’s done”, as there is no need for code reviews and emerge requests;
  • Promoting the well-being of people, who can take a break by changing roles or leaving the session, without stopping the work of the team.

 

Conclusions

Mob programming is a tool, not the solution. It is not a practice that you can always adopt, but when possible and if you learn to use it, it can lead to many benefits.
Mob programming allows you to close priority stories in less time, have a full view and as few interruptions as possible from the whole team on the work being done.
Why not experiment with it?

 

Resources

Read more posts from the same category: Practices and tools for teams

Or explore other categories: Agile projects and products Practices and tools for teams Strategy and organisation