Jaime Yáñez Peña

Head of Agile - Belltech

Profesor - Universidad del Pacífico

CEO - Beam23

Blockchain Expert - Cripto.Guru

Jaime Yáñez Peña

Head of Agile - Belltech

Profesor - Universidad del Pacífico

CEO - Beam23

Blockchain Expert - Cripto.Guru

Desde el Blog

Scrum: La cruda verdad

Scrum: La cruda verdad

Advertencia: Todos los personajes de este post son ficticios.

Empecemos: existe en la actualidad un sin fin de empresas que «hacen» scrum, o en su defecto tienen un «scrum master» o que están orgullosos de hacer scrum diario. Scrum está en todas partes y es el marco más popular para usar.

Cuando llega el momento de la realidad, está claro que scrum no es lo que las empresas tienden a hacer.

1. Roles de Scrum

Volvamos a las raíces: hay tres roles en scrum: propietario del producto, scrum master y equipo de desarrollo. Sin embargo, en muchas empresas añaden roles como «Agile Manager» que es como un PM o gerente de proyecto.

Estos roles añadidos son parte de los procesos de transformación en los que aún, muchas empresas, se encuentran. Y estoy seguro que responden incluso a necesidades internas de mantener a las personas en las organizaciones, pese a que se resistan al cambio o incluso no se capaciten para los nuevos retos de los entornos de transformación digital.

¿En qué se diferencia el PM del Scrum Master?

  • La misión principal del Scrum Master es facilitar las reuniones de trabajo, de manera que sean los más ágiles y productivas posibles, tratando de eliminar los obstáculos e interrupciones. El Project Manager lo que busca es que se siga una planificación previamente definida, aunque suponga una mayor dilatación de los tiempos.
  • El rol del Scrum Master es más de apoyo y de motivación de los miembros de su equipo, priorizando la máxima comunicación y la generación de sinergias positivas. Mientras que el Project Manager tiene un papel más de líder tradicional, de referente y de responsable máximo del equipo y del proyecto.
  • En cuanto a metodología, por lo general el Scrum Master trabaja con equipos más reducidos y presupuestos más pequeños que el Project Manager, cuyos recursos humanos y económicos suelen ser más potentes.
  • Normalmente el Scrum Master trabaja de manera más estrecha con su equipo, priorizando la comunicación y tratando que se produzca el entorno idóneo para que fluyan las ideas más creativas e innovadoras. Por el contrario, el sistema de trabajo del Project Manager es más tradicional, buscando un producto puede que no tan original, pero con vocación de permanecer  más tiempo en el mercado.

La figura del Scrum Master es en definitiva, la consecuencia lógica de los nuevos métodos de trabajo requeridos, sobre todo para la generación de productos digitales, los cuales, al estar muy influenciado por un entorno en constante transformación, precisan de un liderazgo mucho más flexible y dinámico para lograr resultados rápidos, originales y de calidad.

Hace algunos años conocí a «Laura», una Project Manager que ejercía el rol de «Agile Manager» en una mesa ágil de un cliente. «Laura» se dedicaba a ejercer comando y control sobre el equipo, incluso «midiendo» el tiempo en que ese equipo almorzaba o salía al baño. «Laura» nunca se transformó, ni le dio espacio a la agilidad. Porfavor, si eres PM y te pasas al lado ágil dedícate a aprender tu rol, transfórmate a bien y si empiezas a ver la agilidad, hazlo bien y ejerce un liderazgo servicial. Olvídate del control y no seas como «Laura».

2. Eventos Scrum.

Solo hay cuatro reuniones en el marco: planificación de sprint, scrum diario, revisión de sprint y retrospectiva.

El sprint

Por alguna razón, un sprint se define como una iteración de 1 a 4 semanas durante la cual el equipo codifica. Dividir el trabajo en sprints puede ayudar a ver la velocidad del equipo en los puntos de la historia y verificar cuán buenos son los procesos ágiles que estamos siguiendo.

Un sprint es una iteración de un período fijo de tiempo durante el cual el equipo de desarrollo se mata por sacar el incremento. El primer sprint es seguido por otro, y otro, ad infinitum… Todo Sprint tiene su comienzo, tiene su fin y una meta. 

