Es normal que cuando una organización deciden adoptar agilidad, siga la estela y elija por Scrum por ser el método más popular y utilizado del mundo. Sin embargo, durante este proceso es habitual que muchas caigan en los mismos mitos y falacias.
En este artículo vamos a ver algunos de estos errores en Scrum y comentar los motivos que suelen existir para adoptarlas cuando estamos utilizando Scrum.
En Scrum debe de haber un Scrum Master por equipo
Scrum recomienda que en cada Scrum Team exista un Scrum Master y un Product Owner, sin embargo no dice que tenga que ser una persona dedicada totalmente al equipo.
Sí advierte de que si no están dedicadas al equipo, eso puede suponer un impacto en la productividad.
De hecho, en la última actualización de la guía de Scrum, los autores cambiaron los roles a responsabilidades. El motivo es precisamente reforzar el hecho de que lo importante es que se asuma la responsabilidad y no tanto que exista una persona con el título adecuado.
Mi opinión es que tener un Scrum Master por equipo es algo fundamental, sobre todo cuando se trata de nuevos Scrum Masters que requieren de tiempo antes de empezar a tener una visión holística del proceso. Hay diferencia de opiniones en este aspecto.
Debe haber un Product Backlog antes de empezar el Sprint
Aunque la existencia de un Product Backlog refinado antes de comenzar con un primer Sprint, este puede perfectamente realizarse como parte del Sprint Planning e ir refinándose posteriormente conforme comenzamos a desarrollar nuestro producto y vamos aprendiendo sobre el mismo.
Es cierto que lo primero que debemos hacer al comenzar a usar Scrum es tener un Product Owner y elaborar un Product Backlog en torno a un Product Goal que refleje nuestras intenciones en el producto. Este proceso facilita el comienzo del proceso Scrum.
Lo que la guía de Scrum dice es que independientemente de como se haya iniciado el Sprint, al final de este debe haber un Incremento usable y de valor, es decir, producto para entregar al cliente, por pequeño que éste sea.
Los Sprints deben durar dos semanas
Esto es falso. Es uno de los errores en Scrum más extendidos. Los Sprints deben durar lo necesario para poder entregar un Incremento completo y nunca más de un mes.
También hay que tener en cuenta cual es el riesgo que el Product Owner está dispuesto a aceptar, en términos de tiempo hasta poder inspeccionar el Incremento terminado. Hay que pensar en los Sprints como los latidos del corazón de Scrum. Una duración de 1 mes nos da 12 oportunidades de inspección y adaptación al año, mientras que una de dos semanas nos da 24.
Si un Sprint dura más de un mes, se pierden oportunidades para inspeccionar y adaptar. Si con Sprints de dos semanas no se consigue tener un Incremento listo, entonces hay que revisar la duración del Sprint durante la Retrospectiva.
Debe existir una Definición de “Hecho” (Definition of Done)
La Definition of Done, que ha sido una práctica recomendada durante muchos años, alcanzó el estatus de elemento imprescindible de Scrum con la publicación de la guía de Scrum 2020.
La definición de hecho recoge todas aquellas actividades recurrentes que deben de tenerse en cuenta antes de terminar un Incremento. Entre estas pueden estar las pruebas de producto, la aprobación por parte de Stakeholders o la elaboración de la documentación.
El objetivo es mejorar la transparencia, uno de los pilares fundamentales de Scrum.
Así evitamos que cuando consideramos que algo está terminado realmente exista trabajo oculto que todavía tenemos que realizar para ponerlo en manos de un usuario.
El Daily Scrum es una reunión de sincronización
Este es otro de los fallos en Scrum. El objetivo del Daily Scrum es tener una oportunidad diaria para inspeccionar y adaptar nuestro plan de trabajo.
Tras el Daily Scrum, tenemos un Sprint Backlog actualizado con un plan para las próximas 24 horas y que nos proporciona pistas sobre lo que va a ocurrir en los próximos días.
Muchos equipos acuden al Daily Scrum y se limitan a decir lo que han hecho y lo que harán, o para comunicar impedimentos. Muy pocos realmente tienen un Sprint Backlog actualizado después del Daily Scrum.
De hecho, la fórmula de las tres preguntas en el Daily Scrum se eliminó en la actualización de la guía de 2020 para reforzar el hecho de que este evento se centra más en inspeccionar nuestro progreso hacia el Sprint Goal y adaptar nuestro plan para conseguirlo que en reportar qué hemos hecho o vamos a hacer.
Los ítems del Product Backlog deben estar estimados
Scrum dice que los ítems del Product Backlog deben estar lo suficientemente refinados y ser suficientemente pequeños para ser consumibles en un Sprint y, además, estar estimados.
Scrum no dice si esta estimación debe ser hecha en Story Points, mediante tallas de camiseta, flow metrics u otras técnicas. Estimar es una técnica necesaria porque mejora la transparencia y la inspección.
Esto significa que algunos ítems del Product Backlog, los que están más arriba y por tanto serán seleccionados pronto estarán más refinados y mejor estimados y otros, los que estén más abajo, no lo estarán.
Es decisión del Scrum Team determinar cuando un Product Backlog Item está listo. En general podemos decir que si es entendible, granular y es fácilmente seleccionable en el Sprint Planning, está listo.
Un Product Owner por equipo
Otro fallo en Scrum. Lo que es necesario es un Product Owner por producto.
Uno. No más.
Es posible tener representantes del Product Owner o Proxy Product Owners en los equipos, y siempre las decisiones serán tomadas por un único Product Owner.
Cuando se trata de productos a escala, las dependencias juegan un papel fundamental y se puede hacer división horizontal o vertical en lineas o suites de producto para facilitar la coexistencia de distintos productos que interactúan entre sí.
Aquí es donde los Analistas de Negocio o Business Analysts pueden jugar un papel fundamental, estando integrados en cada equipo y ayudando al Product Owner en sus tareas.
El Daily Stand-Up tiene que ser de pie
El Daily Stand-Up no existe en Scrum. Se llama Daily Scrum y puede ocurrir de pie, sentado, a través del teléfono o de Slack. El Stand-Up es una práctica de eXtreme Programming y efectivamente se describe como debe de realizarse de pie para aprovechar la presión conjunta y que sea una reunión fluida.
El Scrum Master facilita las retrospectivas
Este es otro de los problemas en Scrum. No sólo no tiene obligación de facilitar las retrospectivas sino que además tiene que participar de ellas.
Muchos Scrum Masters comenten el error de pensar que facilitar retrospectivas es su responsabilidad y muchos de ellos no participan como uno más durante la retrospectiva.
El Scrum Master es un miembro más del equipo Scrum y, como tal, tiene en la Retrospectiva un espacio perfecto para Inspeccionar y Adaptar el proceso. El papel del Scrum Master es el de un Servant-leader que como parte de ese papel puede ayudar a facilitar eventos conforme sea necesario o se le pida.
A la larga y conforme el Scrum Team y la organización maduran, este papel lo van asumiendo otras personas y no queda como responsabilidad específica del Scrum Master.
El Scrum Master tiene que estar en el Daily Scrum
El Scrum Master tiene que asegurarse de que existe un Daily Scrum, que este dura como máximo 15 minutos y que se utiliza para mejorar la transparencia del Incremento en proceso. No tiene por qué atender físicamente al evento ni facilitarlo.
Esto se consigue a través de la pedagogía y a través de hacer que la organización cada vez sea más consciente de como funciona Scrum, sus mecánicas y sus roles.
Las estimaciones tienen que estar hechas en Puntos de Historia
Otro fallo común. El Planning Poker y los Story Points son una técnica más para estimar ítems en el Product Backlog. Hay muchas otras técnicas que son igual de efectivas -o más- que los Story Points.
El problema de fondo es que las estimaciones realizadas por un equipo en Story Points no son equivalentes entre equipos de un equipo a otro y son una visión subjetiva y sesgada de la estimación hecha por un equipo.
La única estimación que tenemos que realizar es saber si los elementos del Product Backlog son suficientemente pequeños y granulares para poder ser seleccionados y consumidos durante un Sprint.
Las estimaciones se pueden usar para medir la productividad y predecir cuando un producto estará terminado
Uno de los mitos y falacias de Scrum mas típicos. La única manera de medir el progreso en Scrum es a través de la entrega de Incrementos usables y de valor.
Intentar medir la productividad en Scrum tiene unos riesgos y es muy probablemente que los esfuerzos para hacerlo resulten en vano.
Eso puede cambiar de Sprint a Sprint dependiendo del contexto del Scrum Team.
Scrum es genial para desarrollar productos en entornos complejos. Realizar estimaciones en entornos complejos basados en estimaciones subjetivas no sólo es infantil (o wishful thinking) sino que además es peligroso, dado que nos da la sensación de que podemos controlar variables que en realidad no manejamos.
Una buena herramienta para reducir la incertidumbre es usar “conos de incertidumbre” o flow metrics tal y como se usan en Kanban. Cuanto más grande sea el Product Backlog, más difícil será tener estimaciones precisas.
El Product Backlog solo puede contener Historias de Usuario
Otro de los mitos y falacias de Scrum. El Product Backlog debe contener cualquier tipo de tarea necesaria para asegurar que el producto crea valor para los usuarios y no solo historias de usuario.
Esto puede incluir tareas técnicas, documentación, testing o incluso reuniones importantes para tomar decisiones para, por ejemplo, decidir la fabricación de un producto. Para tareas recurrentes que deben ser completadas cada Sprint para cada elemento del Product Backlog, se utiliza la Definition of Done.
Los requerimientos no funcionales tienen que estar en el Definition of Done
Otro de los errores en Scrum. Los requerimientos no funcionales (estabilidad, rendimiento) también pueden estar en el Product Backlog.
De hecho, la mejor manera de tratar estos requerimiento no funcionales (no relacionados directamente con la funcionalidad de nuestro producto) que son necesarios para poder desarrollar el mismo, como puede ser montar una infraestructura, necesitar una revisión legal, una traducción o un acuerdo con un proveedor es hacerlo como dependencias en nuestro Product Backlog.
Una dependencia es un elemento que no permite avanzar a otros elementos que dependen de ella hasta está resuelta.
El Scrum Master no es un puesto de management.
El Scrum Master es un puesto de Management, ya que gestiona el proceso Scrum. Sin embargo, el Scrum Master no debe, en mi opinión, ser un manager al uso.
Uno de los dilemas a los que se enfrentan los Scrum Masters es a cómo influenciar a la organización sin tener la autoridad para ello. A pesar de que un buen manager puede ser un gran Scrum Master, sin la formación en Scrum adecuada, los valores correcto y una manera de pensar ágil, es muy posible que su efecto sea más pernicioso que beneficioso.
El equipo de desarrollo o el Scrum Master pueden cancelar un Sprint
El Sprint sólo puede ser cancelado por el Product Owner y el motivo es que conseguir el Sprint Goal ya no es posible, principalmente debido a que los ítems del Sprint Backlog ya no tienen valor.
Esto puede ser debido a que no sea posible tecnológicamente alcanzar un logro, que nuestra competencia cambie las reglas de juego, a un requerimiento regulatorio a que nuestra organización tenga nuevas prioridades estratégicas.
Equipo Scrum tiene que tener 7 más menos 2 personas
El ultimo de esta serie de mitos y falacias de Scrum. Hace tiempo Scrum recomendaba que el tamaño del equipo de desarrollo fuera de 3 a 9 personas, pero no prescribe que éste sea el número necesario de personas en un equipo Scrum. Y hace muchos más años recomendaba que el equipo fuera de siete más menos dos personas.
Hoy en día la recomendación es que el Scrum Team tenga unos diez miembros para mantenerlo efectivo. Muchas más personas incrementan la complejidad y los retos de comunicación. Sin embargo, no tiene un límite inferior de personas que peuden formar parte de un Scrum Team.
Técnicamente un Scrum Team podría estar formado por una sola persona. Hay que tener en cuenta que todo esto son solo recomendaciones.
El tamaño de un equipo Scrum debe de medirse atendiendo a las necesidades del Transparencia, Inspección y Adaptación.
Si quieres saber más, también puedes consultar el artículo sobre los errores en Scrum que cometen los equipos.