Marco SAFe de escalado ágil corporativo

Qué es SAFe (Scaled Agile Framework)

SAFe es el marco de escalado ágil corporativo más conocido. Este marco nos hace entender que agilizar toda una corporación va mucho más allá que simplemente incorporar metodologías ágiles a la gestión de proyectos, por ejemplo.

La aplicación de este marco en una empresa debería ser un punto final en la agilización a nivel corporativo, no un punto de comienzo. Es decir, los profesionales ya deben conocer en qué consiste una metodología como scrum, Kanban o Design thinking, un enfoque como Lean, y roles como facilitadores ágiles, product owners, así como reuniones de demo, retro, y desde luego en qué consiste el trabajo en iteraciones que van buscando la producción y entrega de productos mínimos viables que generen valor de negocio real y tangible.

Una vez que tenemos claro todo esto, y se está aplicando con éxito en la gestión de proyectos y servicios, nos planteamos que esta idea de entregar valor a clientes de forma tangible y frecuente debería ser el driver para el funcionamiento del día a día de la empresa como conjunto.

El trabajo de escalado corporativo comienza con un primer paso de simple escalado de las metodologías ágiles como scrum, es decir, llevar a cabo trabajos de cierta envergadura gestionando en paralelo la producción de múltiples equipos cuyas integraciones son las que producen los productos mínimos viables. Esto ya implica que, por ejemplo, somos capaces de llevar en paralelo el trabajo de cincuenta o sesenta personas dentro de un contrato de alto importe, trabajando en paralelo con un roadmap de cada uno de los equipos de trabajo dentro de ese contrato, por ejemplo, seis equipos de 10 personas.

Supongamos que a este primer grupo le llamamos “grupo de trabajo de arquitectura de sistemas”.

Y al mismo tiempo, dentro de nuestra empresa tenemos a treinta profesionales del área de seguridad de datos que también están trabajando en paralelo y generando productos de valor añadido en esta área. Estos 30 profesionales estarán organizados en tres equipos ágiles de diez personas cada uno, por ejemplo.
Y el último lugar vamos a suponer que tenemos un grupo de otras cincuenta personas que trabajan en desarrollo de software, que también estarán organizados a su vez en cinco equipos ágiles que trabajan en paralelo con todas las tecnologías al respecto de esta área.

Lo que hace cada una de estas tres áreas de trabajo importa a las otras dos, porque existen impactos y dependencias mutuas que deben ser coordinadas y gestionadas.

Pues bien: a la unión de estas tres áreas de trabajo funcionando en paralelo y al mismo ritmo de producción de productos mínimos viables que integran todo el trabajo, le llamamos “tren de trabajo”, o como le llama SAFe de una forma más académica, “tren de entrega ágil” (agile release train, o más brevemente ART).

La puesta en funcionamiento de estos ARTs es lo que denominamos el nivel esencial de SAFe, es decir, un paso más allá del simple escalado de metodologías ágiles para hacer un proyecto más o menos grande.

Así que cualquier empresa que quiere introducirse en la aplicación de este marco debe diseñar y poner en marcha estos ARTs. Lo que no está definido dentro del marco es cuántos ni cuáles son cada uno de estos trenes, eso depende de a qué se dedique la empresa. Por ejemplo, podríamos tener el tren de desarrollo de software, el tren de arquitecturas de trabajo masivo con datos, el tren de seguridad de la información, el de sistemas, el de blockchain, el de calidad del dato, etc.

Y esta idea es recursiva, es decir, una gran empresa podría tener diferentes trenes de trabajo sólo para desarrollo de software, cada uno de ellos con un gran grupo de profesionales dedicados a una tecnología en particular.

Independientemente del número de trenes y por tanto del número de profesionales incluidos en estos trenes, a este nivel estamos tratando con la versión denominada “Essential” de SAFe.

Lo más interesante llega ahora: ¿a qué podemos aplicar estos ARTs? SAFe propone dos caminos:

• Dar respuesta a un gran proyecto, es a decir un gran contrato, tan grande que va más allá del simple escalado de una metodología ágil y necesita de la implementación de estos ARTs. Es la versión “Large Solution” de SAFe.

