Muchas empresas que desarrollan sus proyectos de forma “tradicional”, con un enfoque en cascada, se ven deseosas o tal vez tentadas de aplicar metodologías ágiles en determinados equipos o áreas, antes de acometer una transformación más profunda. Quieren entender qué es Agile, y si realmente aporta algo diferencial respecto a trabajar “como siempre”. Las reticencias suelen tener con el hecho de “ceder” recursos para trabajar de forma autónoma y “sin jefe” durante un periodo que se considera “indeterminado”, y para desarrollar un producto o servicio de resultado “variable”.
La incertidumbre de no saber el resultado de esta apuesta echa muchas veces por tierra estos intentos de acometer la agilidad en la dimensión operativa de la empresa, a menudo debido a la falta de acompañamiento desde la dimensión cultural, es decir: cómo se relacionan las personas y los equipos. Es más: si no hay un compromiso y apuestas claros por parte de la dirección y hacia abajo, estos conatos de agilidad se podrían convertir en flor de un día sin solución de continuación.
Filosofía, metodología y frameworks Agile
Como filosofía, Agile que se manifiesta en diferentes frameworks y metodologías, como son SCRUM y Lean, o Design Thinking y Lean Start Up, respectivamente.
Concretamente, SCRUM es un marco de trabajo concebido para el desarrollo y mantenimiento de productos complejos. Se viene usando desde al menos la década de los 90, dando el salto desde el mundo del software a las empresas del conocimiento en los últimos años.
Tal y como previene la guía SCRUM, es un framework tan fácil de entender como difícil de aplicar. El primer paso para comprender qué es y qué no es SCRUM es entender que un framework no es un manual de instrucciones a seguir paso a paso, no es un proceso ni una técnica para construir productos o desarrollar servicios, sino un marco en el cual se pueden emplear varias técnicas o procesos.
SCRUM es Agile porque se basa en el empirismo: el conocimiento no se basa en los procesos que se siguen, ni en las herramientas que se usan, sino que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. Por esto precisamente, SCRUM emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control de riesgo en entornos de incertidumbre.
Eventos (reuniones) dentro del marco SCRUM
SCRUM utiliza una serie de eventos, roles y artefactos, e indica las reglas que gobiernan las relaciones e interacciones entre ellos.
Concretamente en el caso de los eventos, SCRUM solo especifica cuatro reuniones como tal, en las cuales el equipo se encuentra o se relaciona con otros implicados en el éxito del producto. Los eventos de SCRUM son la reunión de planificación del Sprint (Sprint Planning Meeting), la reunión diaria (Daily SCRUM), el evento de revisión del Sprint (Sprint Review) y la retrospectiva del Sprint (Sprint Review).
Esto no significa que más allá de estos cuatro tipos de eventos tipificados por SCRUM el equipo no pueda reunirse, conversar o juntarse para debatir aspectos que tienen que ver con el producto, sino que los cuatro descritos han de desarrollarse según lo indicado en la guía SCRUM para que el framework “funcione”.
Eventos SCRUM vs. reuniones “no ágiles”.
Las reuniones o eventos de SCRUM se diferencian por al menos tres características:
- Ser tremendamente operativas: cada persona sabe a lo que va, qué tiene que mostrar y qué debe hacer.
- Tener un tiempo máximo (Time box) para llevarse a cabo, comenzando y terminando puntualmente.
- Tener una frecuencia: el ritmo sostenido a lo largo de todo el desarrollo es fundamental para el éxito de SCRUM.
Dicho de otro modo:
Frente a reuniones “no ágiles” en las que no se prepara bien el contenido de la misma ni se sabe su objetivo o propósito, cada persona defiende su área/ función/ intereses, o no es claramente constatable la contribución de cada persona hacia el objetivo común…
Las reuniones Agile facilitan y promueven que todos los participantes tengan claro el objetivo de la reunión, se compartan valores y un lenguaje común, y el progreso hacia el objetivo común sea inspeccionable y seguible por cualquiera (gestión visual).
Algunos consejos para introducir la agilidad en los equipos
Antes de la reunión
- Tipificando el tipo de reuniones que se pueden convocar o mantener. Por ejemplo, kick off, seguimiento dentro del equipo, información a los Stakeholders, revisión del progreso…
- Estableciendo la alianza y reglas de la reunión: qué valores nos van a guiar y cuál van a ser los comportamientos permitidos (móviles alejados, no consultar el correo, cámara activada…)
- Preparando la reunión con agenda, objetivos, lecturas previas o contribuciones concretas a presentar.
Durante la reunión
- Asistir solo si es imprescindible, durante el tiempo imprescindible. La puntualidad es obligatoria, al inicio y al final.
- Siendo conciso y pensando en qué va a hacer, no en justificar qué ha hecho/no ha hecho.
- Buscando el win-win (propósito común).
- Siendo proactivo en la búsqueda de soluciones.
Después de la reunión
- Llevando a cabo los compromisos acordados.
- Siendo transparente con los demás en cuanto al avance real de su trabajo.
- Sabiendo comunicarse y colaborar o co-crear a través de las herramientas establecidas en el equipo (artefactos).
Conclusiones:
- Las reuniones pueden convertirse en oportunidades de trabajar bajo los principios de agilidad que subyacen bajo el framework SCRUM (transparencia, inspección, adaptación), aunque no se esté trabajando bajo dicho marco.
- Todo lo que no aporte valor (cuantitativo o cualitativo) en las reuniones debe ser eliminado.
- La mejor reunión es la que se prepara por parte de todos los miembros del equipo, y en la que todos actúan como un único “team” enfocado al propósito común.
Para saber más:
Guía SCRUM.
Ser Agile vs hacer Agile.
Fuente de la imagen: https://unsplash.com/photos/smgTvepind4