Demasiado grande para escalar: guía de tamaño óptimo del equipo Scrum

Escucha la versión en audio de este artículo

Ya sea que esté trabajando en una pequeña empresa emergente o en un nuevo producto en una gran empresa, es probable que llegue a un punto en el que tenga demasiadas personas en un equipo. Identificar las señales desde el principio te evitará llegar a la etapa más ineficiente del equipo.

Cada producto es diferente y también lo son los equipos que trabajan en ellos. Por lo tanto, dividir un equipo también requerirá que tomes algunas decisiones que reflejen tus circunstancias. Algunas cosas a considerar son:

• Cómo mantener la integridad de los conocimientos técnicos cuando los compañeros de equipo ya no trabajan juntos
• ¿Debería dividirse por funciones (por ejemplo, equipos de front-end y back-end)?
• ¿Deberían los nuevos equipos tener atrasos separados?
• ¿Debe crecer el equipo de gestión de productos en consecuencia?

¿Cuándo debería comenzar a crear un segundo equipo?

La indicación más obvia para comenzar a pensar en dividir el equipo o agregar un nuevo equipo es cuando aumenta su presupuesto. Esto puede ocurrir con una nueva ronda de inversión en una startup o con nuevos objetivos para su producto en una empresa. Si el aumento del presupuesto es tan sustancial que su equipo crecerá 3 veces o más, entonces es obvio que tendrá que dividir su equipo actual para distribuir el conocimiento. Sin embargo, las decisiones no son tan claras cuando el aumento del presupuesto es incremental y termina agregando algunas personas nuevas a la lista. Si, por ejemplo, tiene planes de hacer crecer su equipo de 7 a 11 personas, ¿eso requiere una división? Agile promueve equipos pequeños pero también promueve individuos e interacciones sobre procesos y herramientas. Tener dos o más equipos crea inevitablemente más procesos para poder trabajar en sincronía.

¿Qué dicen los expertos?

Jeff Bezos, el fundador de Amazon, ha estado usando la regla de las dos pizzas tanto para reuniones como para equipos. Eso significa que cada uno debe tener solo tantas personas como dos pizzas puedan alimentar durante el almuerzo.

La Guía Scrum sugiere tener entre tres y nueve miembros del equipo que realmente estén ejecutando el trabajo pendiente del sprint. Eso significa que no incluiría al propietario del producto o al maestro de scrum en el total a menos que cualquiera de ellos esté implementando los elementos del trabajo pendiente del sprint.

Estos números parecen tener un sentido intuitivo, pero también hay algo de matemática detrás. Si piensas en un equipo, cada persona es como un nodo y se conecta con otros nodos. Son las relaciones interpersonales entre compañeros de equipo. Pueden ser amistosos, competitivos, rencorosos o cariñosos. Cualquiera que sea la relación entre dos personas, sigue siendo un vínculo que requiere cierta capacidad mental de cada persona. A medida que crece un equipo, estos números de estos enlaces no crecen linealmente. La fórmula para los enlaces entre nodos es \(n(n-1)/2\). Aquí está la tabla de crecimiento de enlaces:

El gráfico ilustra claramente desde un punto de vista matemático por qué los equipos funcionan de manera más eficiente cuando no son demasiado grandes. Si tomamos los 3 a 9 miembros del equipo sugeridos por la Guía Scrum, terminamos con entre 3 y 36 enlaces. Si creciéramos a 15 personas, tendríamos más de 100 enlaces. Un equipo de este solo podría operar de manera eficiente si sus funciones estuvieran muy bien definidas y rara vez se superpusieran o si hubiera algunos subgrupos no oficiales. Ni es el caso ni se desea cuando se trabaja en base a principios Agile.

Señales de que el equipo se está haciendo demasiado grande

Scrum diario

