FAST-AGILE con @AgileSpain

Hace pocos días asistí a un fantástico meetup en el que los amigos de Agile Spain nos presentaron el framework de escalado Fast-Agile.

El evento se organizó en el espacio de co-working “Se aceptan ideas”, un sitio que no conocía y que me resultó de lo mas atractivo. Muchas, muchísimas gracias por su colaboración y atención.

A través de este artículo os quiero contar cómo fue el evento y mis percepciones sobre el framework tras la experiencia. Si asististe al evento igual prefieres saltarte la parte en la que cuento lo que hicimos y prefieres ir directamente a mis conclusiones particulares sobre FAST.

Los anfitriones del evento, Joao Barreiro y Daniel Rodríguez, nos indicaron que el objetivo de la reunión era el aprendizaje compartido. Mi particular felicitación para la organización por la puesta en escena de la dinámica y la delicada dedicación. Enhorabuena chicos, así da gusto!!!

FAST está en fase de desarrollo y la comunidad interesada en su definición y evolución requiere del feedback que puedan aportar agilistas conocedores de otros modelos. Por otra parte, los asistentes conoceríamos de cerca el framework a través de una dinámica de resolución de un proyecto aplicando las “reglas” que el propio framework establece.

Comenzamos el evento con un juego muy simpático para romper el hielo entre los asistentes. Me pareció una idea muy buena ya que el juego nos obligaba a emparejarnos varias veces de manera aleatoria y realizar un juego rápido (piedra, papel o tijera), lo cual favorecía permitía hablar con varias personas que no conocías. Por otro lado nos obligaba a hacer un poco el payaso entre juego y juego interpretando un personaje, lo cual permitía desinhibirse. Muy bien por el planteamiento, con el permiso de @danny_rm lo fusilaré de vez en cuando.

DINÁMICA de simulación FAST

La propuesta, a través de la cual íbamos a experimentar la forma de trabajo de Fast-Agile, fue la siguiente:

• Vimos un corto de dibujos animados. Se trata de un capítulo extra de la película infantil “Enredados”. Divertidísimo por cierto…
• Una vez visto había de construir un producto: Un mural que contase la historia del corto, el cuál sería puesto para que los niños lo coloreasen. Los niños que nos acompañaban jugaban el rol de cliente. El mural se debía construir dibujando en grandes hojas de rotafolio.
• @unairoldan jugaba el rol de Product Director, uno de los roles que define FAST y máximo responsable la visión del producto y el Story Map.
• El framework es iterativo e incremental, trataríamos de hacer dos o tres iteraciones.

A priori nada más, lo íbamos a descubrir poco a poco: “learn doing”.

La forma de trabajo en el framework es con un enfoque OST, donde se aprende haciendo, andando, donde no se planifica más allá de lo inmediato, de lo que queremos abordar ahora mismo, y donde el conocimiento se comparte como base fundamental para que las grandes ideas y soluciones fluyan entre los integrantes de los equipos/organizaciones. Bueno, es un resumen tan breve de OST que mejor echa un vistazo al enlace.

Sigo con la sucesión de acontecimientos.

El grupo de asistentes formamos la TRIBU ( tal como lo denomina Fast). Nos reunieron en el FORUM , espacio dedicado a las reuniones de planificación y cierre de las iteraciones, en el que ya estaba preparado un Story Map con todas las historias que el Product Director proponía para construir nuestro producto.

Los anfitriones nos indicaron que nos íbamos a juntar de forma natural en una serie de grupos de trabajo. Para ello si alguien creía que alguna de las historias de usuario contenidas en el mapa era de especial prioridad o valor podía cogerla, explicar el motivo por el cual le daba importancia y esperar a que se unieran otras personas de la Tribu que estuvieran de acuerdo con su propuesta y se comprometiesen a resolver la historia. Esta persona jugaba el rol de STORY STEWARD a partir de ese momento y sólo durante la primera iteración. Los Story Steward podían coger un historia del mapa o proponer una nueva. Se dio el caso que una persona propuso una historia nueva pero al profundizar en ella durante la solicitud de personas para formar un CLAN incluso él mismo dijo, “yo mismo ya no tengo claro que sea necesario”.

