Hace ya mucho tiempo comencé lo que pretendía ser una serie de artículos sobre escalado Agile que, por diversas razones, había dejado “colgada” pero que no quería dejar inconclusa. Creo que merece la pena poner en orden todas las ideas que se pueden articular alrededor de esta serie. Aquí tienes el enlace a la anterior entrada, que hoy por hoy queda un poco lejos:
Pulsando en el enlace a la serie completa tendrás el índice a todos los artículos a medida que se vaya completando.
En el capítulo anterior nos centramos en qué entendemos por un equipo ágil y su configuración ideal cuando sólo es responsable del desarrollo de un producto o proyecto. En este capítulo vamos a ver qué sucede cuando tenemos un único equipo que debe atender a varios productos a la vez y cómo podemos manejar esta tensión. Estudiaremos cómo dirigir este crecimiento de una manera orgánica. Para ello vamos a comenzar por un ejercicio un pelín teórico.
Un equipo para cada producto
Imagina que tenemos un equipo centrado en desarrollar un producto, tal y como hemos visto en el artículo anterior, pero ahora nos piden que construyamos otro producto completamente diferente y de tal manera que no afecte al desarrollo del anterior. Pedimos crear un nuevo equipo y gestionarlo de manera completamente independiente, y nos aceptan esa configuración. (Que es mucho decir, pero recuerda que estamos haciendo un ejercicio de imaginación) 😉
Vayamos despacio. Piensa en qué sucede cuando sólo tenemos estos dos equipos trabajando por separado en dos productos completamente diferentes. ¿Qué comparten y qué les separa?
Por un lado, comparten la misma empresa. Eso va a introducir un montón de limitaciones, pero siguiendo en nuestro ejercicio, vamos a imaginar que ninguna de esas restricciones obliga a ninguno de los dos equipos a pensar en el otro a la hora de organizar su trabajo. Es decir, ambos equipos planifican por separado, construyen por separado y entregan por separado. No hay ninguna necesidad de sincronizar ni planificar de manera conjunta en ningún momento.
Así pues, si escalamos esta configuración, es decir, si para cada nuevo producto pedimos crear un nuevo equipo y gestionamos todo de manera independiente, tendríamos una imagen como ésta.
Ventajas de esta configuración:
- Cada producto se puede gestionar de manera independiente del resto, de manera que se pueden tomar decisiones inmediatamente, sin contar con el resto.
- Cada equipo actúa como una unidad independiente, tanto desde el punto de vista de sus procesos internos (sin dependencias con otros) como de su composición (damos por sentado que tiene todas las habilidades necesarias para hacer bien su trabajo).
- Ser dueños de tu destino (de tus éxitos y tus fracasos) suele llevar a mejores resultados, sobre todo en entornos donde es necesario innovar.
Inconvenientes de esta configuración:
Sus ventajas son, a la vez, su mayor inconveniente. Esa independencia fomenta varios tipos de ineficiencias:
- Las personas no tienen la necesidad de compartir aprendizajes fuera del equipo y, por tanto, el resto de la organización no se beneficiará de ellos.
- Conseguir montar un equipo adecuado a las necesidades de un producto/proyecto nuevo puede ser difícil. El coste de oportunidad de no empezar hasta tener el equipo completo o el coste en sobreesfuerzos o carencias técnicas por empezar sin tener a todo el equipo deben ser contempladas.
Seguro que ya estás viendo que esta manera de escalar no es realista y tampoco sostenible. Sin embargo, curiosamente, es muy similar a la que suelen tender muchas consultoras, que organizan equipos nuevos cada vez que necesitan comenzar un nuevo proyecto. Esto lleva a un problema añadido: las personas como “recurso escaso”. Quiero abordar este tema en esta serie, pero no aún. Ten paciencia.
Doy por descontado que, a medida que avance la vida del desarrollo, iremos descubriendo nuevas necesidades de personal y habrá que ir cambiando la configuración del equipo. Esto también es un tema interesante, que también vamos a aparcar de momento.
Un equipo para varios productos
A continuación vamos a estudiar mejor la tensión que provoca la necesidad de abordar más de un producto/proyecto por parte del mismo equipo. En el siguiente artículo estudiaremos la tensión del otro eje: la que provoca la necesidad de aumentar el número de equipos para trabajar en el mismo producto/proyecto.
Si recuerdas los elementos esenciales que identificamos en el primer artículo:
Cuando añadimos un nuevo producto, su presencia implica que habrá:
- Otra lista de funcionalidades (product backlog) que deberá ser priorizada por separado para dar coherencia y poder gestionar las expectativas de los clientes (internos o externos). En el dibujo las he coloreado de azul y naranja para distinguirlas.
- Los incrementos de producto también deben construirse y entregarse por separado. En el mejor de los casos serán independientes y sólo estaremos sujetos a nuestra propia disponibilidad como equipo.
- Todo esto afecta al equipo porque por un lado ya comienza a exigirle una mayor carga cognitiva y cambios de contexto que afectan no sólo a la eficiencia sino también a la calidad.
Éste de la carga cognitiva es un temazo que tratan muy bien en los primeros capítulos del libro @TeamTopologies y que trataré también en otro artículo más adelante.
Esta configuración es bastante frecuente en equipos que se han estado haciendo cargo del desarrollo de un proyecto/producto durante bastante tiempo, éste ya está bastante estable (hay pocas funcionalidades nuevas que desarrollar, quizás pequeñas modificaciones de vez en cuando, o correcciones de defectos que puedan aparecer extemporáneamente) y alguien considera oportuno comenzar un nuevo desarrollo (normalmente porque se quiere aprovechar que el equipo ya está formado, los conocimientos y experiencia adquiridos en el anterior desarrollo, etc). Es una decisión bastante razonable, pero no exenta de retos.
Navegando la tensión de aumentar el número de productos
Estas dificultades suelen pasar inicialmente desapercibidas porque la persona responsable de priorizar (Product Owner) no tendrá aún muchos problemas. Vamos a ver qué pasa si aumentamos el número de productos de 2 a 3.
Gráficamente ya se puede observar que, para mantener un balance en el avance de los 3 productos, el equipo tiene que reducir la cantidad de trabajo que realiza para cada incremento. Si estáis haciendo Scrum, esto implicará menos trabajo planificado en cada sprint. Si estáis haciendo Kanban, probablemente añadiréis alguna política del tipo “el 20% de trabajos comprometidos serán para el producto A, el 30% para el B, y el resto para el C” o algo por el estilo.
Por otro lado, la carga cognitiva del responsable de priorizar las peticiones ya empieza a ser significativa. Incluso aunque cada producto esté en un momento diferente de su ciclo de vida, cuantos más cambios de contexto, más difícil se hace tener en la cabeza todos los detalles que afectan a las decisiones que luego hay que tomar. El equipo sufre también ese exceso de carga cognitiva. Se suele ver fácilmente en los refinamientos y reuniones de planificación porque cada vez requieren de más introducciones para dar contexto y enfocar las conversaciones.
Estos cambios de contexto, además, tienen un efecto matemático perverso: los retrasos. Cuantas más cosas queremos hacer “en paralelo”, más tiempo terminamos tardando en tenerlas acabadas y a disposición de los clientes. No me voy a detener a explicar la Ley de Little, pero te dejo aquí el enlace a mi artículo sobre Kanban para que puedas profundizar en ella.
A medida que vamos aumentando el número de productos, la tensión se irá haciendo notar de una manera más evidente. Cada vez habrá más quejas de que hay demasidados cambios de contexto, tanto por parte de los responsables de producto como del equipo. También se hará más difícil gestionar las peticiones porque nuestro tiempo de respuesta cada vez va siendo más lento. Y recuerda que estamos asumiendo que los productos se pueden desplegar con independencia, porque si esto no es así, aquí también observarás una gran tensión: un cuello de botella donde se quedarán esperando nuestros trabajos ya acabados pero aún no disponibles para nuestros clientes. A veces sentirás desesperación, otras veces desapego: “yo ya hice lo mío”. Cuidado si estás ya en el segundo caso porque es un círculo vicioso en el que la calidad del trabajo se va degradando y las relaciones con el resto de actores también. El feedback de los usuarios va perdiendo importancia en nuestro trabajo porque se diluye.
Así pues, en un momento dado sentirás que se hace urgente dividir el equipo. Pero, ¿qué criterio seguirás?
Criterios para dividir un equipo que trabaja en demasiados productos
Lo más importante es recordar el principal problema que hemos visto navegando esta tensión: el aumento de la carga cognitiva, que se suele traducir en pérdida de foco y en aumento en los tiempos de respuesta.
Así pues, la primera respuesta a la pregunta “¿cómo dividimos al equipo?” debería ser: “no hay que dividirlo”. En cambio, hay que evitar que tengan que asumir el aumento de carga cognitiva. Recuerda que ya vimos la estrategia “1 equipo y 1 producto”. Puedes crear una nueva formación y no necesariamente será más caro que seguir sobrecargando al grupo actual. Quizás incluso alguien quiera cambiar de aires y se ofrezca a ayudar con la fundación del nuevo equipo.
Vamos a estudiar cómo actuar sobre los diferentes elementos:
El rol del Product Owner
Antes de dividir al equipo, también debemos estudiar qué hacemos con el rol de Product Owner. A veces sentimos que debemos dividir el equipo pero en realidad lo único que necesitamos es ayudar al Product Owner. Aquí merece la pena detenerse a recordar este artículo dedicado a los roles en el que explicaba (un poco de pasada) cómo entiendo yo el rol de Product Owner y cómo es perfectamente asumible por el resto del equipo. Yo entiendo este rol como un equipo multidisciplinar dentro del equipo de desarrollo, donde perfiles de UX, QA o Marketing tienen especial influencia. Lo relevante aquí es si, efectivamente, necesitamos duplicar el equipo o si sólo necesitamos incorporar a un nuevo Product Owner para que tenga el foco suficiente en su producto o productos.
Los Product Backlog
Estamos bastante acostumbrados a identificar un Product Owner con un Product Backlog. En realidad un Product Owner (PO) puede manejar varios backlogs, y también un backlog puede ser manejado por varios POs. Es cuestión de que tenga sentido y no genere confusión a la hora de tomar decisiones. Eso sí, es muy importante que distingamos claramente qué unidades de trabajo corresponden con cada producto, cosa que hacemos asignándolas a sus correspondientes Product Backlog.
Si mezclamos las peticiones, también mezclaremos las prioridades y comenzaremos a perder foco. Por ello es esencial que tengamos siempre bien identificado el Product Backlog de cada producto, independientemente de cuántos haya. Usa etiquetas o usa el mecanismo que quieras, pero mantén bien separado cada lista. Pero, ojo, porque al final el equipo tendrá que planificar el trabajo para una iteración, un lote o como sea que abordéis el trabajo. Y eso implica juntar todas las prioridades y, a su vez, priorizarlas. El típico Sprint Backlog. Éste debe ser único.
Así que el dilema aquí se centrará en identificar cuándo es demasiado el esfuerzo de coordinar todos esos backlogs para entregar al equipo unas prioridades razonables para usuarios y stakeholders. Observa si hay funcionalidades que siempre llegan juntas porque hay productos que comparten estrategia, segmento de clientes… Cualquier pista merecerá la pena explorarla porque puede ser la que te valga a ti en este momento.
Los Incrementos de Producto
Las entregas (o Incrementos de Producto) también deben coordinarse, incluso aunque sean independientes entre sí. El equipo tendrá que planificar los despliegues, cambios en configuraciones, pruebas de aceptación, etc. A mayor número de productos distintos, mayor el tiempo que habrá que dedicar a todas estas actividades. De modo que tu criterio para dividir el equipo se centrará en el tipo de actividades que resultan comunes. Quizás haya varios productos que compartan toda o parte de la infraestructura de despliegue. Ésa sería una buena pista.
También debes prestar atención a los tiempos de ciclo. Es posible que algunas peticiones/incrementos nos lleguen con una cadencia mensual y otras con una frecuencia mayor. Si puedes, agrúpalas por su cadencia natural. Eso no sólo te ayudará a priorizar y planificar las entregas, sino que además te dará pistas de la naturaleza de ciertas tareas, que eventualmente podrás asignar a equipos distintos.
Cuidado, sin embargo, porque podrías llegar a dividir equipos en “equipo de desarrollo” y “equipo de mantenimiento”, porque el primero hace trabajos planificados con la cadencia de un sprint mientras que el segundo hace trabajos de corrección de defectos de manera reactiva. Esto puede parecer buena idea al principio, pero estás creando un mal incentivo: el “equipo de desarrollo” se desentiende de lo que hace porque “el equipo de mantenimiento” lo arreglará si falla. Mucho cuidado con este tipo de divisiones que generan incentivos perversos. Y recuerda: la mejor división de un equipo es ninguna. 🙂
El Equipo de Desarrollo
A medida que aumentamos el número de productos es muy probable que también aumente la variedad de trabajos a realizar, lo cuál requerirá habilidades diferentes, y no siempre de manera permanente en el equipo, puesto que las peticiones cada vez se distancian más en el tiempo. Ésta es probablemente la mayor dificultad a gestionar: la composición del equipo. ¿Cuántos frontends, cuántos backends, etc? Y encima que haya suficientes para que la gente se pueda ir de vacaciones sin detener el ritmo de desarrollo.
Mi consejo es que no debemos pasar de 8 personas en un equipo, contando con los roles de producto, por una razón muy sencilla: porque las reuniones se vuelven ineficaces. Un equipo multidisciplinar tampoco debería tener menos de 4 personas. Me he llegado a encontrar configuraciones de 5 equipos de una persona cada uno y un coordinador de todos esos 5 equipos. Imagina si hubieran montado un único equipo en el que se hubieran coordinado entre ellos. Bien, pues este efecto es el que tenemos que evitar todo el rato cuando dividimos un equipo en dos: hay que evitar la sobrecarga por coordinación. Todo esto lo veremos mejor en el capítulo siguiente.
El otro efecto que debemos cuidar es el de la hiperespecialización. Si en un equipo abunda una especialidad, p.ej. hay muchos desarrolladores de frontend, podemos caer en la tentación de crear un equipo especializado en frontend y darles el encargo de todas las peticiones relacionadas con esa parte del sistema. Sin embargo, ya vimos en el artículo dedicado a la Ley de Conway que con este tipo de decisiones lo que hacemos es deteriorar la arquitectura de nuestro sistema. Por tanto, debemos mantener siempre equipos lo más multidisciplinares que nos sea posible porque eso es lo que les garantizará una mayor autonomía y serán más flexibles en el largo plazo.
El mismo razonamiento aplica si estamos tentados de asignar tareas dentro del equipo según el producto correspondiente, creando de facto dos (o varios) equipos. Esto crea una serie de incentivos perversos como los silos de conocimiento (el sub-equipo A termina sabiendo sólo del producto A y se desentiende del resto). Además, el equipo pierde resiliencia porque el sub-equipo A no puede ser sustituido por nadie más para trabajar en el producto A.
El Feedback de los Usuarios
Cada vez tardamos más en poner en producción, incluso funcionalidades pequeñas, por lo que la percepción de los usuarios se irá deteriorando. Intenta mantener conectado cada Product Backlog con el feedback de los usuarios, y prioriza éste siempre antes que cualquier otra nueva funcionalidad, especialmente si se trata de defectos encontrados en producción.
En general el feedback no va a ser un criterio para dividir, pero podría ser que los segmentos de clientes o la madurez de los productos fueran las líneas a explorar a la hora de dividir a tu equipo. Recuerda que lo que buscamos es que todo el equipo se mantenga enfocado todo lo posible.
Resumen de cómo escalar cuando crece el número de productos
En el siguiente artículo haremos un repaso a cómo surgen las presiones para aumentar el número de equipos, cómo nos afectan estas decisiones de ampliación y cómo podemos gestionarlas. Mientras tanto, aquí te dejo un breve resumen de consejos cuando escalamos el número de productos.
Los roles responsables de producto y los equipos necesitan enfocarse en hacer su trabajo:
- Siempre que puedas, no dividas a los equipos. Es preferible crear uno nuevo para que trabaje de manera independiente, pero no olvides que tendrás que pagar por mantener la coherencia de los productos si es que no son exactamente independientes.
- A mayor número de productos, mayor tiempo de ciclo. Los proyectos y funcionalidades pequeñas son más fáciles de encajar en una planificación.
- Protege la autonomía y resiliencia del equipo. Si lo divides creando dependencias con otro equipo, reduces su autonomía. Si reduces demasiado el tamaño del equipo, puedes estar dificultando que se vayan de vacaciones, se pongan enfermos, etc.
- No dividas los equipos demasiado pronto/tarde: observa sus tiempos de ciclo para acomodar los cambios.
- No permitas sobrecargas en los roles responsables de producto. Si es necesario, crea un equipo para darles apoyo con las tareas extra (p.ej. preparación de mockups, planes de prueba, etc).
LA FOTO: Los folletos de los supermercados son un ejemplo claro de variedad en el catálogo de productos. A mayor variedad, más dificultad en el negocio, pero también alcanzamos a mayor número de clientes.