A veces denominado reunión diaria, el scrum diario es una reunión de todo el equipo para discutir el progreso y los impedimentos del sprint. La Guía Scrum sugiere cronometrarlos en 15 minutos y esa es una buena prueba de fuego para el tamaño del equipo. Si comienza a notar que su equipo está superando la barra de 15 minutos, entonces puede indicar una de dos cosas:

• Los scrums diarios no son eficientes. La gente está entrando en demasiados detalles. O no hay un orden claro para hablar y los compañeros de equipo tardan en hablar. Tal vez el propietario del producto o el maestro de scrum esté utilizando el scrum diario como una oportunidad para proporcionar varias actualizaciones no relacionadas con el sprint.
• El equipo es demasiado grande. Si los scrums diarios son eficientes, pero aún se está excediendo de los 15 minutos, es posible que simplemente tenga demasiadas personas en el equipo. También debe comenzar a notar que las personas están perdiendo interés porque hay un límite en la cantidad de información que una persona puede asimilar. Si demasiadas personas brindan actualizaciones, se vuelve difícil realizar un seguimiento del progreso de todos y comprender el estado del equipo. . Esto hace que las personas se vuelvan hacia adentro y reflexionen solo sobre su progreso en lugar de buscar oportunidades para ayudar a los demás.

Preparación y planificación de Sprint

Tanto la preparación como la planificación de sprints son actividades relacionadas con desglosar las historias de los usuarios y estimar su tiempo o tamaño de entrega. Si bien tener más personas puede ayudar al equipo a tomar mejores decisiones, tener demasiadas personas puede llevar al equipo a un punto muerto. Siempre hay diferentes formas de realizar la misma tarea y la cantidad de argumentos en cada lado aumenta con la cantidad de personas en el equipo.

Al igual que con el scrum diario, no confunda una sesión de planificación ineficiente con el equipo demasiado grande. En última instancia, es el trabajo del maestro de scrum hacer que las ceremonias de scrum sean eficientes y efectivas.

Retrospectivo

Durante una retrospectiva, los miembros del equipo pueden resolver cualquier argumento o conflicto y encontrar formas de mejorar su proceso de trabajo. Las retrospectivas nos enseñan el arte del compromiso, ya que nos hace buscar puntos en común entre las diferentes partes. Un equipo es tan poderoso como sus miembros están dispuestos a ceder en sus diferencias.

Sin embargo, al igual que con la planificación de sprints, demasiados miembros del equipo crean demasiados vínculos, todos los cuales son posibles puntos de conflicto. Comience a notar si encuentra cada vez menos puntos en común durante las retrospectivas. Puede ser una señal de que el equipo es demasiado grande y se beneficiaría si se dividiera.

Cómo dividir el equipo

A primera vista, dividir el equipo es una tarea relativamente fácil. Divida a los miembros del equipo en dos grupos, asegúrese de que cada uno tenga personas con experiencia similar y defina los objetivos para los nuevos equipos. Sin embargo, hay bastantes cosas a considerar que podrían tener un gran impacto en el éxito futuro de los nuevos equipos.

moral del equipo

Probablemente una de las cosas más importantes a tener en cuenta es la moral del equipo. Al final del día, son las personas del equipo las que tendrán que trabajar en la nueva composición. Si el equipo es maduro en términos de principios ágiles, entonces deberían poder dividirse por sí mismos. Este es el resultado más deseable porque los miembros del equipo conocen mejor sus relaciones internas: quién trabaja mejor con quién y quién podría beneficiarse de estar en equipos separados.

Equipos multifuncionales

Scrum promueve equipos multifuncionales “con todas las habilidades como equipo necesarias para crear un incremento de producto”. Esto es cierto cuando se escala a dos o más equipos. Para muchos desarrolladores, especialmente si son nuevos en Agile, la tendencia natural es pensar junto con las líneas técnicas. Por ejemplo, los equipos a menudo quieren dividirse en equipos de back-end y front-end. Esto puede tener sentido en algunas raras ocasiones, pero como gerente de producto, debe desaconsejarlo la mayor parte del tiempo. Un equipo lleno de front-enders no puede ofrecer un incremento de producto por sí solo y, naturalmente, comenzará a pensar más en la capacidad técnica, que es lo que los une. En su lugar, deberían centrarse en el cliente y en cómo satisfacer sus necesidades.

