Teletrabajo y Scrum: 10 consideraciones

La crisis sanitaria está obligando a que casi todas las empresas de software tengan que teletrabajar.

Si tu empresa no hace Scrum, pienso que es el momento de adoptarlo, sin demora. Ahora más que nunca necesitas que tu equipo de desarrollo sea capaz de, en jerga Scrum, inspeccionar y adaptarse a los cambios con celeridad y seguir entregando valor, a pesar de las dificultades. Siempre se dice que, en un mundo incierto, al menos Scrum trae certidumbre a cada Sprint o ciclo corto de desarrollo. A su vez, Scrum procurará transparencia para combatir el presumible caos que el trabajar todos desde casa puede acarrear.

Si ya hacías Scrum, seguramente tu equipo trabajaba desde la misma oficina hasta hace apenas unos días, y ahora estáis en pleno proceso de cambio, dadas las circunstancias. Este es el momento de reforzar el proceso, y tenéis la ventaja de poder hacerlo con la experiencia de haber trabajado anteriormente como equipo co-localizado.

A continuación, repaso algunos apartados a tener en cuenta por equipos Scrum a distancia (asumiendo que sus miembros trabajan dentro de un mismo huso horario).


 Emular lo presencial al máximo

Lo primero que hay que considerar es que el teletrabajo, si bien tiene múltiples ventajas, además de ser la única opción posible en estos momentos en España, no es necesariamente la modalidad que más beneficie el trabajo en equipo ni la creatividad. En mi experiencia, todo lo demás constante, un equipo cuyos miembros se sientan el uno al lado del otro bate casi siempre a uno que opere en remoto. No lo digo yo, lo dice gente como Marty Cagan, aunque los estudios al respecto no están tan claros.

En mi opinión, para que un equipo Scrum funcione telemáticamente, tan bien o mejor que un equipo que comparte ubicación, habremos de hacer un esfuerzo adicional por tratar de emular las condiciones de trabajo que tendríamos si todos estuviéramos en el mismo sitio, soslayando una serie de riesgos asociados al teletrabajo. Entre estos, subrayo los siguientes:

– Problemas de comunicación y mal entendidos ante la pérdida de buena parte de la comunicación no verbal y la disminución de los contactos informales entre miembros del equipo.

– Posible reducción de la colaboración y confianza mutua; opacidad.

– Posible pérdida de motivación y de sentimiento de equipo.

Es importante decir las verdades del barquero para que seamos conscientes y no nos creamos que el teletrabajo es ahora la panacea de todo. Hacer Scrum con equipos no presenciales es perfectamente viable y se puede hacer con éxito, aunque presenta una serie de dificultades que no debemos ignorar.


Los individuos e interacciones son más importantes que los procesos y herramientas

Lo primero que nos dice el Agile Manifesto es “Individuals and interactions over processes and tools”. No nos peleemos por qué herramientas utilizamos según para qué cosa, hay muchas y muy buenas. Tengamos claro el objetivo: cuantas más conversaciones útiles tengamos, mejor. Volviendo a uno de los principios del Agile Manifesto, “The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation”.

El diagrama de los diferentes modos de comunicación de Alistair Cockburn es bastante ilustrativo en este sentido.

Modes of communication. Copyright 2002 Alistair Cockburn.

A falta de la posibilidad de hablar cara a cara, animo a tener tantas videoconferencias como sean necesarias. Uno a uno, en grupos o en equipo, según nos haga falta. Videoconferencia hasta la saciedad. Más vale sobre comunicar que quedarse corto; a riesgo de que no nos entendamos, mejor repetirse.

Crear una cultura en la que las videoconferencias se suceden con espontaneidad, sin necesidad de que pasen por el calendar, puede llevar tiempo, pero considero que sería el escenario ideal.

(Por cierto, no soy partidario de hacer cosas como dejar la cámara activada todo el tiempo durante la jornada de trabajo, demasiado freak.)


Experimentar con las herramientas

Que las interacciones sean más importantes no quiere decir que las herramientas dejen de serlo. Al contrario, en el caso de equipos en remoto las herramientas cobran singular relevancia y pueden facilitarnos el trabajo y favorecer o frenar la colaboración. También habrá que prestar atención a qué cosas documentar y cómo hacerlas visibles para todos. Como decía antes, las herramientas para gestionar la pila de producto, el flujo de trabajo, documentación, etc., son muchas. Lo recomendable es probarlas, y utilizar por ejemplo la restrospective para valorarlas y establecer planes de mejora.

En especial en momentos de cambio, el Scrum Master puede asumir el liderazgo y procurar que esta exploración de herramientas por parte del equipo tiene lugar.


Las ceremonias hay que seguirlas

Si por trabajar en remoto empezamos a hacer el daily meeting un día sí y uno no, o a tomarnos a la ligera la planning meeting, la sprint review o la retrospective… Mal asunto. Trabajando en remoto, las interacciones hay que prepararlas con mayor seriedad si cabe. Lo que importa no es tanto la frecuencia de las interacciones como su calidad: hay que trabajar bien las reuniones.

La deslocalización del equipo supone un reto a valorar de manera continua en la retrospective.


Visión, visión y visión

Todos necesitamos tener clara la ‘bigger picture’, el porqué hacemos lo que hacemos, en particular si lo hacemos estando “solos”, desde casa. Es el momento del Product Owner, de comunicar y explicar la visión de producto, una y otra vez, en cada oportunidad que se presente, como hilo conductor que de unidad y motivación al equipo.


Responsabilidad individual

Cada cual tiene la obligación de establecer sus propias rutinas y un ambiente de trabajo adecuados. Hay quien insiste en la importancia de “vestirse como si fueras a ir a la oficina”, de establecer tiempos de descanso, de tener el equipamiento informático necesario, etc.

Esta responsabilidad individual asimismo debe traducirse en un mayor compromiso para con el equipo. Si el Scrum Master tiene que estar “persiguiendo” por Slack a los miembros del equipo de desarrollo para que actualicen el progreso en la herramienta que corresponda o para que se unan a reuniones telemáticas, mal vamos.


Reglas de equipo

Acordar una “definición de terminado”, establecer reglas sencillas respecto a horarios (a qué hora hacemos la daily meeting, cuándo se para para comer, uso de Slack, etc.) o definir claramente para qué se usa cada herramienta puede ahorrarnos estrés y pérdidas de tiempo innecesarias.


Buenas prácticas

Pair programming, code reviews, continuos integration & deployment, unit tests, automated regression testing, etc., son prácticas extraordinariamente recomendables, más si cabe cuando teletrabajamos, a fin de fomentar un ownership colectivo del código y minimizar bugs.  


Invertir en formación

También son recomendables sesiones de “show and tell en las que compartir conocimientos internamente, así como formaciones externas que permitan reforzar las habilidades del equipo y situarnos a todos a un mismo nivel en determinadas materias.


Buscar más contacto con el cliente

Si trabajamos 100% en remoto, y aprovechando que muchas de las conversaciones que por ejemplo el Product Owner pueda tener con usuarios o clientes finales serán también telemáticas, esta puede ser una oportunidad para incluir en esas conversaciones a más y más miembros del equipo de desarrollo, fomentando así el contacto directo con el cliente.


Picture: some of my former colleagues at Hiyacar on a video call.

_____________________________________________________________________________

¿Buscas formación en Scrum?

Desde Scrumio arrancamos con los online webinars que impartiremos en las siguientes fechas:

Cuando estés listo, podemos ayudarte de 3 formas:

  1. 1. Apúntate a una de nuestras formaciones: cursos intensivos para Scrum Masters y Product Owners, en directo e impartidos por nuestros especialistas.
  2. 2. Simulador Scrum: si estás preparando una certificación como Scrum Master (PSM I) o Product Owner (PSPO I), nuestro simulador de preguntas tipo test es una de las mejores herramientas para prepararte.
  3. 3. Únete a nuestra Newsletter, Piratas Ágiles: recibe contendidos exclusivos sobre Agile y Product Management.
Comparte este post

Publicado por Sergio Rodríguez

Especialista en producto y Professional Scrum Trainer acreditado por Scrum.org. He sido Product Manager, Head of Product y consultor de producto en empresas como Liftshare, Cardmarket o Wave.

Subscríbete a nuestro Newsletter

Únete a cientos de lectores de Piratas Ágiles para recibir historias, consejos y recursos sobre Scrum, Agile y Product Management.