SAFe una lectura general del Big Picture

Scaled Agile Framework


Hola a tod@s,
Hace poco me he sacado el primero de los certificados de SAFe, el Leading SAFe. Hasta ahora me ha pasado como a la gran mayoría, me mareaba al ver el Big Picture de SAFe y no sabía por donde empezar a leerlo para hacerme una idea general. Para mi esto es importante dado que yo entiendo mejor las cosas tiendo una idea general para después profundizar en cada una de las partes. Así en este artículo voy a intentar explicar de manera general y sin entrar en detalle el Big Picture de SAFe. Tened en cuenta que algunos términos sólo los nombraré y que muchos componentes que aparecen en el Big Picture ni si quiera los mencionaré. Espero que os sirva como primera toma de contacto :D.
SAFe trabaja desde las 5 competencias de una Empresa Lean. Estas competencias son:
  • Lean Portfolio Manager: Si una empresa quiere ser Lean debe tener un conjunto de personas que se encarguen de alinear la estrategia de la empresa a corto, medio y largo plazo con lo que se ejecuta en la empresa. El objetivo es que todos los trabajadores tengan la misma visión de hacia donde se quiere ir.
  • Business Solution and Lean System Engineering: Esta competencia permite desarrollar producto muy muy grandes. Aquí se tratará de alinear y sincronizar a grandes equipos de más de 100 personas cada uno. Es imprescindible alinear y sincronizar a todo el mundo para poder desarrollar un producto, si el producto es muy muy grande será necesario establecer mecanismos que permita, de una manera ligera, sincronizar a tantas personas.
  • DevOps and Realease on Demand: Una empresa Lean debe tener DevOps ya que será la única manera de poder sacar al mercado valor de manera temprana y continuada. Además y con el fin de que negocio esté involucrado en el producto es necesario darles la potestad de decidir cuando cada parte del producto sale a mercado. Me explico, en un desarrollo de software una funcionalidad puede estar instalada, sin embargo, esta no es visible a los clientes hasta que negocio lo indique.
  • Team and Technical Agility: Esta capacidad describe las características que deben tener los equipos y cómo han de trabajar para conseguir equipos de alto rendimiento que sean capaces de desarrollar productos de gran calidad.
  • Lean-Agile Leadership: Esta capacidad define cómo los Líderes Lean-Agile dirigen y sustentan el cambio en la empresa. En última instancia los gestores, líderes y ejecutivos son los que deberán liderar el cambio dado que ellos tienen la capacidad de crear el ambiente necesario para que el cambio se produzca.
Para tratar de facilitar la comprensión de cómo se llega desde la estrategia hasta el producto desarrollado vamos a imaginar una empresa de telefonía. La dirección de la empresa ha decidido que quiere llegar al público joven. A partir de ahí arranca la maquinaria SAFe.
Es necesario empezar a dar pasos para bajar a la tierra la visión de los ejecutivos de la compañía. Para eso el primer paso es elaborar una plantilla estratégica (Strategic Theme). Esta plantilla es elaborada entre los Ejecutivos, los Interesados, los Arquitectos de la compañía y el Lean Portfolio Manager. De la colaboración de estos agentes se obtiene tanto el Strategic Theme como los presupuestos Lean (Lean Budgets)
Una vez lo tenemos podemos empezar a elaborar tableros Canvas (Canvas que no Kanban, no es una errata ;) ). Portfolio Canvas es un Business Model Canvas modificado para que encaje dentro de todo el dibujo de SAFe. Este tablero ayuda a analizar un objetivo estratégico. En él se presentan a partir de un Value Stream (o necesidad a cubrir) elementos como: soluciones a esa necesidad, el segmento de clientes, que canales va a usar el Value Stream para llegar a ellos, el coste y muchos más. Así, será posible analizar si seremos o no competitivos y qué cosas serían necesario llevar a cabo.
Para el ejemplo que he mencionado antes podemos tener varios Value Stream:
  • Hacer accesibles la información a este colectivo:
    • Soluciones:
      • Optimizar las páginas web para dispositivos móviles
      • Crear Apps para móviles
    • ...
  • Hacer accesibles los servicios de la empresa a esos colectivos
    • Soluciones:
      • Crear una operadora Low Cost con servicios limitados
      • Asociar precios al carnet Joven (no sé si sigue existiendo :P)
    • ...
Rellenando todos los campos del Portfolio Canvas tendríamos unos cuadros de tomas de decisiones que nos permitirían trabajar con ellos para separar en nuevas opciones o unirlas hasta llegar a los definitivos. Con esto trabajado llegaremos a definir a un alto nivel lo que se quiere llevar a cabo para conseguir lo marcado a nivel de estrategia.
Las "tareas" de muy alto nivel marcadas se denominan Épicas. Para los que conozcáis Scrum o XP estas Épicas no son iguales a las que se usan en esos métodos ágiles. Estas Épicas están descritas mediante una frase, una hipótesis, un MVP (Minimum Viable Producto, mínimo producto viable) que permita validar la hipótesis y un presupuesto necesario.
Las Épicas (o Epic) se incorporan al Portfolio Kanban, donde se priorizan y se aprueban para ser o no llevadas a cabo. Ya en este nivel se introducen elementos a los que se les denomina Enablers (activadores). Los Enablers son elementos que hay que llevar a cabo para poder implementar otro elemento que si aporte valor por si mismo. Por ejemplo, para poder llevar a cabo la creación de una nueva operadora Low Cost serán necesario realizar algunos temas legales y burocráticos antes de poder configurar los servicios.
Para priorizar las Épicas es necesario conocer su tamaño. ¿Y quién creéis que pueden indicar el tamaño de un trabajo a realizar? Efectivamente las personas que lo van a llevar acabo. Así en algún momento se pedirá a ciertas personas de los equipos finales que evalúen el tamaño de las Épicas. Son elementos muy grandes para evaluar directamente, por ello, necesitarán un trabajo de división a fin de poder evaluar partes más pequeñas que después permita obtener el valor final de la Épica.
La evaluación de tamaños se realiza en base a comparación y siguiendo la serie de Fibonnaci. No se utilizan nunca horas.
Si se aprueba la Épica se envía al siguiente nivel, aquí dependiendo del tamaño se crearán Capabilities o Features. La diferencia entre ambos conceptos es el tamaño de lo que representa. Por ejemplo, crear una nueva operadora posiblemente podría ser una Capability. Sin embargo, hacer la información accesible a los dispositivos móviles podría ser una Feature.
Dado que la capacidad de Business Solutions está pensada para sincronizar grandes soluciones y además todavía no parece que se utilice en España, no voy a comentar más que una de sus funciones. Antes y después de la planificación de los ART (que comento más adelante) realizan una reunión previa para para preparar la planificación y que esta se sincronice entre los ART y una reunión después para evaluar sin finalmente las planificaciones han quedado bien sincronizadas.
El equipo formado por un System Architect/Engineering, Product Manager y RTE (ReleaseTrainer Engineering) trabajarán para transformar las Épicas en Feature junto con los Product Owners. Aquí pueden aparecer nuevos Enablers, de diferente naturaleza y tamaño que el ejemplificado anteriormente. Cada rol aporta su punto de vista de manera que, por un lado la necesidad tiene un análisis de 360º y además todas las partes se comprometerán con la solución final.
El equipo de System Architect definirá los estándares técnicos a seguir, las herramientas a utilizar y preparará los elementos técnicos necesarios para llevar a cabo el trabajo.
El Product Manager y los Products Owner se reunirán con los Business Owners para evaluar la solución en el mercado lo más tempranamente posible. En el caso de la operadora Low cost tendrán que ver que otras operadoras similares hay, que ofrecen, que no ofrecen y qué parece que se está demandando por parte de los clientes potenciales.
Todo este equipo trabaja para que después un ART (Agile Release Train o Tren de Lanzamiento Ágil) pueda implementar la solución de negocio que se ha estudiado que más valor puede aportar al mercado. Las Features se guardan en el ProgramKanban y también son priorizadas. Aquí igual que antes deben ser evaluadas por un equipo de implementación para conocer su tamaño.
En Agile se busca una cadencia que haga previsible un ciclo de entregas constante. La implementación de las Features del Program Kanban se van a realizar durante un Program Increment. Un Program Increment puede tener una longitud de entre 2,5 y 3 meses.
La planificación de un Program Increment se hace en el PI Planning donde los equipos de desarrollo (Dev Team) de un ART o tren se distribuyen el trabajo y lo afinan un poco más junto con su Product Owner. Un ART está formado por entre 50 y 125 personas. El tren está organizado internamente en equipos ágiles de entre 5 y 9 personas además de un Product Owner y un Scrum Master. Los equipos pueden trabajar con Scrum/XP o Kanban.
Una vez se ha establecido lo que cada equipo ágil va a realizar y se han sincronizado dependencias entre ellos y otros agentes externos a ellos pueden empezar a trabajar. Aquí, dependiendo de qué método de trabajo usen se organizarán de una manera u otra.
Sin embargo, si existirán algunos eventos comunes para todos. El primero es el Scrum de Scrum donde los Scrum Master y el RTE verán los avances e impedimentos que surjan. También existe una reunión de sincronización de los Products Owners con el Product Manager donde verán el avance y si se cambian los alcances marcados (generalmente se modificarán el alcance del PI que afectará a los siguientes Iteraciones).
Cada entre 2 o 4 semanas todos los equipos integrarán sus trabajos y realizarán una demo conjunta (System Demo). Este evento sirve para mostrar el avance y además fuerza a una integración temprana que evita grandes problemas de integración futuros.
Como mínimo cada vez que se integre todos los trabajos debemos tener la capacidad de ponerlos en el frente lo antes posible. Sin embargo, aunque estén en el frente deberá ser negocio quien indique cuándo podrá ser accesible por el usuario final cada elemento. De esta manera las personas de negocio se verán implicadas y se comprometerán durante todo el proceso en el producto que se está construyendo.
Además, es imprescindible tomar métricas de todo lo que el usuario hace de manera que se pueda recuperar información de cómo está resultando lo que se ha lanzado al mercado y así poder decidir qué acciones deben llevarse a cabo. Esta información llega directamente al equipo de Lean Portfolio Management. De esta manera el circulo se cierra y se retroalimenta para poder tomar decisiones lo más tempranamente posible en función de lo que el mercado demande.
Espero que este resumen haya quedado más o menos sencillo y sirva para alguien pueda hacerse una idea general de cómo funciona SAFe.

Comentarios

  1. Me encanta el enfoque del artículo, efectivamente es un resumen excelente. Realizar el enfoque desde el flujo de arriba a abajo, desde el tema estratégico a los equipos de desarrollo me parece un acierto.

    Un abrazo y enhorabuena :-)

    ResponderEliminar

Publicar un comentario

Entradas populares