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