Lo que te estás perdiendo por hacer «tu» Scrum

Scrum prescribe una serie de roles, eventos y artefactos para adoptar la metodología dentro de los equipos. Estos responden a los pilares y valores sobre los que se construye el marco de trabajo. Para lograr el éxito en la implantación es necesario incorporarlos todos. Pero, ¿qué ocurre si decido utilizar solo alguna de sus partes?

Como cada persona es diferente, el cambio en equipos y organizaciones depende de las personas que los forman. Sin embargo, los marcos de trabajo ofrecen una serie de elementos que nos ayudan a su aplicación. En Scrum esto pasa por incorporar una serie de roles, eventos y artefactos. Sin embargo, muchas veces y debido a incontables factores, nos encontramos con equipos que han desarrollado “su” Scrum. Pero, ¿qué han perdido por adaptarlo?

 

Cambiar la duración del sprint

Imagina que un equipo detecta que no va a alcanzar el objetivo del sprint actual. ¿Qué puede hacer? Una de las ocurrencias puede ser cambiar la duración del sprint para atrasar la fecha de entrega.

Esto implica mucho más de lo que en un principio pueda parecer. Si variamos la duración del sprint estamos distorsionando la predictibilidad del equipo. Los sprints nos permiten crear divisiones iguales de tiempo sobre las que implementar la inspección, adaptación y transparencia. De esta forma, es más fácil para los equipos utilizar la experiencia de sprints previos para planificar.

Antes de plantear modificar la duración del sprint, revisa qué ha ocurrido para que no se consiga el objetivo del sprint.

 

La daily como reporte

Si tus dailies son un reporte al Product Owner o al Scrum Master donde cada miembro del equipo de desarrollo únicamente comenta qué hizo el día anterior con todo lujo de detalles, estás perdiendo la oportunidad de hacer inspección y adaptación para crear un plan de trabajo para las siguientes 24 horas que nos acerque al objetivo planificado.

Recuerda que la daily es un evento para el equipo de desarrollo. La intervención del Scrum Master es, inicialmente, para asegurar que ocurre. La presencia del Product Owner no es necesaria, según la guía de Scrum.

Con el reporte estás restando capacidad de inspección y adaptación del equipo de desarrollo, además de rebajar la calidad de la información y restar capacidad de toma de decisión.

**Si quieres saber cómo mejorar tu Daily, en este enlace te dejamos algunos consejos.**

 

Una retrospectiva cada cuatro sprints

Cuando llegan las prisas a los equipos de desarrollo, lo que ocurre más cerca de la entrega, es susceptible de ser suprimido. Igual que en algunos equipos vemos que las pruebas se quedan sin realizar para dedicar ese tiempo a terminar el código, con los eventos puede Scrum ocurrir lo mismo. La retrospectiva se pospone hasta acumular varios sprints muchas veces motivado porque en ese evento no se aporta valor al cliente.

La retrospectiva favorece la mejora continua del equipo a través de las experiencias vividas. Las acciones resultantes de la sesión van dirigidas a revisar los procesos internos e impulsar la cultura de mejora continua del equipo.

Visto en datos, en un equipo que hace sprints de dos semanas hay 26 retrospectivas al año o, dicho de otro modo, al menos hay 26 mejoras a implementar por el equipo. Al reducir una retrospectiva cada cuatro sprints, se reducen las mejoras a 6 al año. Has perdido 20 oportunidades de mejorar el equipo ¿Crees que esto no afecta al aporte de valor del equipo?

 

El Scrum Master también es desarrollador 

En ocasiones el trabajo del Scrum Master es entendido sólo como el facilitador de eventos de Scrum, y no cómo el guardián del proceso Scrum completo. Cuando un Scrum Master ejerce también el rol de desarrollador, es muy probable que pierda la visión general del equipo, y que deje de lado parte de sus responsabilidades: ocuparse de los impedimentos que aparecen; proteger al equipo de terceros y del Product Owner; preparar las sesiones Scrum para que sean efectivas y cumplan su objetivo; liderar, entrenar y acompañar a la organización; fomentar la mejora contínua; etc..

El Scrum Master es el encargado de velar por la correcta aplicación del marco de trabajo, sirviendo al equipo de desarrollo, al Product Owner y a la organización. Como ves, su ámbito de actuación va más allá de facilitar sesiones y del equipo Scrum.

 

En resumen

  • Cambiar la duración del sprint afecta a la predictibilidad del equipo y dificulta la planificación de los sprints.
  • La daily como reporte afecta a la inspección y adaptación del equipo. Además rebaja la calidad de la información y resta capacidad de toma de decisión.
  • Una retrospectiva cada cuatro sprints limita la mejora continua del equipo
  • Si el Scrum Master también forma parte del equipo de desarrollo estás reduciendo su ámbito de acción al equipo Scrum y dificultando que ejerza adecuadamente su rol..

Como decíamos al principio, cada equipo y la realidad que lo rodea hacen que la aplicación de Scrum varíe de un equipo a otro. Antes de adaptar Scrum, dedica un tiempo para analizar las consecuencias de esa adaptación y lo que estás perdiendo.

También te puede interesar

El Product Owner y su relación con los Stakeholders

Como Product Owner enseguida te has dado cuenta de la gran importancia que tiene tu relación y la del Equipo Scrum con los Stakeholders.

Mi estrategia de Onboarding como Scrum Master

Me incorporo a un equipo como Scrum Master, ¿¿por dónde empiezo??

Estoy seguro de que esta pregunta ha pasado por la cabeza de más de uno y de una cuando se ha enfrentado al reto de comenzar a trabajar en una nueva empresa o con un nuevo equipo. En este post quiero compartir una estrategia que yo he utilizado y me ha sido útil para abordar el proceso de onboarding.

Aprendiendo en un Equipo Scrum

El conocimiento compartido potencia a tu equipo. Aquí descubrirás cómo identificar las áreas de conocimiento y favorecer su aprendizaje continuo

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

El Product Owner: el desconocido y olvidado

Desde hace tiempo tengo la sensación que se desconoce la función de un Product Owner.

El uso de las Métricas para saber nuestro nivel de Incertidumbre

Scrum nos ayuda a manejar la incertidumbre. Pero ¿cómo sabemos que lo estamos consiguiendo? ¿Qué métricas pueden ayudarnos a confirmar que tenemos bajo control la incertidumbre?

Cómo facilito una retrospectiva si no soy Scrum Master

Una buena retrospectiva da la oportunidad al equipo de analizar su funcionamiento y establecer mejoras. Te dejamos consejos para facilitarla.

Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

Burndown y Burnup para el Scrum Master

Como Scrum Master puedes obtener información muy valiosa analizando estos dos gráficos para entender lo que está ocurriendo en tu equipo.

Es importante usar Historias de Usuario

Usar Historias de Usuario es importante para los Product Owner, además de la más utilizada a la hora de escribir el Product Backlog.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies