open langage menutoggle menu
All News

La importancia de los valores Scrum en un equipo

Muchas veces, nos podemos encontrar con listas enormes de valores en paredes o en las webs de las organizaciones. Valores que sólo se hablan, pero no se practican.

Curiosamente, pasa lo mismo con un equipos Scrum, que usan Scrum pero nadie recuerda los valores de Scrum, ni nadie promulga estos valores. Esto puede llevar a que Scrum no se aplique correctamente ayudando a las organizaciones a maximizar la entrega de valor Sprint a Sprint.

Cuando nos enfocamos en los valores de Scrum que son: coraje, respeto, foco, compromiso y franqueza. Esto nos lleva a lo siguiente: los pilares de Scrum que son transparencia, inspección y adaptación y esto hace que todo cobre vida y que se cree un entorno de confianza para todos.

Veamos los valores de Scrum uno por uno.

Valores de Scrum

valores Scrum : courage, focus, commitment, respect, openness

Que podemos observar si no adoptamos los valores de Scrum

Compromiso
Muchos equipos me comentaban que iban bien y que no necesitaban una retrospectiva.

Todo y todos podemos mejorar. La retrospectiva (es el corazón del empirismo) es una oportunidad para que el Scrum Team se inspeccione a sí mismo y cree un plan de mejoras que lo introducirá para el próximo Sprint. Si no lo hacemos caemos en la trampa de falta de mejora y nos podemos estancar.

Coraje
En la mayoría de los equipos donde he colaborado ví como nos absorbía el concepto que la Review es un reporte del Sprint. Y lo difícil que fue cambiar esto.

La Sprint Review se lleva a cabo al final del Sprint para la inspección del incremento y adaptación del Product Backlog. Durante este evento, el equipo Scrum y los stakeholders colaboran sobre lo que se hizo en el Sprint. Es importante matizar que este evento no es una sesión de seguimiento y control como hacen muchos equipos. Sino es una oportunidad para inspeccionar el incremento y fomentar la colaboración. El equipo tiene que tener el coraje para manifestar esto ya que al no ejecutar la Review como es debido, perdemos una oportunidad valiosa de inspección y adaptación.

Foco
¿Te imaginas que en el evento de la Daily pueda participar cualquiera que no sea del equipo de desarrollo? ¿te suena de algo? esto lo escuché y lo ví mucho.

Vamos a aclarar el concepto de la Daily. Este evento lo utiliza el equipo de desarrollo para inspeccionar el progreso hacia la consecución del objetivo del Sprint. y ver la tendencia de tiene el equipo para completar el trabajo para alcanzar el Sprint Goal. Este evento le permite al equipo optimizar la probabilidad para alcanzar su objetivo. ¿Qué pasaría si ejecutamos la Daily malamente? ¿Pero cómo sería eso? veamos unos casos:

  • Algunos días no se hace por que hay ciertos problemas.
  • No está el Scrum Master entonces no se hace.
  • Falta una persona del equipo que no puede venir.
  • El scrum Master comienza a dirigir la Daily-
  • etc.

El Daily ejecutado correctamente optimiza el foco del equipo en alcanzar sus objetivos.

Nota: Recuerda que el Scrum Master solo puede asistir a la Daily para asegurar que este evento tiene lugar.

Franqueza
Últimamente se puede observar como se hace la conversión automática durante un proceso de transformación digital de un Project Manager a un Scrum Master, muchas organizaciones comentan que es la mejor persona para llevar a cabo este rol, ya que tiene experiencia en trabajar con equipos y muchos son líderes. Pero la realidad es que frecuentemente nos damos cuenta que esto es un error y muchas veces suele fallar. 

¿Que pasa cuando un Project Manager le piden que haga de Scrum Master (muchas veces sin apenas formación)?

Muchos Scrum Master que vienen de haber sido Project Manager durante muchos años, siguen con esa mentalidad de jerarquía y reporting a sus Managers Seniors, además de seguir gestionando el trabajo. Esto solo puede ir a peor, como por ejemplo responsabilizar el Scrum Master del trabajo cuando no se cumplen los objetivos. Y si el Scrum Master es bien acogido por el equipo, se podrá comenzar a ocultar cierta información a la organización por parte del Scrum Master y por parte del equipo. Esto puede hacer perder la oportunidad de autoorganización del equipo, ya que ni el Scrum Master ni el equipo de desarrollo están siendo francos con la organización sobre la situación que está pasando. 

Respeto
Como bien se indica en la guía Scrum, el Product Owner es la única persona responsable de gestionar el Product Backlog. Para que el Product Owner tenga éxito es importante que toda la empresa respete sus decisiones. Para hacer esto, es importante que el Product Owner tenga conocimientos profundos de negocio, ya que a no ser así, la mayoría de las decisión vendría tomadas desde otras capas de Management. Y cualquier inspección y adaptación durante el Sprint puede convertirse en un reto. Lo que conlleva a la disminución de la entrega de valor por falta de tomas de decisión sobre el producto.

Conclusion
Si hay algo de Scrum que no funciona y no ves cómo abordarlo, párate unos minutos y piensa en los valores de Scrum. Si el equipo y la organización no lo saben explicaselos detenidamente. Los valores son la base fundamental para la ejecución de Scrum correctamente y para alcanzar la auto-organización a nivel organizativo además de a nivel de equipo.