Link Search Menu Expand Document
Devismos

Mob programming

Created: Feb 17, 2021 12:43 PM Created By: Pablo Pareja Tobes Last Edited By: Pablo Pareja Tobes Last Edited Time: Mar 23, 2021 9:02 AM

Related concepts

These are not specifically mob sessions:

Project first-steps session

These sessions can be used to define who does what in a project and, more generally, define the organization and logistics of a project.

Demo

Someone showcases something that has already been done, opening for discussion-related topics that may arise as well as contributions for possible improvements in future phases of the project/tool.

Mob session / programming

Definition

Decision-making session to either deal with a complex feature or, as part of the first stages of a project, be able to standardize the opinions of all / most members of the front-end team. There may be some programming included but it is not a requirement. These sessions should be aligned both with the company’s purpose and the front-end team strategy.

Duration

It should normally take around 1 or 1 and a half hours. However, the idea is to use that time as efficiently as possible by previously doing individual asynchronous work by the attendees of the session.

General objectives

  • Gather everyone’s input on the selected topic. Active participation from the whole team is a must. We want these sessions to be 100% inclusive and all attendees should feel they have the time and space to share their thoughts about the topic.
  • Contribute towards the standardization of the ways of working across the team. Reach a unified vision for the front-end solutions.
  • Work towards the elimination of knowledge silos across the team
  • Increase the team cohesion
  • Create a space for new ideas to pop up

Outcomes

Even though specific outcomes per session must be defined, at least the following outcomes should be produced:

  • A dedicated folder for each specific mob programming session will be created in the Notion “Community & Growth” site
  • This dedicated folder should at least include the following items:
    • Session notes
    • Decisions made (also documented on the project)
    • Actions summary (when applicable, e.g. gathering feedback about the session)

Optional outcomes

  • Blog-in post describing the session and its outcomes/conclusions.
  • Session recording (optional but highly encouraged)

Attendance

Attending a mob session won’t be required but it will be highly encouraged so that the general objectives are more easily met. /However, we should obviously take into account our capacity and projects’ duties before committing to participate in a mob session.

We should obviously take into account our capacity and projects’ duties before committing to the participation in a mob session.

Frequency

In principle we could aim for a monthly frequency, that way we would have the “Mob session of the month”, allowing enough time for the preparation + follow-up for each of the sessions.

This is not a requirement, just something we would be aspiring to.

Prerequisites

  • Agenda: A simple but clear agenda should be defined several days in advance including session sections with the corresponding expected timings.
  • Homework for attendees: A list of must-know resources (docs, links, etc) should be defined in advance and shared with the prospective attendees at least one week in advance. That way everybody should have had time to get familiarized with the topic
  • Questions form (optional) Form including the main questions that will be asked on the mob session. It should be created and shared at least one week in advance also. **These questions would be answered by the other developers and the answers will be accessible to anyone so they can prepare before the meeting.

Roles

  • Note-takers: This role should be assigned prior to the session. Several people should be assigned to this role so that all the effort doesn’t fall on just one person. Each of the note-takers should be assigned to specific sections or items from the session as part of the Agenda. That way we would avoid confusion about who should be taking notes and when. Overall the idea is that everybody should be involved in the note-taking effort. (As an addition to the notes, we could also explore the possibility to automate part of this through recordings and natural language recognition).
  • Topic Lead Person who is the driving force of the session and initiates the discussion. He/she has written the agenda. This is the person who either knows more about the subject or is designated to start the project and has a broader and more complete background of the topic.
  • Moderator Responsible to keep an eye on the time of the different sections of the agenda so they fit into the expected duration. Also will ensure the participation of every attendant as much as possible.

Structure

  • Short introduction: 5 mins tops.
  • Sections: Every question / part of the agenda that requires some decisions. This is divided on:
    • Split into groups (2-3) depending on the number of participants: We split the conversation into several groups to gather everyone’s insights
    • Sharing and further discussion: Some representative of each group shares the decisions and the section is discussed by the whole team
    • Conclusions: The final decisions/actions are documented
  • Q&A or addendum After all the topics are discussed there might be some time to add some more questions/doubts about the project and solve them.

Follow-up requirements

  • Session Notes review: everyone commits take a look at the notes to see if there was something missing or not accurately portrayed.