El Mob Programming o programación en grupo es una forma de desarrollo en el que un grupo de profesionales trabajan en un mismo problema, al mismo tiempo y en un mismo entorno de trabajo.
Es un modo de trabajo en el que se aprovechan las cualidades colaborativas para crear un entorno de trabajo de crecimiento y aprendizaje.
Roles
En esta modalidad de trabajo se distinguen, como en el Pair Programming, dos roles:
El rol de Driver es llevado por una sola persona al mismo tiempo y es aquel que sigue las indicaciones de los Navigators, que son aquellos que proponen ideas, buscan información y guían al Driver.
La diferenciación entre los dos roles es un modo de reducir la carga cognitiva de pensar una solución e implementarla al mismo tiempo, que es lo que hacemos cuando trabajamos solos. De este modo tenemos más espacio para pensar, aprender y llegar a una mejor resultado.
Lo ideal es que estos roles vayan variando frecuentemente para reducir el desgaste y cambiar el punto de vista lo que siempre enriquece las sesiones.
Otro punto importante es la planificación de estas rotaciones así como los descansos. Una vez se acuerden entre los miembros del grupo es necesario respetarlos. Por ello, es necesario tener sistemas para compartir el código de forma rápida o por otra parte disponer de algún sistema de control remoto.
Feedback
La gran ventaja de esta metodología es su ciclo de feedback instantáneo en el que tenemos retroalimentación inmediata sobre la solución que estamos implementando. Así como una mejor calidad en el código.
Por otra parte hay que estar atento a los problemas que nos podemos encontrar. Uno de los más peligrosos es el pensamiento de grupo que evita la generación de nuevas ideas.
A continuación lanzaré algunas ideas interesantes que aprendí de Agile New England en su webinar del 25 de junio de 2020.
En ocasiones con encontramos con inconvenientes como que la sesión es ocupada totalmente por una persona que es capaz de lanzar muchas ideas y eso no es negativo per se. El problema es que el mindset del Mob es la participación de todos los integrantes así enriqueciendo la sesión. Por tanto, a veces es necesario que alguien tome un rol de moderador o facilitador. Esta persona, normalmente con más experiencia, puede dar a las sesiones más dinamismo de modo que todas las personas tengan voz.
Otro punto importante es el cambio frecuente de roles. De esta manera, todos los participantes se ven obligados a un cambio de marco mental. Y en caso de que un driver tenga una idea que se quiera poner a prueba, este driver cederá su puesto y pasará a navigator y guiará su implementación.
Que la persona que tiene las ideas sea la misma persona que hace de driver es una perdida de cualidades de Mob y Pair Programming. Por lo general es el driver el que se tiene que esforzar por seguir y entender a los navigators, lo que hará que se genere un aprendizaje por parte del driver.
Por lo general, el que más aprendizaje acumula es el driver, ya que en el momento su nivel de concentración y compromiso con el problema es mayor. Por eso es necesario rotar el puesto.
Una buena práctica al final de cada sesión de Mob es realizar una pequeña retrospectiva del aprendizaje de la sesión y realizar sugerencias para mejorar próximas sesiones.
Hay momentos en los que la sesión no puede estar siendo todo lo productiva que se desearía y para ese momento es deseable que alguien adopte el rol de “navigator de navigators” que sugerirá caminos e ideas a los navigators para desatascar la sesión.
También hay veces en los que dos miembros del equipo sugieren dos soluciones a un mismo problema. En este caso lo mejor es aplicar la solución del más junior primero. Esto permite iterar entre ideas más rápidamente y aprender de los errores.
Una gran ventaja de este tipo de prácticas es el sentimiento de comunidad y tribu que se genera colaborando para alcanzar un objetivo común. Se genera un sentimiento de comunidad muy fuerte entre sus integrante que es proporcional al compromiso de los mismos.
Si todos saben como solucionar el problema no tiene sentido trabajar en grupo. Cuanto más difícil es un problema, más necesario es hacer Mob.
Trabajar en Mob debería ser una opción. Si el equipo o una persona no quiere trabajar en Mob no tiene sentido obligarla. De otra manera no se aprovecharían todas las ventajas de la práctica.
Conclusión
Descubrir el Mob Programming a sido para mí una grata e inesperada sorpresa. En mi formación siempre había trabajado solo y tengo que confesar que aún me cuesta trabajar en equipo, pero pongo mi mejor esfuerzo en mejorar. Siempre me he sentido más cómodo trabajando solo, pero era por no ser consciente realmente de las grandes ventajas del trabajo en equipo y el círculo virtuoso que es capaz de generarse. Por lo tanto, mi intención es seguir trabajando en Mob Programming y aprovechar sus grandes virtudes.
Recomiendo visitar la web https://www.remotemobprogramming.org/ para más obtener más información.