SAFe 4.5 un marco ágil y lean hasta la médula

Existen dos términos en inglés que nos dan la pista sobre la clave de como ser una compañía lean-agile.

  • Output: la salida producida.
  • Outcome: el resultado producido en términos de beneficio o de resolución de problemas.

En la gestión clásica de proyectos ponemos el foco en la construcción de outputs. Lo hacemos en forma de funcionalidades, nos basamos en un input a base de una lista de requerimientos que llamamos alcance, y a lo largo del proyecto construimos un paquete grande de funcionalidades que cubre esos requerimientos, y lo hacemos de forma optimizada para el paquete completo.

En cambio en agile y lean el foco está en producir outcomes, en construir soluciones a problemas de negocio para hacer una compañía competitiva y que obtenga beneficios de forma sostenida.

Encontraremos ambos términos en cada uno de los sprints en Scrum, cuando obtenemos la pila de sprint y el objetivo del sprint en la planificación del mismo. La pila de sprint es el output y el objetivo el outcome, no importa tanto si las historias de usuario entregadas corresponden a lo que se planificó, lo que importa es que las historias entregadas sean la mejor solución para el negocio. El objetivo guiará al equipo a lo largo del sprint en base a la necesidad o problema a solucionar.

Si miramos el marco de SAFe podernos observar que a nivel de los equipos se construye con iteraciones guiadas por objetivos (goals), tal como marca Scrum. Cuando escalamos se hace patente la grandeza del marco, tenemos pilas de elementos a diferentes niveles que priorizadas por valor de negocio (realmente WSJF) llevan las intenciones estratégicas a los equipos, que estos cocinan y así obtienen los objetivos que escalan al equipo de equipos (Agile Release Train) en forma de objetivos agregados (PI Objectives). Estos son un plan factible de entrega de valor para las mejores soluciones a los problemas de negocio.

La realidad, los verdaderos outcomes se producen al final de los PI, PIs guiados por los objetivos y la Continuous Delivery Pipeline. Recordemos que no todo puede saberse al principio, una buena solución se descubre y redefine a lo largo del camino, mediante exploración continua para despejar incertidumbre, puntos de integración y aprendizaje continuos que mejoran de forma iterativa el producto, y el despliegue continuo que permite validar asunciones y conseguir la mejor solución posible.

En gestión clásica podemos construir por ejemplo 45 funcionalidades y en un proyecto agile 22, en la gestión clásica quizá se hayan dado solución a 2 problemas de negocio (outcomes) con esos 45 outputs, en agile 10 soluciones con esos 22 outputs… esa es la verdadera esencia de agile y lean.