El Product Director no indicaba la prioridad de las historias del mapa, podíamos coger la que nos resultase de mas valor o interés. Cada equipo formado se juntó en un Clan para resolver su compromiso. A todo este proceso de selección de historias de usuario y adhesión del resto de personas de la tribu creó recordar que se le llama MARKET PLACE.

FAST no define reuniones directamente, define ESPACIOS en los que se realizan determinadas acciones. En realidad es lo mismo pero con otro enfoque.

El número máximo de Clanes que podíamos formar creo recordar que era de 5.

Tras la creación de los clanes los Story Stewards se reunieron para identificar dependencias entre las historias seleccionadas.

Finalizado el market place, los Clanes se reunieron en sus SALAS DE TRABAJO (cada clan en una) y realizaron una planificación sobre su historia antes de abordar el desarrollo. Finalizado ese momento, se ejecutó lo planificado para disponer del incremento de la iteración.

No todos generamos el producto esperado en todas las iteraciones, algunos equipos generamos incrementos menores dibujados en un folio en vez de en una hoja de rotafolio, esperando feedback sobre su propuesta de solución.

Finalmente la Tribu se reunió en el Forum y mostró sus incrementos a los clientes y al Product Director, quienes decidieron aceptarlos o no. 

Los Story Stewards pierden su rol y todo empieza de nuevo. Market place para seleccionar las historias de interés para la tribu a través de nuevos o repetidos Story Stewards, los integrantes de la tribu pueden cambiar de historia pese a no haberla acabado en la fase anterior, el ciclo se repite y finalmente se termina el producto con las entregas de la segunda iteración.

Después de este juego de simulación FAST los organizadores abrieron un debate dejando fluir la conversación y planteando solo alguna preguntas clave, se pretende detectar qué ha sorprendido a los participantes, tanto por bueno como por malo. Fue un debate realmente interesante.

Por último João nos presentó la teoría de FAST.

MIS CONCLUSIONES

FAST es rápido (obviamente) y ligero para facilitar la eliminación del desperdicio. Es abierto, colaborativo y comprometido para permitir que la creatividad, el conocimiento y el aprendizaje fluyan de forma natural y para obtener el compromiso y la motivación de las personas. Es escalado, para aprovechar la inteligencia colectiva por encima de la individual. Es, ante todo, desarrollo, Code Craftsmanship, para garantizar la calidad intrínseca y la excelencia técnica. Es OST para asegurar la auto-organización, que las decisiones las tomen las personas adecuadas y que las tareas las realicen las interesadas y motivadas. Y es crecimiento emergente para que las soluciones y los productos se construyan en tiempo y forma natural.

Impresionante, ¿verdad?… Lo malo es que su estado de definición es ciertamente prematuro como para poder estructurar una organización en base a su propuesta si previamente no se dispone de otras bien consolidadas capacidades y/o experiencia agile. Es posible que el framework se encuentre en este estado de forma intencionada, no por facilitar el crecimiento en base al feedback que reporten las comunidades interesadas, sino más bien por pretender que esta sea su naturaleza para que la implementación del mismo sea interpretable a necesidad. En este caso me voy a permitir decir que lo percibo más como una declaración de intenciones, una disposición cultural-organizativa, que como un framework. No es crítica destructiva, confieso que me ha resultado realmente interesante y he aprendido mucho, tanto con el evento, como con la propuesta de FAST.

El framework está tremendamente enfocado en el desarrollo, hasta el punto de que los integrantes de la Tribu se denominan DEVELOPERS. Esta es la principal característica de FAST, el foco en el desarrollo, en la excelencia, en la calidad, en el diseño emergente… pero ¿y el producto?

