Cuando las organizaciones deciden adoptar agilidad, la mayoría opta por Scrum por ser el MÉTODO MAS POPULAR Y UTILIZADO DEL MUNDO. Sin embargo, muchas caen en los mismos mitos y falacias de Scrum. Veamos algunas de ellas y como evitarlas
Un Scrum Master por equipo
Scrum recomienda que en cada equipo 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.
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
Mito. Aunque es muy positivo que exista un Product Backlog antes de empezar el Sprint, este puede perfectamente realizarse como parte del Sprint Planning e ir refinándose durante el Sprint. De hecho, puede ser una tarea totalmente factible para un primer Sprint.
Lo que Scrum dice es que, independientemente de como se haya iniciado el Sprint, al final de este debe haber un Incremento, es decir, Software listo para entregar al cliente, por pequeño que éste sea.
Los Sprints deben durar dos semanas
Falacia. Los Sprints deben durar lo necesario para poder entregar un Incremento completo y nunca más de cuatro semanas. El motivo es que si duran más, 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.
Debe existir una Definición de “Hecho” (Definition of Done)
Falso. La definición de “Hecho” o Definition of “Done” es una práctica recomendada pero no forma parte del núcleo de Scrum. La definición de “Hecho” recoge todas aquellas actividades recurrentes que deben de tenerse en cuenta antes de terminar un Incremento. Esta práctica mejora la transparencia de los Incrementos.
El Daily Scrum es una reunión de sincronización
Falso. El objetivo del Daily Scrum es tener una oportunidad diaria para Inspeccionar y Adaptar. El resultado del Daily Scrum es un Sprint Backlog actualizado con un plan para las próximas 24 horas y 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.
Los ítems del Product Backlog deben estar estimados
Verdadero. Scrum dice que los ítems del Product Backlog deben estar lo suficientemente refinados y ser suficientemente pequeños para ser potencialmente entregables al final del Sprint y, además, estar estimados. Scrum no dice si esta estimación debe ser hecha en Puntos de Historia, mediante Slicing u otras técnicas. La estimación es necesaria porque mejora la transparencia y la inspección.
Esto significa que algunos ítems del Product Backlog, los que están más arriba estarán más refinados y mejor estimados y otros, los que estén más abajo, no lo estarán.
Un Product Owner por equipo
Esta es una falacia. 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 el único Product Owner.
Aquí es donde los Analistas de Negocio pueden jugar un papel fundamental, estando integrados en cada equipo y ayudando al Product Owner en sus tareas.
El Daily Stand-Up tiene que ocurrir con todo el equipo junto de pie
Falso. El Daily Stand-Up no existe en Scrum. Se llama Daily Scrum y puede ocurrir de pie, sentado o a través del teléfono. El Stand-Up es una práctica de eXtreme Programming.
El Scrum Master facilita las retrospectivas
Falso. 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 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 Scrum Master tiene que estar en el Daily Scrum
Falso. 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.
Las estimaciones tienen que estar hechas en Puntos de Historia (Story Points)
Falso. 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. Los Story Points no se pueden cambiar de un equipo a otro y son una visión subjetiva de la estimación hecha por un equipo determinado.
Las estimaciones se pueden usar para medir la productividad y predecir cuando un producto estará terminado
Falacia. Uno de los mitos y falacias de Scrum mas típicos. La única manera de medir el progreso en Scrum es software finalizado y listo para entregar al cliente. Eso puede cambiar de Sprint a Sprint dependiendo del entorno. 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.
Una buena herramienta para reducir la incertidumbre es usar “conos de incertidumbre”. 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
Mito. El Product Backlog debe contener cualquier tipo de tarea necesaria para asegurar que el producto queda como el Product Owner quiere. Esto puede incluir tareas técnicas, documentación o tipos de testing. El uso de una Definición de “Hecho” reduce la complejidad para tareas recurrentes que deben ser completadas cada Sprint
Los requerimientos no funcionales tienen que estar en el Definition of Done
Otro de los mitos y falacias de Scrum. Los requerimientos no funcionales (estabilidad, rendimiento) también pueden estar en el Product Backlog.
El Scrum Master no es un puesto de management.
Falacia. El Scrum Master es un puesto de Management, ya que gestiona el proceso Scrum.
El equipo de desarrollo o el Scrum Master no pueden cancelar un Sprint
Verdadero. El Sprint sólo puede ser cancelado por el Product Owner, cuando este ve que no tiene sentido terminarlo, principalmente debido a que los ítems del Sprint Backlog ya no tienen valor.
Equipo Scrum tiene que tener 7 +/- 2 personas
El ultimo de esta serie de mitos y falacias de Scrum. Scrum recomienda que el tamaño del equipo de desarrollo sea de 3 a 9 personas, pero no prescribe que éste sea el número necesario de personas en un equipo Scrum. El tamaño de un equipo Scrum debe de medirse atendiendo a las necesidades del Transparencia, Inspección y Adaptación
