La relación entre el modelo de fluidez ágil y las topologías de equipos
Tenemos dos modelos muy populares en el contexto de la agilidad de desarrollo de producto digital: el modelo de fluidez ágil (AFM) de Diana Larsen y James Shore, y las topologías de equipos de Manuel País y Matthew Skelton. Hace poco hablábamos en la comunidad de AFM de la relación entre ambos, y salieron algunas ideas interesantes.
No encaja una comparativa como tal entre ambos, pues son modelos de naturaleza diferente, y por tanto ven los equipos desde perspectivas diferentes. Veremos qué relación puede existir entre ellos.
Hagamos un repaso muy rápido de ambos:
El modelo de fluidez ágil.
El modelo de fluidez ágil representa cómo los equipos siguen una progresión típica en su entendimiento de los métodos ágiles y los beneficios que recibe la organización. Personalmente me convenció (aparte de la solidez intelectual demostrada por sus autores) porque se centra en los beneficios esperados de la agilidad. No es un modelo de prácticas, un listado/checklist de prácticas que tienes que ir avanzado para seguir al siguiente nivel. Cuando prometemos que la agilidad va a solucionar algún problema (nota: ¡no lo hagas!) debemos ver BENEFICIOS de su implantación.
El modelo presenta 4 zonas por las que evolucionan los equipos:
- Focalizando, requiere un equipo que aprenda a trabajar junto para focalizarse en crear valor de negocio en vez de simplemente finalizar tareas técnicas. Se obtiene visión sobre el equipo del trabajo, transparencia, y tendrá más oportunidades para influencia el trabajo en direcciones positivas. Esta zona refleja lo básico de Agile.
- Entregando, requiere que un equipo invierta en aprender una serie de habilidades en el desarrollo de software. Esta zona refleja la sostenibilidad Agile. Las habilidades no se obtienen fácilmente, pero con tiempo y el adecuado apoyo organizacional, el equipo obtiene la habilidad de crear y lanzar software con una baja tasa de errores tan pronto como el mercado lo acepte, lo que proporciona a la organización nuevas oportunidades para lograr retorno de la inversión en su desarrollo software.
- Optimizando, representa la promesa de Agile: un equipo que baila y se mueve al son de las condiciones cambiantes del mercado, y toma responsabilidad compartida para construir el mejor producto que la inversión pueda comprar. Conseguir la fluidez en esta zona significa que los expertos del negocio deben unirse a los equipos como participantes a tiempo completo, y mientras que este cambio de la estructura organizativa puede ser un reto, es beneficioso mejorando la habilidad de tus equipos para servir al negocio.
- Fortaleciendo, representa el futuro de Agile. (no tratada por los autores en su diagnóstico)
Estas zonas no son secuenciales, y pueden ser independientes en su logro, si bien, la observación de los autores (que comparto), es que es el camino más habitual.
Topologías de equipos
Las topologías de equipos representan la situación de un equipo respecto a su cadena de valor:
Las cuatro topologías de equipos:
- Equipos focalizados en una cadena de valor, capaces de entregar a cliente/usuario lo más independientemente posible.
- Equipos de soporte, ayudan a otros equipos a cubrir una necesidad (tecnológica o de dominio) para aumentar su autonomía.
- Equipos de subsistemas complejos, responsables de construir y mantener parte del sistema que requiere habilidades o conocimiento especiales.
- Equipos de plataforma.
Y no solo habla de las topologías de los equipos, si no de sus interacciones: X-as-a-service, colaboración y facilitación.
Ninguno de los dos modelos definen una situación para los equipos ideal, si no que dan herramientas para identificar su situación, y trabajar en su desarrollo hacia un lugar más efectivo o eficiente en nuestro contexto. Las topologías desde el diseño organizativo de los equipos (composición y relaciones) y AFM desde el nivel de capacidad del equipo para una entrega continua, adaptable y de calidad (vamos a decir, "ágil").
Entonces, ¿Hay una relación entre zonas del modelo de fluidez ágil y la tipología del equipo?
Si tenemos diferentes tipologías de equipos, y diferentes zonas de fluidez ágil en las que se puede encontrar cada uno de ellos, ¿existe zonas más apropiadas según la tipología? ¿requieren diferentes tipologías de diferentes capacidades o habilidades a conseguir?
Mi primera idea es que el modelo de fluidez y las tipologías son ortogonales. Por un lado hablamos del objetivo o lugar del equipo dentro de la cadena de valor, y por otro de las habilidades conseguidas de este equipo respecto a su capacidad y nivel de entrega.
Ambas hablan obviamente de una aproximación organizacional por equipos. Sin que la organización decida trabajar por equipos es difícil empezar a obtener los beneficios esperados de la agilidad. Hay una necesidad del salto indicado para la primera zona, FOCALIZANDO. Obviamente, antes de esta zona ni siquiera hay conciencia de equipos en una organización, por lo que no tendremos probablemente ni un planteamiento de topologías de los mismos.
Parece trivial decirlo, pero aún hay muchas organizaciones que no han dado el salto, y o no lo creen o no lo es necesario para su modelo de negocio.
Parece trivial decirlo, pero aún hay muchas organizaciones que no han dado el salto, y o no lo creen o no lo es necesario para su modelo de negocio.
Por tanto, sea cual sea la topología de equipo, necesita de la zona FOCALIZANDO para poder entregar con transparencia, y conseguir un mínimo de adaptabilidad y trabajo priorizado por valor en unidades significativas para el negocio. Significa al menos hacer la inversión para crear equipos reales, lograr mecanismos de trabajo transparentes, y un proceso de mejora continua. Diana y James lo declaran como el beneficio básico de Agile.
¿Qué sucede con el resto de zonas?
- Los equipos de entrega en la cadena de valor, se beneficiarán de la zona ENTREGANDO especialmente si sus productos van a ser sostenidos en el tiempo, donde necesitan mantener bajo control la deuda técnica y altos estándares de calidad interna. Se beneficiarán de la zona OPTIMIZANDO si necesitan actuar rápido en el mercado, experimentar con opciones, y liderar su mercado objetivo.
Estos equipos son los que más se beneficiarán de la zona OPTIMIZANDO pues es dónde se trabaja la respuesta adecuada al mercado y su adaptabilidad al negocio.
Estos equipos son los que más se beneficiarán de la zona OPTIMIZANDO pues es dónde se trabaja la respuesta adecuada al mercado y su adaptabilidad al negocio.
- Los equipos de plataforma los situo en una zona ENTREGANDO como zona necesaria. Si una organización está creando plataformas para dar servicio al resto de equipos, la calidad del producto, su capacidad de entrega continua, debe estar siempre por encima de los equipos a los que da servicio o se crearía un cuello de botella artificial. La zona OPTIMIZANDO probablemente es menos necesaria, pues su gestión de requerimientos no está en contacto directo con el mercado.
- Los equipos de soporte necesitan trabajar al menos al mismo nivel técnico en la zona ENTREGANDO que a aquellos equipos a los que sirven. Imagino que muchas veces tendrán la responsabilidad de elevar el nivel en esta zona misma a los equipos a los que ayudan.
- Los equipos de sistemas complejos deben maximizar los resultados deben decidir cuál es la inversión necesaria para dar el mejor servicio al resto de equipos.
Si las representamos sería algo así:
Este podría ser un mapa objetivo, pero podríamos tener un mapa de los equipos de la organización, incluyendo la zona actual y la zona deseada. Cada zona puede tener diferente grado de consecución, y podremos observar patrones de necesidades por tipo de equipo.
¿Y si las relacionamos a través de un mapa?
Creo que lo interesante de estos modelos no es analizarlos en un marco teórico, si no en su contexto y evolución en las organizaciones. Ambos hablan de la evolución de los equipos, uno desde la estructura organizacional y otro desde las habilidades y capacidades de los equipos. Ni una cosa ni la otra son estáticas en una organización de desarrollo de software, y se tienen que ir adaptando a las necesidades como pueden ser de crecimiento o escalabilidad o las del mercado cambiante.
Y para hablar de modelos en evolución, podría ser interesante traer los mapas de Wardley. Muy básicamente, en ellos situamos nuestros elementos en dos ejes: su posición en la cadena de valor, y en la evolución del producto.
ANEXO: Las tipologías que nos encontramos.
Lamentablemente, estas son algunas de las topologías disfuncionales de equipos que nos encontramos en muchas organizaciones de desarrollo de producto:
- Equipo de "llego hasta dónde puedo y paso la pelota al siguiente": Los equipos front-end y back-end, los equipos con múltiples dependencias para cualquier funcionalidad...
- Equipo de "comunicación": Como, por ejemplo, el equipo de front y el de back se llevan mal y no se entienden, establecemos un canal de comunicación que define y despliega servicios entre ambos, y por tanto una plataforma más, claro. Si lo piensas en clave de la Ley de Conway, es terrible.
- Equipo de despliegue: Un equipo para hacer los pases a entornos de Producción. Dado un word y un código fuente, tenemos un despliegue exitoso en PRO.
- Equipo de "recursos": Cuándo el equipo ni sabe qué personas tiene esa semana, ni cuánto pueden dedicar a trabajar juntos.
Seguir investigando
La idea de las topologías de equipos según la situación en el mapa de Wardley y su identificación de la zona de fluidez necesaria es un trabajo en progreso. Creo que puede dar mucha información para facilitar las conversaciones alrededor de la evolución de una organización, pero quizás está un poco sobrecargado. ¡Si tienes alguna idea, no dejes de escribirla en los comentarios!
Inspiring you
jmbeas dice:
Hola Joserra, qué interesante artículo. Por un lado me ha aclarado bastante cómo entender el Agile Fluency Model (AFM) y por otro me ha intrigado tu propuesta de conectarlo con Team Topologies y Wardley Maps. Me gustaría continuar la conversación con una nota acerca de las zonas del AFM y los Wardley Maps, a ver qué te parece.
Para empezar, me gustaría aclarar cómo visualizo yo el Wardley Map. Para mí, los componentes que yo visualizaría ahí serían diferentes prácticas en las que la organización (individuos y equipos) tiene diferentes niveles de desempeño. Además, para este caso prefiero ver el eje de evolución (el horizontal) con los siguientes valores: «Novel», «Emerging», «Good» y «Best». P.ej. si ponemos el foco en un equipo en concreto, quizás su desempeño en cuanto a integración continua sea de «Best practice» (porque lo tienen perfectamente asumido e integrado en su flujo de trabajo), pero de TDD sea de «Novel» (porque están empezando a hacer algunos pinitos).
Me llama mucho la atención que sitúes las zonas del AFM en el eje vertical del mapa porque yo la veo más bien en el eje horizontal. Para mí, a medida que vamos avanzando de una zona a otra, también vamos aumentando el nivel de estandarización en los procesos, por lo que creo que hay una relación bastante directa entre «Focalizando» y el paso de «Genesis/Novel practice» a «Custom/Emerging practice», «Entregando» y el paso de «Custom/Emerging» a «Product/Good», y «Optimizando» y el paso de «Product/Good» a «Commodity/Best».
Por otro lado, interpreto que la disposición de las zonas que haces en vertical quiere expresar que en la zona «Focalizando» nos centramos en aspectos más internos y en la zona «Optimizando» en aspectos más cercanos a los clientes. ¿Es así? En ese caso, también estoy de acuerdo contigo, con lo que quizás estemos hablando de algo más parecido a una distribución en diagonal.
No sé, ¿cómo lo ves tú?
Un abrazo
JMB
Joserra Díaz dice:
¡Gracias por esas ideas!
En el Wardley Map no sitúo las prácticas de los equipos (sería otra perspectiva), si no el componente/producto software en el que estén trabajando (visto desde el punto de la cadena de valor). Entonces, según su topología de equipo, y su situación en la evolución de ese componente, es cuándo me pregunto que prácticas (zonas del modelo de fluidez) les serían más útiles. O sea, le estoy dando la vuelta a cómo lo visualizas tú.
Creo que las dos maneras de visualizarlo pueden revelar información valiosa para un buen diseño organizacional. Yo lo planteaba desde la situción de los equipos, y entonces conversar sobre cuál es la zona del modelo que les podría interesar a cada equipo según su situación.
Estableciendo «Focalizando» en todas las áreas quiero decir que es básico.
La distribución creciente de «Entregando» quiere decir que quizás en un entorno de genesis no vas a preocuparte de todas las prácticas de calidad, pero conforme el producto madura, necesitarás trabajar más para asegurar la escalabilidad.
Y la zona «Optimizando», los beneficios de las mejores decisiones de producto, serán vitales en esos momentos en los que tras validar una idea la quieres hacer crecer. Es obviamente una feliz suposición que con un producto consolidado puedes dedicarte un poco más a «ordeñar la vaca» que a crear grandes innovaciones.
Ponemos diferentes perspectivas en el mapa y salen diferentes conclusiones 🙂