Otra consideración interesante son los roles que no son de desarrollo en el equipo. En diversas situaciones, un equipo puede incluir un diseñador, un analista comercial o un especialista en control de calidad. Una vez que divide un equipo, especialmente si no está contratando a demasiadas personas nuevas, surge un dilema con respecto a qué hacer con estos roles. ¿Deberían dividir su tiempo entre los equipos? ¿Debería contratar gente nueva, que estaría dedicada a un solo equipo? ¿Deberían trabajar con los equipos de desarrollo o ser parte del equipo de producto?

Realmente no hay un buen consejo único para esto porque cada producto es muy diferente. Es mejor tomar estas decisiones junto con el equipo, teniendo en cuenta que es posible que deba corregir el rumbo en el camino.

¿Deberían los equipos tener trabajos pendientes separados?

Si un equipo está dividido, entonces la pregunta natural es si deberían estar trabajando con el mismo trabajo pendiente o si deberían tener otros separados. Podemos buscar orientación en Scaled Agile Framework.

Scrum@Escala

Scrum@Scale es una metodología desarrollada por el creador de la Guía Scrum. Scrum@Scale no es muy prescriptivo y no describe específicamente cómo manejar la acumulación de productos. Sin embargo, señala dos puntos:

• El proceso a nivel de equipo es el mismo que se describe en la Guía Scrum.
• Los propietarios de productos forman un equipo de propietarios de productos, en el que crean una única cartera de pedidos unificada. Esto se hace para evitar la duplicación de trabajo y crear visibilidad dentro de la empresa. Al mismo tiempo, los equipos tienen sus trabajos pendientes separados que alimentan los elementos del trabajo pendiente unificado.

Entonces, en esencia, Scrum@Scale crea imágenes de los nuevos equipos con sus propias órdenes de compra y trabajos pendientes. Solo agrega algunas estructuras adicionales para coordinar el trabajo entre los equipos. Scrum@Scale funciona mejor con varios, decenas o cientos de equipos, pero puede proporcionar información valiosa incluso si trabaja con dos equipos.

Scrum a gran escala (LeSS)

LeSS promueve un enfoque interesante para la cartera de productos. En LeSS, un propietario de producto trabaja con dos a ocho equipos. Puede parecer imposible que una OP trabaje con tantos equipos. La filosofía de LeSS es que el PO trabaja en un nivel abstracto y delega las responsabilidades de refinamiento de los elementos de la cartera de productos a los equipos. En este caso, los equipos de desarrollo de funciones cruzadas también deben incluir conocimiento del dominio comercial para poder entregar un incremento de producto. En LeSS, solo hay un backlog.

Cómo mantenerse al día

Para un gerente de producto, varios equipos significan más trabajo para rastrear el progreso y responder consultas.

Priorizar reuniones

Si estaba asistiendo a los scrums diarios de un solo equipo, continuar con este hábito probablemente será improductivo. Considere los scrums diarios como una oportunidad para conocer el pulso de los equipos y recordarles que está disponible para las discusiones.

Tu asistencia a las sesiones de planificación de sprints dependerá de la madurez de los equipos. Si los equipos incluyen muchas caras nuevas o no han estado trabajando con Agile durante mucho tiempo, será necesaria alguna orientación de su parte. Incluso si te sientes seguro de dejar que el equipo planifique sin tu presencia, asegúrate de estar disponible para pasar o chatear por voz con el equipo durante sus planificaciones si surge alguna pregunta.

Las revisiones de Sprint tendrán que seguir siendo su principal prioridad y todas deben ser atendidas. Las revisiones de Sprint son una oportunidad para obtener comentarios de primera mano de las partes interesadas presentes y del propio equipo. Es un momento en que se validan las suposiciones y no debe perderse.

