La mayoría de los desarrolladores trabajan en solitario. Las tareas suelen asignarse a individuos en una práctica llamada "codificación en solitario". Los desarrolladores que practican la codificación en solitario a menudo están aislados en silos que evitan compartir conocimientos en el equipo. Estos silos también dificultan que los miembros del equipo se relacionen y creen vínculos personales, especialmente en un entorno de trabajo remoto. La integración de nuevos miembros al equipo se complica y el establecimiento de puertas de calidad como las revisiones de código resulta en un cuello de botella para la eficiencia en la entrega. Además, asignar el trabajo a miembros individuales también crea un riesgo cada vez que esa persona abandona el equipo (por ejemplo, vacaciones o baja por enfermedad). Finalmente, con el tiempo, los individuos se convierten en dueños de regiones del sistema y en la persona a la que acudir para conocimientos específicos de funciones.
La programación en pares es una alternativa viable a la codificación en solitario.
En Programación en Pares se exploran sus beneficios y desafíos. Cuando se desarrolla en pares, las personas pueden trabajar estrechamente juntas con el objetivo de compartir constantemente conocimientos e información. Esto conduce a una mejor refinación de historias porque todos tendrán el contexto necesario para contribuir. Además, no es necesario tener procesos específicos de revisión de código ya que todo el código se revisa sobre la marcha. El emparejamiento crea más oportunidades para que las personas se conozcan y desarrollen vínculos personales, aumentando así la cohesión del equipo. Los procesos de emparejamiento deben ir acompañados de una ceremonia de rotación de pares periódica para que el cambio de parejas pueda ocurrir. Esto permite que las personas experimenten trabajar con todos en el equipo. Después de esta ceremonia, los desarrolladores deben compartir el contexto y el progreso de las tareas actuales con la nueva pareja para que el flujo de entrega pueda continuar.
La frecuencia de las rotaciones de pares puede variar entre equipos. Aunque se prefieren rotaciones frecuentes de pares para maximizar los beneficios del emparejamiento, algunos equipos han informado que rotar pares con frecuencia crea fricciones. Existe la percepción de que rotar pares todos los días, o cada dos días, es más costoso y más difícil que rotar una vez a la semana. Por otro lado, también hay equipos que rotan pares una vez al mes. Esto significa que un individuo tardaría al menos 5 meses en emparejarse con otras 5 personas del equipo al menos una vez, suponiendo que no haya parejas repetidas durante este período. Otra rutina es cuando las parejas rotan solo cuando terminan una tarea, lo que hace que la frecuencia sea indeterminada. También no es práctico rotar pares al completar una tarea, ya que es poco probable que otras parejas terminen al mismo tiempo.
Empezamos a notar que los equipos con rotaciones de pares poco frecuentes tienden a presentar síntomas similares a los equipos que realizan codificación en solitario. Las parejas de larga duración empiezan a convertirse en "cómplices". Compartir contexto se vuelve más difícil cuanto más tiempo pasa sin que se produzca el cambio de parejas: los desarrolladores necesitan compartir todo el contexto del mes anterior con una nueva pareja en el contexto de las rotaciones mensuales. Teníamos evidencia de que nuestra práctica de cambio de parejas no estaba produciendo los resultados deseados, por lo que decidimos realizar un experimento con el objetivo de mejorar el rendimiento del equipo a través de las mejores prácticas de emparejamiento.
Nuestro Experimento
Decidimos desafiar a los equipos que practicaban rotaciones de pares poco frecuentes a aumentar radicalmente esta frecuencia como parte de un experimento. ¿Qué pasaría si durante dos semanas rotamos pares todos los días? ¿Cuáles fueron las dificultades encontradas durante este tiempo, y qué podemos hacer para abordarlas? ¿Obtuvimos los beneficios del emparejamiento durante este tiempo? De ahora en adelante, ¿el equipo desea seguir rotando pares todos los días o volver a la frecuencia anterior?
Desarrollamos un ejercicio diseñado para ayudar a un equipo a explorar la rotación frecuente de pares y hacer un análisis crítico de su impacto. El ejercicio comienza con una sesión de pizarra facilitada de una hora, durante la cual los miembros del equipo escriben y discuten sus ideas sobre las siguientes tres preguntas:
- ¿Por qué es valioso el emparejamiento?
- ¿Qué hace que el emparejamiento sea difícil?
- ¿Qué hace que el emparejamiento sea fácil?
Estas preguntas se presentan en orden. El equipo tiene tres minutos para publicar respuestas para cada pregunta en la pizarra y siete minutos para discutir lo que han compartido.
Figura 2:
Tablero mural que muestra la retroalimentación del equipo durante el experimento de rotación de pares
En los días siguientes del ejercicio, el equipo continúa trabajando en su lista de tareas mientras rota pares todos los días. Para cualquier tarea en progreso, un miembro de la pareja se queda con la tarea como "ancla" mientras que el otro rota a otra tarea. Los "anclas" de una tarea rotan cada dos días, asegurando que ningún miembro del equipo trabajará en una tarea individual durante más de dos días consecutivos.
El equipo se reúne todas las mañanas durante 30 minutos en una sesión de pizarra con las siguientes tres preguntas:
- ¿Qué hace que el emparejamiento sea difícil?
- ¿Qué hace que el emparejamiento sea fácil?
- ¿Qué prácticas deberíamos intentar hoy para que nuestro emparejamiento sea más fácil y efectivo?
Estas preguntas se presentan en orden, con tres minutos para publicar ideas en la pizarra y cinco minutos para discutir. Una vez finalizado esto, el equipo identifica los "anclas" para cada tarea en progreso y facilita la asignación de nuevas parejas.
Facilitamos esta retrospectiva diaria utilizando el mismo tablero todos los días, con un color de post-it único para cada día. Esto permitió a los miembros del equipo ver los puntos planteados en cada área en cada día, lo que resultó en una visualización del aprendizaje y el pensamiento crítico del equipo a lo largo de la semana.
En el último día del ejercicio, facilitamos la sesión final en la pizarra, y luego pedimos al equipo que decidiera una frecuencia de rotación de pares para continuar. Luego animamos al equipo a seguir revisando la frecuencia de rotación de pares en futuras retrospectivas de equipo.
Resultados de Nuestro Experimento
Durante 2022 – 2023 involucramos a tres equipos separados para probar este experimento durante una semana cada uno. Cada uno de estos equipos estaba totalmente distribuido, trabajando juntos en línea pero nunca en persona. Dos de estos equipos estaban ubicados entre Estados Unidos y Brasil.
Cada equipo planteó preocupaciones similares al inicio del experimento. En la primera sección a continuación compartimos algunas de esas preocupaciones y describimos cómo evolucionó la posición de los equipos durante el transcurso del experimento. La segunda sección presenta algunos comentarios que muestran los beneficios reales del emparejamiento y las rotaciones frecuentes de pares.
Todos los equipos que participaron en nuestro experimento utilizaron sistemas como
Jira or
Trello are used for documenting and tracking work items, with both platforms referring to a record as a "card." The feedback and outcomes presented below utilize the term "card" in this context.
Challenges in Pairing and Changing Perceptions
“Lack of empathy, alignment, and communication makes pairing difficult”
Regular pair rotations can significantly enhance team dynamics. Initially, a lack of empathy and alignment can pose challenges to pairing, particularly when team members are unfamiliar with each other’s work patterns, pace, and expertise. By frequently switching pairs, team members get to understand each other better and more rapidly. This mutual understanding makes it easier to empathize and align, fostering stronger team bonds. Additionally, the practice of frequent pair rotation promotes a culture of feedback. It is recommended that team members actively provide feedback during brief sessions at the end of their pairing activities, contributing to ongoing improvement and enhanced collaboration.
“There are numerous interruptions to pairing time”
Teams encountered difficulties in pairing due to frequent interruptions stemming from a lack of extended uninterrupted work periods. To tackle this issue, the teams set core working hours in the afternoon to minimize interruptions. Consequently, meetings were rescheduled to the morning or end of the day. Moreover, team members employed techniques like the Pomodoro Technique or other timeboxing methods to maximize efficiency and productivity during their limited work hours.
“Switching pairs every day slows us down”
There’s a perception that increasing pair rotation frequency leads to reduced delivery performance, as believed by the product team. They argue that more rotation results in decreased efficiency and slower output.
Developers also hold the view that frequent rotations introduce additional complexity, consequently impeding team progress. This is due to the continuous need to share evolving work contexts, seen as a time-consuming process.
However, advocates for more frequent rotations suggest that context sharing becomes more efficient with increased frequency. This efficiency stems from the reduced amount of context to convey with frequent pair switches. Additionally, with every team member gaining a comprehensive understanding of ongoing tasks, sharing context becomes more effective. Furthermore, frequent pair rotations create opportunities for establishing processes that aid in context sharing.
With time, the practice of regular rotations becomes more manageable and streamlined. As teams become accustomed to this approach, initial challenges associated with frequent rotation diminish, making the process progressively smoother and more efficient.
Benefits of Regular Pair Rotation
“Context sharing is simplified and hastened through regular practice”
One common concern voiced by all three teams was the fear that changing pair members during ongoing work could lead to difficulties in sharing context with the new pair member. Indeed, this was the main reason for teams preferring long-standing pairs.
In each team’s board, this concern typically arose early on. Team members devised practical ways to facilitate context sharing, and by the end of the experiment, this fear had dissipated. A common practice that emerged was for pairs to conclude their day by adding a note to the card itself, summarizing the day’s work and decisions. They would also adjust tasks on a shared to-do list within the card. These simple practices helped embed the context of ongoing work within the card itself, rather than relying on individual team members for context.
Each team developed new practices regarding cards. During daily meetings, team members requested more context within the cards, smaller cards, and ongoing comments on the cards.
“Information flows seamlessly within the team”
An insightful observation made by the teams was that it took minimal time for a team member to brief a new pair on the context at the beginning of a coding session. There was often no substantial new context to convey. Additionally, teams found it easier to comprehend any card after working on various other cards from the backlog. Regular pair rotations expedite this learning process as team members engage in a wide array of tasks each week.
“It’s impossible to uphold knowledge silos”
Each team comprised members with diverse experience levels and areas of expertise. Initially, teams viewed this diversity as a hindrance to frequent pair rotations. Before the experiment, teams planned pairs and assigned cards based on factors like seniority, specialization (front-end, back-end, devops), prior experience in specific codebase areas, etc. Managing this intricate matrix made frequent pair switches arduous and reinforced knowledge silos within the team.
With the daily pair rotations during the experiment, maintaining these rules proved unfeasible. Daily rotation required team members to operate in unfamiliar codebase areas. However, the reduced time spent on a specific card before passing it to someone else lowered the risk for team members tackling unfamiliar tasks.
Teams discovered that frequent pair rotations mitigated the impact of individual experience levels on cards. Longer-tenured team members could unblock newer members and share knowledge, expediting their learning curve concerning the codebase and tools used for development.
Feedback received a few months post-experiment from one team highlighted an interesting observation: Problems in production no longer necessitated depending on a single individual for resolution. Any team member could be assigned to troubleshoot an issue. Additionally, another feedback noted that a new pair rotation brought fresh context, altering the implementation direction and aiding in resolving early-stage feature development issues, ultimately saving time and reducing rework. These instances underscore the advantages of disseminating knowledge across the team.
“Work distribution among team members”
Team members realized that everyone gained insights into all the cards in progress, allowing for a smoother transition and handover process between team members.
In advance of commencing work on each card, a practice that enhanced the efficiency of the daily standup meetings was observed: Team members collaborated by sharing insights, anticipating risks, and assisting one another in overcoming obstacles. This collaborative environment thrived when all developers possessed comprehensive context and shared responsibility for all cards in play, with no individual claiming ownership over any particular task.
Despite engaging in daily pair rotations throughout the experiment, the three teams involved ultimately opted to vary the frequency. One team adopted three-day rotations, while the remaining two settled on two-day rotations. The decision to extend the rotation period to three days stemmed from the realization that frequent rotations unveiled bottlenecks and frictions within the teams' development processes. This adjustment was made to circumvent these impediments effectively.
It was noted that team members usually had limited hours, often dispersed throughout the day, for pairing activities. The participants expressed the need for more than a single day to ensure a meaningful pairing experience, hinting at a high degree of time fragmentation during development. Consequently, the teams chose to decrease the rotation frequency from the original daily practice during the experiment.
Several challenges encountered during the experiment were perceived as solvable problems rather than insurmountable obstacles. The daily sessions provided a platform for the participants to reflect on the difficulties encountered during pair rotations and collaboratively devise solutions. The dedication of time and effort to the experiment’s procedures yielded substantial returns on investment.
Overall, the experiment significantly increased the frequency of pair rotations within the teams. Notably, one team transitioned from monthly rotations to a three-day cycle, attributing the shift to the recognized benefits of short-term pairings such as enhanced knowledge sharing and team cohesion. Engaging in the experiment enabled team members to acquire insights into best practices for pairing, with pairing retrospectives and feedback sessions promoting a culture of constructive feedback within the teams.