• Dar respuesta a un portfolio variado de negocio que necesita integrar productos y conocimiento de muchas áreas de trabajo que funcionen en paralelo. Es lo que necesitamos cuando nuestra empresa puede estructurarse en trenes que siempre permanecen en funcionamiento (seguridad del dato, analítica, desarrollo de software, etc.) pero que deben ir aplicándose en diferentes clientes y contratos que no exigen cada uno la asignación full time de todos los profesionales disponibles en cada uno de ellos, pero que en conjunto sí que suponen la necesidad de un grupo de profesionales mucho más grande de lo que pueda ser un simple equipo ágil.

Personalmente, creo que este segundo caso es el habitual de cualquier empresa de tamaño medio o grande, siendo a veces necesario además poner en marcha una respuesta a una gran solución (large solution). Es decir, estos dos caminos son compatibles entre sí: podemos estar aplicando SAFe para una gran solución en una parte de la empresa que comprende 100 o 150 profesionales, y podemos estar aplicando SAFe para la gestión de un portfolio que incluye el trabajo de 200 profesionales diferentes dentro de la misma empresa. Elegir estas aplicaciones es precisamente en lo que consiste un proyecto de implantación de SAFe en la compañía.

Eso sí, se está dando por sentado que todos y cada uno de los profesionales conocen el enfoque ágil, sus principios, sus valores, el sentido del trabajo en iteraciones y demás.

¿En qué consiste el nivel más avanzado de SAFe denominado “full SAFe”? Ni más ni menos que integrar a todos los profesionales dentro de alguno de los ARTs que a su vez están dentro de una gran solución o bien de la gestión ágil de todo un portfolio.

Esto implica que toda la empresa funciona en base a ARTs que se coordinan entre ellos y generan productos mínimos viables y entregas de valor, se refieran al contrato y al cliente que se refieran: hemos llegado ni más ni menos que a una empresa ágil como corporación, con todo lo que ello implica en cuanto a estructura y funcionamiento interno y con todo lo que ello implica en cuanto a entrega de valor hacia los clientes.

Principios de SAFe

Los principios básicos de este marco no son ni más ni menos que los principios del enfoque ágil de trabajo, pero siempre teniendo en mente que estamos hablando de aplicarlo a una empresa entera, no simplemente a un equipo de trabajo de 8, 10, ó 12 personas.

Por ejemplo si un principio básico es la comunicación abierta y transparente, su aplicación ya no consiste simplemente en que un equipo haga un radiador de información en una reunión de retrospectiva al final de una iteración, sino en pensar cómo la empresa puede ir recogiendo información para la mejora continua cada corto periodo de tiempo, y extender el uso de esta idea a toda la empresa: por ejemplo, que todos los equipos ágiles de todos los trenes de trabajo de todas la grandes soluciones (y de todo el portfolio) tengan las mismas dimensiones de análisis en un radar, al final de cada iteración. La idea es poder aprender como empresa lo que ocupa y preocupa a los profesionales que trabajan en la misma, desde un punto de vista global. Con esta información se deberían elegir herramientas para el trabajo diario como IDEs de desarrollo, frameworks, ajustes en metodologías, etc.

La palabra clave sería la “institucionalización” de estos principios y prácticas; pensando concretamente en SAFe y alejándonos de lo meramente académico, el valor ágil de “entregar producto funcionando, mejor que documentación exhaustiva” es especialmente importante, puesto que los ARTs son precisamente una forma de funcionar que busca asegurar entregas de producto cada corto período de tiempo, aunque sean iniciativas (contratos) de gran tamaño. Aquí lo importante es que “producto” no tiene por qué significar “producto final en manos de un usuario que lo pueda utilizar”, sino versiones intermedias que la empresa va enriqueciendo, incluso prototipos (esto sería literalmente así en un ART que, por ejemplo, se dedique a explorar las posibilidades de blockchain, para incluirlo como aporte de valor en ofertas y proyectos futuros).

Pasos para conseguir agilizar la empresa

Ojalá existiera una “receta” tal que, si la seguimos, podemos conseguir agilizar una empresa… esto no existe siquiera para aplicar un método sencillo como scrum a un proyecto; pero, al menos, sí es cierto que tenemos que seguir unos pasos mínimos. La duración y envergadura de cada uno es lo que cada empresa debe determinar:

1. Conocer el enfoque ágil: los participantes necesitan formación en todo lo relativo al enfoque ágil del trabajo (estimación y planificación progresiva, trabajo en iteraciones, etc., además de compartir la cultura y los principios ágiles).