Participe más con Scrum Masters

Si bien es posible que esté reduciendo su compromiso con algunas de las ceremonias de scrum, debe duplicar su asociación con el maestro de scrum. Es posible que haya más de uno ahora después de que el equipo se separó, en cuyo caso, deberá trabajar en estrecha colaboración con todos ellos.

Asegúrese de que puede confiar en ellos para brindar una visión honesta del progreso del equipo y cualquier problema que surja durante los sprints. Estas relaciones le permitirán mantenerse actualizado sin la necesidad de participar en todas las ceremonias de scrum.

Introducir Scrum de Scrums

A veces llamado meta scrum, un scrum de scrums es una nueva ceremonia que generalmente se presenta a medida que escalan los procesos de scrum. Es una réplica del scrum diario a un nivel superior. Cada equipo designa un embajador, todos los cuales se reúnen en el scrum de scrums todos los días para discutir el progreso y los impedimentos. Esta ceremonia también se usa para resaltar cualquier problema técnico entre equipos que deba resolverse.

Considere expandir el equipo de productos

Si su configuración de scrum requiere que el gerente de producto participe activamente con el equipo, considere agregar más personas al lado del producto. Hay algunas maneras de abordar esto.

Gerentes de producto júnior. Un camino es asumir un rol más estratégico para usted mientras agrega gerentes de productos junior para manejar algunas de las tareas diarias. Podrían asumir algunas tareas como control de calidad (QA), escribir especificaciones para historias de usuarios o crear maquetas de alto nivel para nuevas funciones.

Analistas de negocios. Otra forma es hacer que uno o más analistas comerciales trabajen en los equipos o junto a ellos. El gerente de producto puede trabajar con los analistas comerciales para identificar los supuestos del producto y luego dejar que los analistas comerciales encuentren formas de validarlos a través de la investigación o de nuevas características.

Conclusión

A medida que su equipo crece, es probable que comience a notar algunas señales de que se está volviendo demasiado grande, especialmente en:

• Scrum diario. Si está sobrepasando el marco de tiempo de 15 minutos durante los scrums diarios y ve que las personas comienzan a perder interés.
• Planificación de sprints. Si terminas en puntos muertos durante la planificación del sprint cada vez con más frecuencia.
• Retrospectivo. Si comienza a notar que se está volviendo más difícil llegar a compromisos durante las retrospectivas.

Todo esto apunta al hecho de que es posible que deba dividir el equipo. Dividir un equipo parece una tarea fácil, pero también tiene consecuencias duraderas y cada gerente de producto tiene algunas cosas que considerar al hacerlo:

• moral del equipo. Idealmente, debe dejar que el equipo decida cómo quieren dividirse para minimizar la cantidad de buenas relaciones laborales desechadas.
• Equipos multifuncionales. Los equipos deben tener todas las habilidades necesarias para crear un incremento de producto.
• Pila de Producto. Decida si sus equipos tendrán una cartera de pedidos separada o unificada.

Hacer un seguimiento de dos o más equipos requerirá que establezcas prioridades. Un gerente de producto efectivo debe planificar cómo se mantendrá actualizado con los nuevos equipos:

• Prioriza las reuniones. Piense en qué ceremonias ágiles valen la pena y cuáles se pueden ignorar.
• Interactuar con los maestros de scrum. Utilice scrum masters como representantes de su equipo y recopile información de ellos.
• Ampliar el equipo de producto. Agregue personas para que trabajen con usted y lo ayuden con las tareas repetitivas diarias o realice investigaciones de usuarios y análisis de mercado.

Al utilizar estas sugerencias, debería poder tener una división limpia del equipo. Si sus equipos siguen creciendo y agregará aún más equipos en el futuro, debe leer sobre Scaled Agile Framework, que proporciona sugerencias de estructuras y procesos para Agile a escala.