Qué frameworks de agilidad conviene usar según el contexto

A la hora de elegir qué marcos y técnicas se van a utilizar para el trabajo en equipo bajo la filosofía agile, el contexto juega un papel muy importante. Hay técnicas y marcos que son más adecuados para determinados contextos. Y además las distintas opciones no son mutuamente excluyentes. Por otra parte la situación de cada organización siempre será única, e incluso irá variando a medida que sume integrantes, arranque nuevos proyectos, modifique su forma de entregar productos o se incrementen  las habilidades del equipo. Por eso la elección de frameworks de agilidad tiene múltiples variables.

 

No obstante, para ayudar en el cambio de mentalidad y a plasmar estructuras, procesos y mesas ágiles puede ser conveniente elegir y aplicar un marco metodológico –o una combinación de ellos- y asegurarse de que haya coherencia a nivel de la terminología. Y al evaluar qué marco utilizar, es crucial asegurarse de que se ajuste a la compañía, particularmente en lo que hace a sus sinergias “con la ambición, cultura y madurez de la organización”.

 

Los frameworks de agilidad más populares

Los frameworks de agilidad más populares –como Kanban, Scrum y XP- brindan buenos conceptos básicos para comenzar. Pero cada equipo tendrá que descubrir qué funciona mejor en su contexto particular. Por otra parte siempre es posible usar aspectos de una variedad de marcos y complementarlos con otras técnicas: el punto clave es comprender  por qué se lo hace.

 

Por ejemplo la mayoría de los equipos ágiles de desarrollo de software usan Scrum, y muchos de ellos usan al menos algunas ideas de Kanban (por ejemplo los tableros de administración visual).

 

Un estudio encontró que el 84% de las organizaciones usaba tanto Scrum como Kanban. El 78% dijo que usaba Scrum, y el 46% Kanban. Estos dos frameworks implican el uso de un tablero con todo tipo de actividades o tareas que deben realizarse. Ambos proporcionan información sobre el estado y el movimiento del trabajo. “Scrum es un marco ágil para administrar proyectos donde el trabajo se compromete para cada iteración, que se conoce como sprint. Los equipos de Scrum a menudo entregan, se centran en productos listos y tienen roles claramente definidos. Kanban por su parte se enfoca en visualizar el trabajo, limitar las tareas en progreso y asegurar que sigan fluyendo”.

 

La principal diferencia entonces es que un equipo Scrum trabaja en una serie de sprints, por lo que hay un comienzo y un final claramente definidos, así como una sesión de planificación. Kanban, en cambio, es un proceso continuo. Además para trabajar con Scrum hay que conformar equipos interfuncionales dedicados con nuevos roles que sigan las pocas prescripciones que plantea el marco. Kanban por su parte habilita a arrancar con los equipos existentes y a cambiar de modo gradual.

 

El enfoque principal en Scrum está en las iteraciones, o unidades de tiempo fijas  y cortas («sprints»). El punto es entrar en un patrón predecible de entrega de trabajo. El equipo realiza una planificación y revisiones y retrospectivas frecuentes. De tal suerte, Scrum es adecuado para el progreso y la planificación. Esto es, “para el trabajo basado en funciones con grandes objetivos de lanzamiento o hitos”.  Por ejemplo es muy útil para el trabajo de desarrollo de software en el que hay un montón de características que se necesita compilar.

 

En Kanban no hay sprints. Su objetivo es dividir y visualizar pequeñas tareas y tener un flujo de trabajo fluido en los distintos estados. Por lo tanto resulta ideal para hacer mejoras, reparaciones de defectos o pequeños trabajos a medida que surgen.

 

Complementos necesarios

Scrum y XP (marco de programación extrema) manejan un concepto de timebox que se puede usar para permitir que el equipo se concentre en un conjunto específico de trabajo durante un período de tiempo determinado, entregue algo al final y obtenga comentarios. Este enfoque puede ser útil cuando hay que hacer una cantidad considerable de trabajo sobre un producto y se desea desplegar puntos de control frecuentes.

 

En cambio Kanban, al enfocarse sobre el flujo, resulta útil por ejemplo para el trabajo de organizaciones de servicio o asistencia, que deben trabajar sobre tareas que llegan de manera impredecible y se pueden entregar cuando se realizan para proporcionar valor de inmediato. En tales casos este enfoque puede brindar más flexibilidad, sobre todo para responder a los cambios de prioridad.

De todas formas, nada impide a las organizaciones tomar algunos elementos de un marco, y otros de otro. Por ejemplo trabajar con el enfoque de flujo y mezclar puntos de control regulares, reuniones diarias para coordinar actividades y retrospectivas regulares.

 

Para el caso concreto del desarrollo de software, por ejemplo, XP incluye buenas prácticas técnicas que ayudan a mejorar las habilidades básicas de desarrollo de software orientado a la transformación digital. Y esto no se encuentra ni en Kanban ni en Scrum.

 

Por otra parte para grandes proyectos u organizaciones, los métodos ágiles no son suficientes, ya que fueron diseñados solo para equipos pequeños. Por eso en los últimos años surgieron varios marcos de escala ágil, que se basan en prácticas a nivel tecnológico y de gestión.

 

Para escalar la agilidad también hay muchos marcos disponibles, cada uno con su propio enfoque específico. Las organizaciones a menudo adaptan los marcos existentes o desarrollan uno propio. Una investigación encontró que Scaled Agile Framework (SAFe, con 19%) y Scrum of Scrums (17%) son los marcos escalados más comunes; pero muchas organizaciones usan otros (14%) o un marco personalizado.

 

Así las cosas, dado que cada equipo es único, el enfoque ágil debe reflejar su contexto. A veces las organizaciones asumen que pueden tomar un marco específico y «simplemente» usarlo, tal como está. Y lo cierto es que ese marco específico podría no funcionar para su equipo o su proyecto. Tampoco se trata obviamente de dedicar largas horas de reflexión a la elección del framework. Pero sí conviene hacer un análisis  práctico que tome muy en cuenta la situación particular y las características de la organización.

 

¿En su organización eligieron un marco agile específico, combinaron varios o tiene su propio framework personalizado? ¡Nos gustaría que comparta el caso!



Deja un comentario