Esta es un hipótesis de como debemos plantear y armar un ART (Tren) en SAFe.
Antes de entrar en el asunto, debemos de entender, que lo que buscamos es adelantar el retorno de inversión, encontrando el máximo valor en el menor tiempo o con el menor esfuerzo y priorizarlo, para eso usaremos la siguiente figura, que representa 2 tipos de abordajes:
Esta imagen habla por sí sola, si quieres obtener retorno lo antes posible, debemos de optar por el abordaje número 2. esto implica que la forma en que planteamos el desarrollo de las Unidades de Trabajo (Historias, Feature o Epics) deben tener orientación al foco de las Unidades de Trabajo prioritarias y hacerlas de forma serial (monotask) y no en paralelo (multitask).
Esta misma lógica aplica para cualquier Unidad de Trabajo como las Historias de Usuario en un Equipo Ágil, veamos como se verían en un Burndown Chart, ver la siguiente figura:
*En la alternativa 1, se corre mucho riesgo al no terminar ninguna Historia de Usuario y no entregar ningún valor al finalizar el Sprint.
Ahora como se vería con un grupo de Equipos Agiles, montados en una organización virtual, llamada ART (Tren) que atienden Epics:
Una vez que hemos entendido la lógica y el valor de trabajar en serial o monotask, el objetivo es alinear y crear los ARTs (trenes) para que se enfoquen en trabajar de esta forma y en el siguiente gráfico mostramos, cual debería ser una estructura básica para armar un ART para cumplir con la hipotesis expuesta.
Cabe aclarar que la única forma de no poder trabajar en serie (monotask), y se tenga que trabajar en paralelo (multitask), es porque hay dependencia entre las unidades de trabajo o restricciones que imposibilita hacerlo, pero tal vez el problema fue como se conceptualizaron estas Unidades de Trabajo (Historias de Usuario, Feature o Epic) que genera esa dependencia.
Para esto hay que entender que el tamaño recomendado de un ART es de entre 50 a 125 personas, siguiendo el número de Dunbar, y debe de estar compuesta por Equipos Agiles con todas las competencias necesarias para poder entregar (Feature) valor, sin depender de otros ART, para cubrir dichas necesidades (esto también implica dedicación de los Equipos con el ART).
Para poder cumplir esto, es importante crear equipos ágiles transversales a la organización, y esto se necesita cuando estas personas, no pueden estar dedicados dentro de los ART.
Aquellos equipos transversales son:
System Team: Áreas de Operaciones o Sistemas, que trabajan en infraestructura y utilizan muchas practicas ágiles como DevOps.
Shared Services: Aquellos servicios o roles que se necesitan compartir entre los ARTs, como los ambientes de pruebas.
y los Roles dedicados del ART son:
RTE: El Release Train Engineer, en resumen es el Scrum Master de todo el ART, y se apoya en los Scrum Master de los Equipos Ágiles.
Product Management: En resumen es el Product Owner de todo el ART, y se apoya en los Product Owner de los Equipos Ágiles.
System Architect/Engineering: Equipo de Apoyo, que ayuda a planificar y ejecutar los entregables del ART, con competencias técnicas como de Arquitectura o Ingeniería, para algunas empresas, son el área de TI.
Equipos Ágiles: Equipos Scrum, XP y Kanban.
Y eso es todo 🙂 de seguro quedaron muchas dudas, pues usemos los comentarios de este blog.
En este post agradezco a Eric Adames, el mejor consultor de SAFe que he conocido y que me ayuda mucho con su feedback y reflexiones, gracias Maestro.
Clic en la imagen para mas información de los próximos cursos de SAFe Agilist ===>>>
