El crecimiento de un Producto generalmente conlleva un aumento en la cantidad de personal. Nos encontramos organizando un primer squad y luego tenemos que crear un segundo, luego un quinto, un décimo y así sucesivamente. Las dificultades comienzan a surgir a partir de los dos equipos, aunque en esta etapa se pueden resolver relativamente rápido. Pero cada paso o cambio en la organización puede dar lugar a nuevos problemas o amplificar los problemas existentes.
Entre la falta de visión, las dependencias técnicas u organizativas y los solapamientos involuntarios, los squads se encuentran teniendo que lidiar con situaciones que los ralentizan y hacen que su día a día sea desagradable. Como resultado, el Time to Market se alarga, la previsibilidad disminuye, los equipos se desaniman y, en el peor de los casos, la calidad de su Producto se deteriora.
En este artículo, te ofreceremos sugerencias para todos los tipos de dependencias que puede encontrar.
1.1 Gestión de dependencias y alineamientos entre squads de Producto
Dependencias y alineamientos en una organización vertical
Una organización vertical no resolverá mágicamente la coordinación entre los equipos. Es necesario accionar una serie de palancas para garantizar que el Producto se mantenga coherente en su conjunto y que la colaboración entre los squads sea fluida y no esté aislada.
- Palanca 1: Crear una instancia de arbitraje para el roadmap global.
- Palanca 2 : Establecer instancias de planificación y gestión periódicas de dependencias (inspiradas en el PI Planning de SAFe).
- Palanca 3: Implementar una herramienta visual de planificación como el Program Board.
- Palanca 4: Establecer un Design System.
- Palanca 5: Implementar una gestión visual centrada en la experiencia del usuario (Experience Board).
- Palanca 6: Establecer comunidades de práctica.
- Palanca 7: Crear el rol de Product Ops.
- Palanca 8: Establecer un proceso de código abierto interno.
- Palanca 9: Implementar OKR (Objetivos y Resultados Clave).
1.2 Gestión de dependencias entre una squad y un equipo transversal (RH, compras...)
Existen muchas dependencias con los equipos transversales en la empresa y claramente son servicios y roles que no pueden integrarse en cada squad.
Las dependencias que hemos observado en nuestras diversas misiones están relacionadas con necesidades de contratación o refuerzo de equipos con una fuerte dependencia de los servicios de Recursos Humanos y Compras (contratación interna o externa) o con necesidades de experiencia legal o ad hoc.
El precio a pagar es el mismo que para otras dependencias: el time to market se alarga y la previsibilidad de entrega disminuye cuando una squad carece de recursos y no tiene control sobre ese parámetro.
Proponemos diferentes soluciones para gestionar estas dependencias inherentes a cualquier organización.
- Palanca 1: Ser delegado de ciertas actividades realizadas por los servicios de Recursos Humanos o Compras.
- Palanca 2: Negociar un presupuesto de servicios para que cada squad pueda gestionarlo de forma autónoma.
- Palanca 3: Integrar ocasionalmente expertos especializados en los squads correspondientes.
Para saber más descarga el libro Las Organizaciones Orientadas a Producto
2) Gestión de dependencias en organizaciones híbridas
No siempre es posible integrar todas las competencias necesarias en cada squad para brindarles total autonomía. En algunas organizaciones, por razones prácticas o presupuestarias, se mantienen competencias de manera transversal, ya sea a nivel de la tribu o a nivel de la propia organización de Producto: Product Designers, Data Analytics, Testers, Data Scientists, desarrolladores móviles, etc…
A menudo encontramos en los proyectos con clientes, organizaciones híbridas que presentan algunas o todas las características, alineamientos y dependencias descritas a continuación:
Dependencias y alineamientos en una organización híbrida
Esta situación crea automáticamente una fuerte dependencia entre los squads y las entidades transversales, lo que prolonga el Time to Market cuando todas los squads de Producto solicitan simultáneamente el mismo equipo transversal. Los niveles presentados anteriormente son aplicables en la mayoría de los casos y le permitirán resolver parte de las dependencias que encontrará. Sin embargo, tenemos recomendaciones específicas para estas situaciones, según la tipología de su organización.
2.1 Gestión de dependencias con un equipo transversal de back-end
Aunque consideramos que es un antipatrón, sigue siendo común ver equipos de back-end independientes con la misión de servir a squads de Producto muy orientadas al front-end.
El equipo de back-end debe crear APIs que sirvan a varios squads y no puede adaptarse completamente a las demandas de cada uno y al ritmo de desarrollo necesario en el front-end. Al no saber cuándo estará lista la funcionalidad proporcionada por el back-end, los squads a menudo se frustran al depender de otros equipos para alcanzar sus objetivos, mientras que los equipos de back-end tienen que equilibrar prioridades externas que no controlan, lo que puede generar una alta rotación en última instancia.
Sin embargo, no todo está perdido. Además de las soluciones mencionadas anteriormente, puede probar diferentes medidas paliativas para abordar estos problemas.
- Paliativo 1: Integrar temporalmente desarrolladores de back-end en las squads
- Paliativo 2: Definir contratos de interfaz entre los equipos de back-end y front-end
- Paliativo 3: Implementar una arquitectura de microservicios
Es importante tener en cuenta que con una arquitectura de este tipo, se crearán nuevas dependencias entre cada uno de los Feature Team (ya que cada uno será responsable de sus propios servicios), pero estas dependencias son más fáciles de manejar que la relación cliente-proveedor entre un único equipo de backend y varios equipos de frontend.
2.2 Gestión de dependencias con un equipo de Operaciones (Ops)
Al igual que en el enfoque descrito anteriormente, es común ver que el equipo de "Ops" trabaje de forma independiente a los squads y no esté directamente integrado en ellos.
Esta dependencia se refiere principalmente a la implementación de herramientas de desarrollo y, sobre todo, a la puesta en producción de nuevas features. Después de desarrollar un conjunto de features, los squads deben enviar su entregable para que el equipo de "Ops" lo implemente en los diferentes entornos apropiados. Este equipo de "Ops" recibe las solicitudes de implementación de producción de los diferentes equipos y las prioriza. Mientras que la dependencia anterior con los equipos de backend se puede sortear fácilmente, la dependencia con los equipos de Ops puede ser perjudicial para los equipos.
Además de los efectos mencionados anteriormente, como el aumento del Time to Market, la disminución de la predictibilidad y la fatiga de los miembros de los squads, también se corre el riesgo de poner en peligro las entregas.
No pretendemos ser expertos técnicos ni expertos en DevOps, por lo que nos limitaremos a resumir las soluciones de Ops y DevOps que hemos encontrado en nuestras diversas intervenciones.
- Solución 1: Implementar una gestión visual (por ejemplo, kanban) que represente el flujo de entregas y las reglas de priorización.
- Solución 2: Integrar los requisitos del equipo de "Ops" en el trabajo diario de los squads, creando historias de usuario "listas para Ops".
- Solución 3: Proporcionar a los squads fábricas de software como servicio.
Sin embargo, seguimos convencidos de que la mejor solución para promover la agilidad y facilitar el proceso de desarrollo de productos es implementar una verdadera cultura DevOps dentro de la organización.
2.3 Gestión de dependencias con un equipo de componentes independiente (generalmente móvil)
Hemos observado en muchas organizaciones la presencia de un equipo móvil independiente de los squads. De hecho, las especificidades técnicas de las herramientas y plataformas de desarrollo móvil suelen llevar a agrupar a los desarrolladores con estas habilidades en el mismo equipo. Del mismo modo, los Mobile Product Managers y Product Designers deben dominar las pautas de Google (Android) y Apple (iOS), que cambian con frecuencia, y conocer las particularidades del diseño de productos móviles.
Además, dado que la mayoría de los productos se desarrollan tanto para iOS como para Android, no siempre es pertinente o posible, en términos de costes, integrar en cada squad un desarrollador móvil especializado en cada sistema operativo.
Las estrategias que proponemos para gestionar esta situación son:
- Estrategia 1: Mantener los equipos móviles (u otros componentes) y adoptar una lógica de equipo "explorador" en relación con los squads.
- Estrategia 2: Disolver el equipo móvil una vez que el alcance funcional de la aplicación sea equivalente a la versión web.
2.4 Presencia de equipos con skills transversales dentro de la tribu
Por las mismas razones expuestas anteriormente sobre los equipos móviles, no siempre es posible distribuir todas las skills necesarias en cada squad: debido a la falta de talento disponible, Product Design, Data Science o QA a veces se agrupan a nivel de la tribu o incluso de la organización de producto, y trabajan para todos los squads. Aunque a veces es inevitable, este esquema genera muchas interdependencias que a menudo perjudican la eficiencia de los squads. Recomendamos las siguientes soluciones para limitar las fricciones y los cuellos de botella:
- Solución 1: "Agilizar" los equipos transversales.
- Solución 2: Hacer que los squads sean cada vez más autónomos.
Conclusión
Los alineamientos y dependencias son inherentes a cualquier modelo de organización, ya sea entre squads tipo Feature Teams o entre equipos transversales en organizaciones híbridas.
Para nosotros, lo más importante sigue siendo encontrar los mecanismos para limitar los efectos de las dependencias en términos de retraso en el time to market, disminución de la previsibilidad y desmotivación de los equipos. Sin embargo, seguimos convencidos de que las organizaciones verticales con equipos multidisciplinares y autónomos no solo son más compatibles con nuestra visión de la Gestión de Producto, sino que también conducen a una mejor toma de decisiones y una gestión más fácil de las relaciones entre equipos: los alineamientos ciertamente se multiplican, pero las dependencias se minimizan, y son estas últimas las que plantean los mayores problemas.
Creemos que es importante que una organización se acerque gradualmente a este modelo invirtiendo en la contratación de perfiles multidisciplinares, reclutando Product Managers y desarrolladores full-stack, capacitándolos constantemente para mantener o crear esa cultura multidisciplinar y enfatizando la necesidad de una mentalidad abierta al cambio y la iteración organizativa. Cuanto más valore la multidisciplinariedad, más fácil será gestionar las dependencias.
Para leer el capítulo completo descarga el libro Las Organizaciones Orientadas a Producto
Imagen de Google Deepmap en Unsplash