2. Aplicar metodologías ágiles: debemos empezar por lo pequeño, es decir, porque todos los proyectos se gestionen con alguna variante de scrum, kanban, lean, XP o mejor aún una combinación de todas ellas. También los servicios (ITIL 4 también se aplica bajo un enfoque ágil).

3. Escalar una metodología ágil a un gran proyecto (gran contrato). Aplicar scrum o kanban en cada proyecto no significa que la empresa sea ágil, pero un primer paso es escalar el método a algo más grande que un equipo de 6, 8 ó 10 personas. Se trata de tomar soltura en la coordinación de 4, 5 ó 6 equipos ágiles, la integración del roadmap de cada equipo para generar un entregable integrado, las aprobaciones de dicha integración por parte de un product owner “proxy”, etc. De momento, sin preocuparnos de montar un ART, simplemente de llevar a cabo alguna iniciativa de mayor tamaño a lo habitual en base a generar productos mínimos y entregas coordinadas entre diferentes equipos.

4. No ser simplemente académico: es fundamental no tratar de utilizar los manuales teóricos de metodologías, ni tampoco el de SAFe, como la respuesta a los problemas de cada empresa. Se trata de determinar por dónde empezar, y hacerlo sin pensar en “cuándo llegaremos a ser completamente ágiles” o “cuándo cumpliremos con todos los niveles de SAFe”; estas cuestiones son irrelevantes en la práctica, puesto que SAFe es una herramienta, un camino, para hacernos mejorar en cuanto a la orientación del trabajo hacia iteraciones y la coordinación de éstas entre distintas iniciativas. No es un objetivo “cumplir con la propuesta de SAFe”, sino mininizar los desperdicios a nivel corporativo consiguiendo que todo el trabajo de todos los profesionales esté en algún ART que genere valor.

5. Diseñar y poner en marcha el primer ART: ¿Qué línea de trabajo, de cierta envergadura, queremos ordenar en primer lugar? Por ejemplo, que todos los profesionales de desarrollo de software se incorporen a algún roadmap de trabajo, y que el ritmo de esos roadmaps sea el mismo. Poner en marcha el ART no quiere decir simplemente probarlo durante una semana, sino confirmar que, durante 8, 9 o 10 iteraciones (al menos) efectivamente cada grupo dentro del tren hace un delivery al mismo ritmo (p.ej. 1 vez a la semana, una vez cada dos semanas, o como mucho una vez al mes) y coordinado con los demás.

6. Diseñar y poner en marcha nuevos ARTs: repetir la idea anterior a nuevas líneas de trabajo. Un consejo: el orden de incorporación podría basarse en lo que actualmente se hace peor, es decir, conformar los primeros ARTs con las líneas de trabajo que estén fallando más en las entregas, que no las realicen, o que se encuentren más descoordinadas; así obtendremos buenas ganancias desde el inicio (y si nos falla la idea, no estaremos deshaciendo valor que actualmente sí estaríamos resolviendo bien). Los últimos ARTs en incorporarse deberían ser los más sencillos.

7. Aplicar a todos los contratos: expandir la idea anterior a “todo”, es decir, plantearse si queda algo que aún no forme parte de un ritmo de entrega constante, e incorporarlo a algún tren ya existente, o crear uno nuevo.

8. Incorporar herramientas de ayuda a la gestión: existen muchas en el mercado; personalmente ha sido muy buena la experiencia con TargetProcess, muy bien estructurada para dar entrada a los ARTs.

9. ¡¡Hacer que todo esto sea un proyecto ágil en sí mismo!! Los pasos anteriores, que podríamos denominar “Proyecto de implantación de SAFe…” tienen que ser un proyecto ágil que sea, precisamente, un ejemplo a seguir: cada paso anterior puede (debe ser) un producto mínimo viable del proceso, así como la incorporación de cada nuevo ART. En este sentido, una carrera profesional muy interesante actualmente consiste en especializarse en esta implantación, como podrás hacer realizando la carrera de experto en metodologías ágiles de OpenWebinars.

10. Métricas, métricas y métricas… Todo esto es un proceso de cambio amplio que debe basarse en métricas: agilizar una empresa debe ayudar a ésta a madurar, también, como data driven company. De hecho, una data driven company debe entenderse como una empresa ágil dirigida por el dato, y SAFe se postula como el mejor marco de referencia para conseguirlo.