Debido a la crisis del coronavirus, muchos equipos van a teletrabajar estas semanas. Esto nos obliga a reinventarnos y, por suerte, Scrum es adaptable a este tipo de situaciones. Recordemos que Scrum, como marco de trabajo que es, permite jugar de muchas maneras, siendo cada equipo el que decide cómo jugar para “ganar”. Tendremos que modificar nuestra estrategia para poder hacer Scrum a distancia.
Las técnicas, prácticas, métodos y demás nacidos del desarrollo Agile tienen como principio fundamental la comunicación “cara a cara”. En estos días de confinamiento, no va a ser posible y debemos sacar adelante productos que nuestros usuarios necesitan.
Suelo ser bastante crítico con respecto a la separación de equipos mediante la subcontratación por motivos de abaratamiento de costes. Las mejores empresas unen a los equipos, ya que genera mayor colaboración entre ellos. No obstante, toca remangarse y autoorganizarse para sacar adelante el trabajo. ¿Cómo lo hacemos?
Cómo podrían actuar los roles de Scrum a distancia
Cada rol tiene que asumir la situación. El Scrum Master debe entender que muchas de sus funciones, de estar pendiente para lo que ocurra, se complican. Por ejemplo, Lyssa Adkins recomendaba que un Scrum Master se siente en el centro del equipo para escuchar y sentir lo que ocurre. Sin embargo, ahora no es posible, por tanto un buen consejo es conseguir que el resto del equipo gane más protagonismo. En concreto, hacer que el Development Team fije sus reglas de trabajo y acompañarlos para que las cumplan.
El Development Team debe fijar sus reglas de trabajo. ¿Cada cuánto nos reunimos? ¿La daily es suficiente? ¿Podemos interrumpirnos a cualquier hora o fijamos ventanas de tiempo para ello? Todo esto son reglas de equipo y hay que fijarlas, para después inspeccionarlas y adaptarlas a medida que aprendamos a trabajar así. Por tanto, el primer consejo es tener Sprints de una semana, en las que podamos hacer cambios que se vayan requiriendo. Desde luego, si tenemos Sprints más largos (por eventos como Sprint Review con usuarios), tratemos de aumentar el número de momentos en los que inspeccionamos y adaptamos.
Pensad que vamos a necesitar usar tecnologías que nos permitan compartir pantalla, trabajar por pares o hacer pequeñas formaciones en el equipo. Recomiendo al Scrum Master sacar estos temas a la luz para que el Development Team tome las decisiones oportunas. Herramientas como Zoom permite al Dev.Team compartir pantalla y usar el ordenador de un compañero, con lo que son ideales para trabajo en remoto.
El Scrum Master no debe olvidar que las interacciones ahora son más importantes que nunca. Al ser online, puede que ocurran sin que se entere, sobre todo, si el equipo no ve valor en su figura. Así que, la mejor estrategia es, ¿en qué puedo ayudaros? No se debe poner la gorra de controlador para justificar su rol, debe ser sé natural y, si en esta época, tiene que dejarles más tiempos solos, adelante.
En cuanto al Product Owner, su labor quizás no se ve tan alterada pero sigue teniendo que modificar ciertas pautas. Por un lado, su relación con los usuarios si va a ser telemática, hay que fijar reuniones y calendarlas lo antes posible. Es buena idea fijar todos los eventos de Scrum para que los usuarios puedan conectarse y tratar con ellos.
Según el contexto en el que trabajemos, un Product Owner puede tener diferentes necesidades: más estimaciones, resolver dependencias técnicas, hacer pequeñas presentaciones del producto… Es vital que transparentemos todas estas necesidades al resto del equipo y que podamos ayudarnos mutuamente. Una vez más, la responsabilidad del Scrum Master es ayudar al Product Owner a sacar a la luz todo esto y facilitar que se tomen decisiones de equipo que les permita ser efectivos.
Cómo usar los artefactos en un Scrum a distancia
Quizás los artefactos sean los elementos de Scrum más fácilmente adaptables. Ya hay muchas soluciones digitales que te permiten tener el Product Backlog, el Sprint Backlog y el Incremento digitalizados. Cómo sabéis, soy amante de los tableros físicos y de la gestión visual del trabajo, sin embargo, ahora es más complicado.
En equipos que teletrabajan, sí que he visto poner un tablero físico al que se conectaba la persona que estaba fuera. En una situación en la que cada uno está en una ubicación, quizás esto pierda fuerza y sí que sea conveniente alguna solución digital. No soy especialmente amante de Jira, en mi caso prefiero Trello (solución sencilla y rápida) o Kanbanize que me parece más completa.
Aún así, es importante que recordemos que las herramientas digitales pueden ayudar o entorpecer en función de cómo las usemos. En el caso del Product Backlog, con tener una lista ordenada por prioridad es suficiente, de hecho, un excel nos valdría. La clave de todo es el Sprint Backlog. Recordad que no debemos tener un listado de cosas “por hacer/todo”. La gracia del Sprint Backlog es que represente un plan de trabajo. Debe ser una plan de organización que el propio Development Team construye en la Sprint Planning, y que mantiene a lo largo del Sprint. En situaciones donde es más difícil vernos, ser muy disciplinados con su actualización es mucho más importante.
Cómo hacer los diferentes eventos
Los eventos tienen muchas opciones de personalización: recordemos una vez más que podemos “jugar” a Scrum de muchas maneras. El primer consejo es hacer Sprints de una semana para tener más capacidad de inspeccionar y adaptar en una situación nueva y, en gran manera, improvisada.
De esta manera, reducimos los tiempos de la Sprint Planning, Sprint Review y Sprint Retrospective, ya que dependen del tamaño del Sprint.
Consejos para la Sprint Planning
Los últimos equipos que he acompañado estaban lejos por decisión de la empresa. Para hacer la Planning, hacíamos los siguientes pasos. Primero el Product Owner compartía su pantalla e iba repasando cada uno de los elementos del Product Backlog susceptibles de abordarse durante el Sprint. Era importante dar espacio para dudas, si el Scrum Master detectaba que no se conseguía interacción, era el momento para actuar: ¿De qué te has enterado? ¿Podrías explicar esta historia? A continuación, podíamos s fijarnos el Sprint Goal y,cuando lo analizásemos en detalle, podríamos ajustarlo si hubiéramos sido ambiciosos.
El siguiente paso era hacer la división en tareas (en Jira son subtareas) de cada uno de los elementos del backlog. Las tareas podrían ser atómicas y por capas, el objetivo era conseguir un análisis técnico de lo que suponía cada uno de esos PBIs. A veces, eran tareas triviales: front, back, bbdd… Aún así, nos servían para diferenciar las que solo afectaban a una capa de las que trataban muchas. La idea era generar una conversación técnica sobre el trabajo que tenemos que hacer antes de estimarlo.
El hecho de que haya debate genera sensación de equipo con madurez trabajando juntos. Para planificarnos y hacer estimación utilizábamos la siguiente técnica. Una vez teníamos los elementos del Product Backlog, los ordenábamos por tamaño, de manera que los íbamos comparando de dos en dos. Esto nos permitía acelerar la estimación, y nos permitía hacernos una idea del trabajo que teníamos que sacar adelante. En nuestro caso, era obligatorio estimar por decisión de la empresa, por tanto todos los equipos debían hacerlo.
Una vez estaba ordenado, asignábamos al elemento central el tamaño de “tres puntos de historia” y, a partir de ahí, comparábamos unos con otros.
De esta manera, obteníamos una estimación relativa más fiable que lanzando cartas a diestro y siniestro. Además, utilizábamos la técnica de puntos de forma relativa, que es el principal beneficio de usarla.
El siguiente paso era la asignación de tareas. Esta parte del evento era relevante y muy pocos equipos que haya acompañado la han realizado. ¿Cómo nos íbamos a organizar? La mayoría de herramientas digitales no permiten grandes cosas, aún así, era importante que no acabara la Planning sin saber con qué nos íbamos a poner. Podíamos fijar pequeños hitos durante la semana para saber si progresábamos hacia el Sprint Goal a buen ritmo.
Y por último, teníamos una conversación final con el Product Owner sobre todo lo que habíamos descubierto analizando-estimando-asignando tareas. De esta conversación final, podrían salir ajustes sobre el Sprint Goal y sobre los elementos que podríamos abordar (previsión que no compromiso).
Consejos para la Daily Scrum
La Daily Scrum es, quizás, uno de los eventos que gana más relevancia en una situación de Scrum a distancia. Recordemos que su objetivo es la inspección y adaptación de nuestro plan de trabajo (Sprint Backlog) de cara a cumplir con el objetivo (Sprint Goal) que nos hayamos marcado en este Sprint. Esto es importante, porque podemos caer en la tentación de usar el evento para “demostrar que trabajamos”
Recordemos que la Daily Scrum es un evento destinado a la coordinación del equipo, ya que es autoorganizado y no dispone de “cabeza de mando”. Siendo a distancia, creo que es importante que el Scrum Master y el Product Owner estén, aunque no participen activamente. Es un evento para el Dev. Team y hay que respetar su espacio, sin embargo, da visibilidad al resto del Scrum Team.
Recordad que un buen uso de la Daily Scrum es para organizar el día. Por ejemplo, si tenemos dudas de una funcionalidad, podemos usar la Daily para organizar una reunión posterior con las personas que hagan falta. Además, puede ser una buena idea tener más de una Daily Scrum al día, para coordinarnos mejor, esto es una posibilidad que el Dev Team debe aprobar, pero el Scrum Master podría proponerlo. Si tenemos varias, es más fácil entender que las Daily Scrum nunca son de reporte; estar reportando todo el día es poco útil y genera sensación de desconfianza, lo que nos lleva a generar desmotivación.
Para finalizar, es interesante que en la Daily Scrum vayamos con el oído por encima de la lengua, es más interesante escuchar que hablar en este evento.
Consejos para la Sprint Review
La Sprint Review es uno de esos grandes desconocidos del que ya hemos hablado muchas veces. Su función principal es la inspección del impacto de nuestro producto en el mercado (incremento) para adaptar próximas mejores sobre el producto (Product Backlog). El Scrum Team, liderado por el Product Owner, muestra a los diferentes stakeholders el estado del producto para tener conversaciones en torno al futuro del mismo.
Dado que tenemos que invitar a varias personas, es importante convocar el evento con antelación, y entender que las personas se pueden retrasar o no ser puntuales. Por tanto, es relevante dejar espacio suficiente para todo lo que tenemos que hacer dentro. Una vez más, el Scrum Master debe estar atento para generar conversación sobre el producto, si está funcionando y si aporta valor a nuestros usuarios (y por tanto a la organización).
De cara a preparar la Sprint Review, recomendamos hacer la “pre-review”. Esta práctica es sencilla, cuando en la Daily Scrum el equipo ha finalizado un PBI, un miembro de lo enseña al Product Owner para que tenga constancia y validar que funciona como se espera. De esta manera, tenemos mejor informado al Product Owner sobre el estado del producto.
Consejos para la Sprint Retrospective
Un evento que, bajo mi opinión, más va a sufrir estando a distancia es la Sprint Retrospective. Hay varias aplicaciones online que sirven para hacer retrospectiva aunque las he usado poco. Mi consejo, dado que una situación así requiere de mucha madurez del equipo, es que tratemos los diferentes temas de manera abierta con coraje, respeto y apertura. Esto es, creemos una Backlog de impedimentos y asuntos que queramos mejorar y repasemos uno a uno. La idea es terminar con un plan de acción que nos permita superar los impedimentos y ser más productivos.
Una vez más, si apostamos por Sprints cortos de una semana, la principal pregunta que debemos responder en la Retrospectiva es: “¿Qué podemos hacer mejor la semana que viene?”. Cuando los Sprints son cortos, es vital tener muy pocas acciones en marcha, para que rápidamente podamos ver su impacto. Y en caso de tener Sprints largos, recomiendo hacer más de una retrospectiva durante el Sprint, eso sí, consensuado con el resto del Scrum Team.
Consejos para Refinar y Gestión de Producto
Para poder refinar, os proponemos varias ideas. Una es hacer “bajo demanda”, es decir, cada vez que una tarea esté trabajada, quedar con el equipo o parte de él para estudiarla. Hay equipos que pre-asignan un propietario a cada historia para que se asegure durante el Sprint que está correctamente refinado para la Sprint Planning. La alternativa es quedar con el equipo en un evento prefijado. Una vez más, hay que hacerlo con antelación para garantizar que todos nos conectemos.
En cuanto a la Gestión de Producto, es interesante que el Product Owner tenga reuniones telemáticas con los usuarios para analizar su producto y el impacto en mercado. Ahora es buen momento para estudiar si en nuestro producto tenemos métricas que nos den pistas sobre cómo estamos. Para productos que aún no están en producción, es interesante que nos hagamos la pregunta: ¿Cómo garantizamos que este producto está funcionando bien? Y con la respuesta definimos métricas.
La principal clave es la cultura, de empresa y de equipo
Construir una cultura de libertad&responsabilidad donde los equipos puedan tomar sus propias decisiones lleva mucho tiempo. En situaciones como estas es donde vemos qué empresas son más resistentes. La primera clave para que un equipo funcione a distancia es su capacidad para ser un equipo maduro. Nuestra compañera Esther nos analizó las fases de Tuckman, que nos dicen en qué punto estamos.
Los equipos más maduros tendrán ventaja competitiva, por tanto, si eres el Scrum Master de un equipo, toca remangarte para que las cosas funcionen. Los individualismos-dañinos son más fáciles ahora en esta época en la que estamos todos separados.
Al igual que ocurre con las empresas que trabajan en modo producto no tienen problemas con la entrega en fecha porque asumen que una fecha es solo un hito, una oportunidad. Sin embargo, las empresas que trabajan en modelo de proyecto, cuando llegue la “fecha de entrega”, seguramente acaben echando horas. En el caso de Scrum a distancia, empresas que hayan trabajado la confianza en los equipos, ahora verán que pueden seguir confiando en ellos.
En el libro Lidertarios de GoodRebels, contaban que una vez tuvieron que teletrabajar todos porque iban a hacer una mudanza de sus oficinas. Ese día se lo tomaron en equipo, crearon un hashtag y se pusieron a trabajar a saco. Para ellos fuera una experiencia positiva, y fue semilla para crear esa cultura de la confianza que les caracteriza.
Y tú, ¿cómo vas a hacer Scrum a distancia estos días?
Nuestro agradecimiento a Jorge Celeiro, quien nos ha dado la idea de escribir este post.
