Scaled Agile Framework (SAFe), una metodología ágil para grandes empresas

El último debate en el mundo ágil ya tiene nombre: SAFe. Una metodología, más concretamente un framework, creado por un Sr. llamado Dean Leffingwell, (si su apellido fuese Pérez nadie hablaría hoy de SAFe) y que ha saltado a la fama al unir agilidad + polémica.
Hoy te voy a dejar un resumen de qué es SAFe, y mañana te cuento el porqué la polémica. Aunque, para los más antiguos del lugar, te adelanto que el tal Leffingwell trabajó… en Rational (para los más jóvenes del lugar, lee esto las 3 metodologías más importantes en los 80 y los 90.)

SAFe: una metodología ágil para organizar grandes empresas

El objetivo de SAFe es ayudar a implementar la agilidad en la empresa, a nivel de la organización, y no sólo a nivel de equipo, algo a lo que, por ejemplo, está más enfocado Scrum.
SAFe está basado en principios ágiles y Lean, y para su implantación en una empresa se distinguen tres niveles de abstracción que hay que coordinar entre sí: el nivel de equipo, nivel de programa y nivel de portfolio.
Cada uno de estos niveles posee un Backlog (team Backlog, program Backlog y portafolio Backlog), en los que se incluyen“historias” a distinto nivel de abstracción en función de cada nivel: Historias de usuario (a nivel de equipo) – Features (a nivel de programa) – Epopeyas (a nivel de portafolio). Si quieres ampliar sobre estos conceptos, te dejo aquel post de cómo gestionar qué esperamos de un proyecto ágil: temas, epopeyas e historias de usuario. 
Veamos un resumen de cada nivel…

1 – Nivel de equipo

En este nivel se define cómo organizar a cada equipo que interviene en el desarrollo software. SAFe propone que los equipos utilicen una combinación de técnicas de Scrum (en el equipo está presente la figura del Product Owner y Scrum Master, el trabajo se planifica en iteraciones y se emplean las historias de usuario, de la misma forma y con el mismo significado que Scrum) y XP, aparecen los “spikes”, que son historias especiales que se realizan cuando, por ejemplo, una historia es muy compleja y es necesario que el equipo investigue posibles soluciones o se familiarice con alguna técnica.
A este nivel, el único rol que varía un poco es el de Scrum Master, que aparte de las funciones básicas de Scrum, se comunica y coordina con los Scrum Masters de otros equipos y participa en los “ART release Planning meetings” (ahora vemos lo que es un ART).

2 – Nivel de programa

A este nivel aparecen nuevos roles como “System Team”, “Product Manager”, “System Architect” (que es la autoridad de diseño a nivel de programa, y trabaja con los equipos asegurándose de que se cumplen los requisitos no funcionales acordados en el software que se está desarrollando), etc.
A este nivel se definen los Agile Release Train (ART), que mencionamos antes, a grandes rasgos se puede decir que una iteración es al nivel de equipo lo que un ART al nivel de programa. En un ART trabajan conjuntamente entre 5 y 10 equipos, sincronizando sus iteraciones y releases.
Además, hay un “program backlog”, que es una lista priorizada de “features”.
Estas features se priorizan utilizando el framework Weighted Shortest Job First (WSJF).Las features pueden originarse a nivel de programa o derivar de epopeyas definidas a nivel de portafolio. Las “features” se descomponen en historias de usuario, en las que trabajan los equipos.
Cada 10 semanas (5 iteraciones) se produce la release, y se obtiene un Incremento Potencialmente Entregable (PSI). Una vez este termina se planifica el siguiente PSI.
A nivel de programa, hay un equipo de gestión de release (Release Management Team), en el que se incluye representación de gente marketing, desarrolladores, calidad y despliegue) y aprueba lo que se va a entregar a los clientes en las distintas releases.
En este nivel hay que tener un cierto tipo de visión global acerca de lo que se quiere conseguir en cada ART, para coordinar a todos los equipos que trabajan en ella y que tengan los mismos objetivos comunes. Para esto ayuda bastante el roadmap (que se define a nivel de portafolio) y en el que se incluyen normalmente las releases que se van a hacer en los próximos 3 a 6 meses.

3 – Nivel de portafolio

A nivel de negocio se planifican epopeyas a alto nivel, alineando los objetivos de negocio y arquitectura del sistema. A este nivel se define a grandes rasgos lo que más valor aporta a la organización, y se emplean los principios de Lean, además de utilizar tableros Kanban para organizar las tareas de este nivel.
A nivel de portafolio también se llevan a cabo y se controlan distintas métricas como la satisfacción de los empleados de la empresa, de los clientes, la calidad del  software que se lanza al mercado y el número de releases al año que realiza la empresa.

8 comentarios en “Scaled Agile Framework (SAFe), una metodología ágil para grandes empresas”

  1. Hola Dr. me sirven de mucho sus publicaciones son muy interesantes.
    Actualmente me encuentro con una problemática con el SAFe 3.0, recién lo estoy estudiando para poder implementarlo en mi trabajo, me encuentro analizando el nivel de Portafolio, pero me gustaría saber si de favor me pudiera orientar con unas buenas prácticas para poder obtener los «Temas estratégicos».
    Y al igual ¿Cómo inducir al framework a equipos multidisciplinarios? ya que la mayoría no son del área de software.
    Saludos

  2. Muchas gracias por el resumen, muy bueno y muy concreto. Veo oportunidad en la traducción al español, misma que me genera una duda, la «epopeya» es el «epic»?

  3. Hola Javier, me agradó tu resumen;
    ahora a leer todo sobre SAFe me parece interesante, agradeceria puedas publicar mas casos prácticos.
    continua compartiendo conocimiento.

  4. Hola Javier,
    simple y útil, como de costumbre 🙂
    Tengo un par de consultas:
    – Recomiendas SAFe frente a otras metodologías de escalado en grandes empresas?
    – Prefieres algo más sencillo para empresas medianas (entre 100 y 500 empleados)?
    Gracias!

  5. Buenos dias Javier:

    Son tantas las metodologias, en este caso estas apuntando a metodologias para desarrollos de Software, que no es igual a las implementaciones de Software, que pueden ser combinaciones de varias metodologias, el Mapa de los Procesos de Negocio generado de varias fuentes como son las historias de usuarios para los procesos internos ERP, MRP y para los procesos externos las estrategias de marqueting definidas poe los directivos para el uso del CRM e Inteligencia de Negocios

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba