Según la guía Scrum, el equipo Scrum es un equipo auto-organizado:
“Los equipos auto-organizados eligen la mejor forma de llevar a cabo su trabajo y no son dirigidos por personas externas al equipo. Los equipos multifuncionales tienen todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no son parte del equipo. El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad”
La adopción de la mentalidad Agile a nivel de equipo es una realidad. Apenas ya nadie se cuestiona las ventajas que Agile ofrece al equipo. Sin embargo, en la mayoría de las organizaciones los productos, proyectos y procesos no son llevados a cabo por un equipo de 3 a 11 personas. Sino que muchas veces requieren de 30 o más personas, y es entonces cuando ayuda contar con marcos de trabajo o bibliotecas de recursos que nos doten de herramientas para poder seguir conservando los beneficios de Agile a una escala mayor.
Desde la comunidad Agile se ha tratado de optimizar las distintas partes de una organización. Una manera de hacerlo es reducir, desescalar las organizaciones, se crean equipos auto-organizados. En algunos contextos esto no es posible, no podemos crear equipos donde en cada equipo tenemos a una persona del departamento de “Legales” o de “Finanzas” o de “Marketing”. Sino que hemos de buscar marcos de trabajo que permitan que los distintos departamentos colaboren entre ellos manteniendo el alineamiento en torno a los objetivos de negocio.
SAFe
SAFe® (acrónimo de Scaled Agile Framework Enterprise) es un marco de trabajo para la escalación de las prácticas ágiles basado en los principios de Lean y Agile para el desarrollo de software y sistemas, a nivel corporación. SAFe me ha demostrado ser útil también como marco de trabajo Lean Agile en entornos que no desarrollan software ni sistemas, sino para equipos que participan en un proceso.
SAFe® es un marco de trabajo para la escalación de las prácticas Agile
Hay gente que no considera SAFe como un marco Agile, de hecho, conozco casos donde este marco se ha implantado no como marco de soporte para alcanzar la agilidad sino como un objetivo en sí mismo. Esto ha generado opiniones muy contrarias las cuales entiendo. Sin embargo, mi objetivo no discutir sobre si SAFe es o no es Agile, sino compartir mi experiencia como SAFe nos ha ayudado a adoptar o escalar las practicas Lean Agile en organizaciones con varios equipos que trabajaban en un mismo producto o proceso.
mi objetivo no discutir sobre si SAFe es o no es Agile, sino compartir mi experiencia como SAFe nos ha ayudado a adoptar o escalar las practicas Lean Agile
Marco estricto o Biblioteca
SAFe funciona muy bien si lo interpretamos como una biblioteca de recursos para la escalación de las practicas Agile. Difícilmente nos dará buenos resultados si se aplica como un marco de trabajo rígido donde todos los roles y eventos deben estar presentes por el simple hecho que en el «big picture» aparecen.
Primeramente, como se explica en este otro artículo, SAFe está basado en una serie de principios Lean Agile.
Otra razón por la cual podemos afirmar que SAFe es Agile y que todos los marcos de escalado deben seguir, es el hecho que la base son los equipos Lean Agile.
la base de SAFe son los equipos Agile
Equipos Agile
SAFe promulga que nada debe interferir a los equipos, éstos son el bloque básico de la escalación. El equipo es el ADN sobre el que construir todo, está en el corazón y es donde empieza el escalado de las prácticas Lean y Agile.
Las características de estos equipos, tal y como está reflejado en la biblioteca de SAFe son las siguientes:
- Apoderados, auto-organizados, auto-gestionados y cros-funcionales
- Entregan conjuntamente valor, testeado, a través de un Sistema funcionando cada dos semanas.
Es cierto que SAFe parece imponer una condición a los equipos: “iteraciones de 2 semanas”. La razón detrás de esta imposición es facilitar la sincronización entre equipos para facilitar la alineación a nivel de equipo de equipos (tren) aunque la longitud de iteraciones debería ser aquella que nos permita gestionar aceptablemente el riesgo del negocio y sincronizar el desarrollo con otros eventos de negocio. Las iteraciones podrían ser de 3 o 4 semanas o incluso de 1 semana, aunque es altamente aconsejable que TODOS los equipos trabajen en iteraciones de la misma duración o duraciones múltiplos entre ellas.
A parte de esta restricción, en todas las escalaciones donde se utilice SAFe como marco de referencia, la base son los ser equipos Agile.
