¿Tu equipo “pretende” ser ágil?

Según el 15to informe anual State of Agile, ha habido un gran aumento en la adopción de marcos ágiles durante el último año. Dentro de los equipos de software, la adopción ágil creció del 37% en 2020 al 86% en 2021.

En medio de esta explosión ágil, muchos equipos están pasando por dificultades. De acuerdo con el informe antes mencionado, el 46% de los encuestados informa tener dificultades con prácticas inconsistentes y el 43% informa casos culturales.

¿Por qué es esto? A menudo, las organizaciones y los equipos que adoptan Scrum no han adoptado por completo los conceptos detrás del empirismo (tomar decisiones basadas en lo que se sabe) y no han adoptado los tres pilares que hacen posible el empirismo: transparencia, inspección y adaptación.

En cambio, muchos equipos que se mudan a un marco ágil terminan siguiente los pasos sin comprender la razón detrás del marco. Cuando esto sucede, Scrum (o cualquier otro método ágil) simplemente se convierte en un escaparate sin mucho valor.

A continuación, se presentan algunos síntomas comunes de los equipos que “pretenden” ser ágiles:

• Los equipos no están entregando un incremento utilizable “terminado” en cada Sprint. Por usable queremos decir que el producto está completamente probado y proporciona un incremento completamente usable de funcionalidad valiosa.
• Daily Scrum es una actualización de estado en lugar de una mini sesión de planificación.
• La reunión de Sprint Review es simplemente una demostración y no una oportunidad de colaboración.
• La Sprint Retrospective no da como resultado ideas de mejora procesables que el Equipo Scrum aborde de manera proactiva.
• La calidad del producto resultante del trabajo del Equipo Scrum no está aumentando.
• El Scrum Master no está capacitando al Equipo Scrum ni a la organización matriz en técnicas para mejorar el uso del marco Scrum.
• Los desarrolladores no se autogestionan ni colaboran con el Product Owner para maximizar el valor del producto.
• La organización no respeta las decisiones del Product Owner.
• Los administradores de recursos no saben cómo apoyar a los equipos ágiles.

Primero, ¡no te rindas! La adopción del marco Scrum es un viaje continuo.

En segundo lugar, comprende que la base de Scrum es el proceso de control empírico. El marco funciona mejor cuando los eventos, artefactos y responsabilidades de Scrum incorporan los tres pilares de transparencia, inspección y adaptación.

A continuación, se muestra una descripción general de cómo se aplica el empirismo a los eventos, artefactos y responsabilidades de Scrum y presenta algunas preguntas difíciles para determinar si su equipo realmente ha adoptado Scrum o simplemente está fingiendo.

El Sprint es un contenedor para todos los eventos de Scrum. Durante el Sprint, no se producen cambios que puedan poner en peligro el Sprint Goal, la calidad no disminuye, el Product Backlog se refina según sea necesario y los Developers pueden aclarar o renegociar el alcance con el Product Owner a medida que aprende más. La duración del Sprint debe permanecer bastante constante a lo largo del tiempo (no debe cambiar cada Sprint) y debe ser de un mes o menos.

El Sprint Planning es el primer evento dentro de un Sprint. En el evento Sprint Planning (con un límite de tiempo máximo de ocho horas), el Equipo Scrum inspecciona el Product Backlog y crea el Sprint Backlog para el próximo Sprint.

El Daily Scrum es un punto de contacto para los Developers. Tiene un tiempo fijo de 15 minutos para cada día del Sprint. El propósito de este evento es aumentar la probabilidad de que el Equipo Scrum logre el Sprint Goal. Brinda una oportunidad para que los Developers analicen el progreso y planifiquen el trabajo para las próximas 24 horas.

La Sprint Review es el tercer evento dentro del Sprint. El propósito de este evento es que el Equipo Scrum y sus interesados inspeccionen los resultados del Sprint y adapten el Product Backlog en función de los comentarios.

La Sprint Retrospective es el evento final de un Sprint. Su propósito es que el Equipo Scrum se inspeccione a sí mismo y encuentre formas de mejorar la calidad del producto y la efectividad del equipo.

El Product Backlog es una lista única y ordenada de todo lo que se saba que se necesita en un producto. En pocas palabras, en la lista de tareas pendientes para el Equipo Scrum. El Product Owner es responsable del contenido y el orden del Product Backlog, y nadie puede decirles a los Developers que trabajen desde otra lista.

El Sprint Backlog es el plan de los Developers para lo que lograrán en el Sprint. Contiene el Sprint Goal, los elementos del Product Backlog que los Developers han seleccionado para el Sprint y su plan para entregarlos.

El Increment es el producto (o productos) que el Equipo Scrum entrega al final del Sprint. Es la sima de todos los elementos del Product Backlog completados dentro de un Sprint. Existe un incremento tan pronto como un solo elemento del Product Backlog cumple con la Definición de Terminado.

El Product Owner representa los intereses de los interesados del producto de la empresa o la comunidad a través del contenido y el orden del Product Backlog. El Product Owner puede delegar este trabajo, pero sigue siendo responsable de él, y nadie puede decirles a los Developers que trabajen desde otra lista.

Los Developers estiman, planifican y ejecutan el trabajo del Equipo Scrum. Colaboran con el Product Owner para maximizar el valor del Product Backlog y determinar qué elementos de trabajo incorporar al Sprint (los Developers son propietarios del Sprint Backlog).

El Scrum Master es responsable de establecer Scrum de acuerdo a la Guía Scrum. Suene simple, pero no lo es. Ser un Scrum Master implica en parte arte y ciencia. El Scrum Team perfecto no evoluciona de la noche a la mañana. Puede llevar años convertirse en una unidad de alto rendimiento. Un Scrum Master sabio sabe qué desafíos abordar primero.

El viaje hacia el Equipo Scrum ideal no ocurre de la noche a la mañana. Si encuentras síntomas de que tu equipo simplemente pretende ser ágil, discute lo que encontraste en la Sprint Retrospective. Usa este evento para identificar mejoras procesables para tu Equipo Scrum.