Aquí te recomiendo que no seas como «Jhonny», un Scrum Master que conocí hace tiempo, que tenía como «buena práctica» cambiar constantemente la duración de sus Sprints o incluso tenía como buena práctica «terminar» o «acortar» sprints cuando se le daba la regalada gana. Entiende que los Sprints tienen una duración fija. Por favor, no seas como «Jhonny».

Planificación de sprint.

La planning dura hasta 8 horas para un Sprint de 4 semanas, si tienes Sprints más cortos, haz la matemática.

La planning ayuda al equipo a poder entender lo que necesitan hacer durante el sprint, esto se conoce como objetivo del sprint y se vincula estrechamente a la visión del producto que tiene el Product Owner y su gestión de incrementos. Recuerda que el rol de Product Owner es el de decidir «Qué» se hace en este Sprint, y el rol de equipo de desarrollo es decidir «Cómo» lo hacen (Esto incluye las estimaciones).

Hace unos años conocí a «Ren», un orgulloso Product Owner de un gran cliente, que tenía como mejor práctica decidir qué se hace, cómo se hace y encima estimar el trabajo por el equipo. No solamente eso, «Mike» el Scrum Master de esa mesa, permitía que eso suceda, sin blindar a su equipo ni dar espacio a la experimentación propia de una ceremonia tan importante como la Planning. Entiende que es el equipo quien estima. Por favor, no seas como «Ren» si eres Product Owner, y menos seas como «Mike» si eres Scrum Master.

Scrum diario

Ceremonia importante, corta. No es una reunión de seguimiento o control y recuerda que si eres el Scrum Master tienes el deber de facilitarla.

Aún recuerdo los Scrum Diarios de «David», Scrum Master orgulloso de una célula que usaba JIRA como herramienta de «control». Recuerdo a «David» asignando tareas al equipo, estimando sus tiempos o incluso poniéndole deadlines a las tareas, solo porque «David» era la mano derecha del Project Manager de esa célula. Probablemente la diferencia entre Scrum bien hecho y el equipo de «David» es que «David» tiene un equipo que poco o nada sabe de agile, que seguramente «David» no se dedicó a evangelizar o por lo menos entrenar en lo más básico del marco. Por favor, no seas como «David» y recuerda que es tu rol evangelizar a tu equipo en el marco.

Revisión del Sprint

La revisión del Sprint o la Review es un momento para que se muestre en incremento y se obtenga feedback del producto por parte del Product Owner o los Stake Holders. Al menos eso es lo que se entiende en el marco Scrum, pero tuve la oportunidad de ver cómo muchas reviews o revisiones se tornan en sesiones de guerra. No permitas que tu equipo use la review como una catarsis. No seas como «David».

Retrospectiva

Una retrospectiva es la oportunidad perfecta de inspeccionar y adaptar la práctica del equipo, sacamos feedback del equipo para mejorar continuamente. La retro es del equipo.

Me tocó ver a «David» facilitando retrospectivas, me tocó ver a ese equipo y sentir cómo se ven obligados a hacer la retro. Me tocó ver que esas retrospectivas no eran más que reuniones de culpa, en donde alguien dice que otra persona no hizo A, B o C cosa y que por eso hay deuda técnica. Me tocó ver a ese equipo gritarse en las retrospectivas de «David»…


Si conoces equipos como estos, con personajes como los que mencioné, o peor aún, estas inmerso en un equipo así, lo siento por ti: Tu organización, empresa, equipo, no hace scrum.

Mi consejo? Empieza por meterte de lleno en el marco, pero incluso antes de eso, empieza por creer en el manifesto ágil, en sus valores, principios, lee sobre Scrum y entiende que Scrum se trata de las personas, de su adaptación, de la experimentación, pero sobretodo: entiende que Scrum es un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, revisando y mejorando siempre!

Taggs:
1 Comment
  • Fredy Asencios 4:00 pm octubre 9, 2019 Responder

    Buen post Jaime!!

Write a comment