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: el desconocido y olvidado

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

Multiplica los resultados de tu Sprint Planning

Hoy es día de Sprint Planning. Miras hacia tu equipo y… sólo ves pacas de paja rodar de un lado a otro. ¿Qué ha pasado con tus compañeros? ¿Dónde se esconderán? ¡Te han dejado solo! Te traigo 5 consejos para multiplicar los resultados de tu Sprint Planning.

Por dónde empezar como Product Owner que viene de Tecnología

Estás dando tus primeros pasos como Product Owner, tras haber pasado años diseñando y desarrollando software. Te enfrentas a varios dilemas.

Como empezar como Scrum Master

Acompañar a equipos es una gran responsabilidad pero es muy gratificante. Cada persona y cada equipo tiene unas necesidades diferentes en función de su realidad. Sin embargo, bajo nuestra experiencia, estos consejos pueden servirte para iniciarte como Scrum Master en un equipo.

¿Es conveniente tener un Equipo Scrum en exclusiva para Incidencias?

En tus Equipos Scrum os encontráis en una situación en la que la cantidad de incidencias que hay que atender os penalizan demasiado, o la deuda técnica acumulada aumenta en exceso la complejidad de cualquier evolución en software.

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?

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

Beneficios de la automatización en los equipo Scrum

La automatización, cada vez más, forma parte del desarrollo del software. ¿Qué beneficios tiene para los equipos Scrum?

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.

Apoya a tu equipo entendiendo qué le ocurre

La transparencia es uno de los pilares de Scrum. Con ella conseguimos hacer visible lo que ocurre dentro del producto, equipo, personas, … para hacer inspección y adaptación. ¿Cómo podemos saber qué ocurre en el equipo para poder apoyarle?

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