FAST atribuye la visión del producto al Product Director y determina que el mapa de historias se crea con historias ciertamente abstractas. Tiene sentido, si se quiere ser ligero y rápido no interesa profundizar en lo que no se va a trabajar de forma inmediata.

En ningún momento se define cómo debe crecer el producto, FAST lo deja en manos de la Tribu ya que el producto crece en base a la selección de las historias. Muy asambleario, pero no por ello más óptimo ya que el equipo de desarrollo no es experto en el qué, más bien en el cómo. Esto puede funcionar en el caso que se desee generar un producto muy disruptivo e innovador buscando un Océano Azul. Pero incluso en ese caso parece de mucho interés disponer de roles de negocio dentro de los Clanes. FAST ubica el negocio fuera de la Tribu, determinando que el Product Director es el responsable de la visión del producto y que los Stakeholders no pertenecen a la Tribu. Aquí observo una incongruencia importante, la VISION en FAST es, según su web…

“Harmony between business and development”

El framework especifica que los integrantes de la Tribu deben tener habilidades similares a los equipos de desarrollo en Scrum, a modo de T-Shaped People, Este tipo de trabajadores aúnan habilidades verticales (de gran profundidad técnica sobre una materia particular) y habilidades horizontales (trasversales a la organización: gestión, creatividad, organización, comunicación, etc). Es posible que FAST determine que una de las habilidades horizontales sea el conocimiento del negocio, pero ni lo especifica, ni quizá sea lo que facilite ese “surgir emergente” que le caracteriza. En definitiva, veo de mucho interés que se incluyan roles de negocio en los Clanes.

FAST no especifica en qué tipos de escalado se puede aplicar. Estamos hablando de un framework que puede llegar a trabajar con varios productos relacionados y Tribus de hasta 150 integrantes (Número Dunbar).

Veamos tipos de escalado y cómo puede resultar FAST en cada uno de ellos:

• Un mega-producto, varios equipos. En este caso los distintos Clanes (equipos) trabajan contra el mismo producto. El único problema puede ser que el Product Director se cargue de trabajo ante situaciones de productos muy grandes con Tribus grandes.
• Un mega-producto, un equipo. Es lo mismo que antes desde el punto de vista de FAST.
• Varios productos, varios equipos. Varios Clanes (equipos) trabajando sobre varios productos relacionados o no. El caso abre la posibilidad, no planteada por FAST, de introducir más de un Product Director.
• Varios productos, un equipo. Es lo mismo que antes desde el punto de vista de FAST.

No sé si me dejo algo de interés, pero parece que puede encajar en cualquiera de la opciones de escalado.

MIS PROPUESTAS

• Más de un Product Director. Uno único se me antoja tremendamente escaso. Personalmente abriría el framework a la posibilidad de más de uno, que en caso de varios productos en desarrollo permite repartir la carga de trabajo.
• Añadir roles de negocio a los Clanes. Sigo viendo que FAST desliga Negocio y Desarrollo pese a significase como lo contrario. Una buena solución podría ser que no se pueda formar un Clan si no tiene, al menos, un rol de Negocio (stakeholder) interesado en unirse.
• Equipos ágiles experimentados en busca de productos disruptivos o experimentales. La idea de FAST es buena para emerger productos inesperados. Ciertamente arriesgado pero de mucho interés cuando se buscan “Océanos azules” en mercados saturados.
• Un modelo de auto-organización más que un framework de escalado. Personalmente le veo más futuro como modelo de auto-organización del Equipo de Desarrollo para equipos Scrum que requieran más miembros de lo habitual.
• Introduciría el concepto de “Llamamiento” en el market place, mediante el cual, un Clan recién formado expone el motivo por el cual cree que determinada persona debe unirse al Clan para construir al mejor incremento posible para su historia.

Gracias por leer el artículo, si te ha gustado comparte.

Saludos.

Óscar R. Onrubia