Demasiado grande para escalar - Guía del tamaño óptimo de un Scrum Team

Ya sea que estés trabajando en una pequeña empresa o en un nuevo producto en una gran empresa, es probable que llegue un punto en el que tengas demasiadas personas en un solo equipo. Identificar las señales de que el equipo ha sobrepasado su numero ideal de participantes te ayudará a evitará llegar a una etapa ineficiente.

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 se tomen algunas decisiones que reflejen tus circunstancias. Algunos puntos 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 dividir las funciones (por ejemplo, equipos de front-end y back-end)?

• ¿Deberían los nuevos equipos tener backlogs separados?

• ¿Debería crecer el equipo de gestión del producto en consecuencia?

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

El indicador más obvio para comenzar a pensar en una división de equipo o agregar un nuevo equipo es cuando aumenta el presupuesto. Esto puede ocurrir en una nueva ronda de inversión en un inicio o nuevos objetivos para un producto en una empresa. Si el aumento de presupuesto es tan grande que su equipo crecerá 3 veces o más, entonces no hay duda de que tendrás que dividir a el equipo actual para distribuir los conocimientos técnicos. Sin embargo, las decisiones no son tan claras cuando el aumento del presupuesto es incremental y terminas agregando algunas personas nuevas a la lista. Por ejemplo, tienes planes de hacer crecer al 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 inevitablemente crea más procesos para poder trabajar en sincronización.

¿Qué dicen los expertos?

Jeff Bezos, el fundador de Amazon, ha estado usando la regla de las dos pizzas para reuniones y equipos. Eso significa que cada equipo debe tener solo la cantidad de integrantes equivalente a la cantidad de personas que dos pizzas puedan alimentar durante el almuerzo.

La Guía Scrum sugiere tener entre tres y nueve miembros del equipo que en realidad están ejecutando el Sprint Backlog. Eso significa que no se incluiría al Product Owner o o al Scrum Master en el total a menos que alguno de ellos esté implementando los elementos del Backlog.

Estos números parecen tener un sentido intuitivo, pero también hay una matemática detrás. Si piensas en un equipo, cada persona es como un nodo y se unen a otros nodos. Estas 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 un equipo crece, estos números de estos enlaces no crecen linealmente. Existe una fórmula para enlaces entre nodos. Esta es la tabla de crecimiento de enlaces:

La tabla ilustra claramente desde un punto de vista matemático por qué los equipos operan 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 tamaño solo podría operar eficientemente si sus funciones estaban muy bien definidas y rara vez se superponen o llega a haber 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á volviendo demasiado grande

Daily Scrum

A veces, conocido como el Daily Standup, el Daily Scrum es una reunión de todo el equipo para discutir el progreso y los impedimentos del sprint. La Guía Scrum sugiere cronometrar a no más de 15 minutos y es una buena prueba de fuego para el tamaño del equipo. Si empiezas a notar que tu equipo está sobrepasando la barra de 15 minutos, entonces puede indicar una de dos cosas:

Los Daily Scrums no son eficientes. La gente está entrando en demasiados detalles o no hay un orden claro para hablar y se necesita tiempo para que los compañeros expresen su opinión. Tal vez el Product Owner o el Scrum Master estén utilizando el Daily Scrum como una oportunidad para proporcionar varios cambios o actualizaciones no relacionados con el sprint.

El equipo es demasiado grande. Si los Daily Scrums son eficientes, pero aún estás superando los 15 minutos, es posible que simplemente tengas demasiada gente en el equipo. También debes comenzar a notar que las personas están perdiendo interés porque hay un límite en la cantidad de información que puede recibir una persona. Si hay demasiadas personas que proporcionan actualizaciones, se hace difícil darle un seguimiento del progreso de todos y comprender el estado del equipo. . Esto hace que las personas vean hacia adentro y reflexionen solo sobre su progreso en lugar de buscar oportunidades para ayudar a otros.

Preparación y Planificación del Sprint

Tanto la preparación como la planificación del sprint 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 demasiada gente podría llevar al equipo a un punto muerto. Siempre hay diferentes maneras 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 Daily Scrum, no hay que confundir una sesión de planificación ineficiente con que el equipo que es demasiado grande. En última instancia, es tarea del Scrum Master hacer que las ceremonias de scrum sean eficientes y efectivas.

Retrospectiva

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

Sin embargo, al igual que con la planificación del sprint, demasiados miembros del equipo crean demasiados enlaces, todos ellos son puntos potenciales de conflicto. Comienza a darte cuenta si estás encontrando cada vez menos puntos en común durante las retrospectivas. Puede ser una señal de que el equipo es demasiado grande y que se beneficiaría de la división.

Como dividir al equipo

Dividir al equipo es una tarea relativamente fácil. Solo tienes que dividir a los miembros del equipo en dos grupos, asegurarte de que cada uno tenga personas con experiencia similar y definir los objetivos para los nuevos equipos. Sin embargo, hay algunas 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 que debes 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 cuestión de principios ágiles, entonces ellos deberían ser capaces de dividirse ellos 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 necesarias como equipo para crear un incremento de producto". Esto se aplica al escalar a dos o más equipos. Para muchos desarrolladores, especialmente si son nuevos en Agile, la tendencia natural es pensar junto a 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 ocasiones, pero como gerente de producto, debes desaconsejarlo la mayor parte del tiempo. Un equipo lleno de front-enders no puede entregar un incremento de producto por sí mismo 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 de los no desarrollo en el equipo. En diversas situaciones, un equipo puede incluir un diseñador, un analista de negocios o un especialista en control de calidad. Una vez que divides un equipo, especialmente si no estás contratando demasiadas personas nuevas, surge un dilema sobre qué hacer con estos roles. ¿Deberían repartir su tiempo entre los equipos? ¿Deberías contratar personas nuevas, que estarían dedicadas a un solo equipo? ¿Deberían trabajar con los equipos de desarrollo o formar parte del equipo de producto?

Realmente no hay un consejo perfecto para esto porque cada producto y cada proyecto es muy diferente. Estas decisiones se toman mejor junto con el consejo del equipo, teniendo en cuenta que es posible que se tenga que corregir el rumbo a lo largo del camino.

¿Deberían de tener Backlogs separados los diferentes equipos?

Si un equipo está dividido surgirá una pregunta habitual que es si deberían trabajar en el mismo Backlog o tener uno por equipo. Podemos consultar los marcos de trabajo ágil escalados para obtener orientación.

SCRUM@SCALE

Scrum@Scale es un marco de trabajo desarrollada por el creador de las Guía de Scrum. Scrum@Scale tiene en cuenta dos puntos:

• El proceso a nivel de equipo es el mismo que se describe en la Guía de Scrum.

• Los Product Owners forman un equipo de Product Owners, donde crean un único Backlog unificado. Esto se hace para evitar la duplicación de trabajo y para crear visibilidad dentro de la empresa. Al mismo tiempo, los equipos tienen sus Backlogs separados que alimentan los elementos del Backlog unificado.

Así que, en esencia, Scrum@Scale imagina a los nuevos equipos con sus propias tareas y respectivos Backlogs. Simplemente 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 se está trabajando con dos equipos.

LARGE-SCALE SCRUM (LESS)

LeSS promueve un enfoque interesante para el Backlog. En LeSS, el Product Owner trabaja desde dos hasta con ocho equipos. Puede parecer imposible que un PO trabaje con tantos equipos. La filosofía de LeSS es que un PO funciona en un nivel abstracto y delega las responsabilidades de refinamiento del elemento del Backlog a los equipos. En este caso, los equipos de desarrollo multifuncionales también deben incluir el conocimiento del dominio de negocios 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 revisar el progreso y responder a las consultas.

Priorizar Reuniones

Si estuvieras asistiendo a los Daily Scrums de un solo equipo, continuar con este hábito probablemente sea improductivo. Considere los Daily Scrums como una oportunidad para visitar a los equipos y recordarles que estás disponible para las discusiones.

Tu asistencia a las sesiones de planificación de sprint dependerá de la madurez de los equipos. Si los equipos incluyen muchas caras nuevas o si no han estado trabajando con Agile durante mucho tiempo, entonces será necesario un poco de orientación por tu parte. Incluso si te sientes suficientemente confiado en dejar que el equipo planifique sin tu asistencia, asegúrese de estar disponible para conversar o hablar por voz con el equipo durante sus planes si surge alguna pregunta.

Las revisiones del Sprint tendrán que seguir siendo tu principal prioridad y todas deben ser atendidas. Las revisiones de Sprint son una oportunidad para obtener retroalimentación de primera mano de los interesados actuales y del propio equipo. Es un momento en que las suposiciones se validan y no se deben pasar por alto.

Involucrarte más con los Scrum Masters

Si bien puedes estar reduciendo tu compromiso con algunas de las ceremonias de scrum, debes duplicar tu asociación con el Scrum Master. Puede haber más de uno ahora después de la división del equipo, en cuyo caso, tendrás que trabajar en estrecha colaboración con todos ellos.

Asegúrate de que puedas confiar en ellos para que den una visión honesta del progreso del equipo y cualquier problema que surja durante los sprints. Estas relaciones te permitirán estar al día 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 se presenta normalmente como escala de procesos de scrum. Es una réplica del Daily Scrum 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 utiliza para resaltar cualquier problema técnico entre equipos que deba resolverse.

Considera ampliar el equipo de producto

Si tu configuración de Scrum requiere que el gerente de producto se involucre activamente con el equipo, considera agregar más personas al lado del producto. Hay algunas maneras de abordar esto.

Jefes de producto junior. Una vía es asumir un rol más estratégico para ti al mismo tiempo que se agregan 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 que uno o más analistas de negocios trabajen en los equipos o junto a ellos. El gerente de producto puede trabajar con los analistas de negocios para identificar los supuestos del producto y luego permitir que los analistas de negocios encuentren formas de validarlos a través de la investigación o nuevas características.

Conclusión

A medida que el equipo crezca, es probable que comiences a notar algunas señales de que se está volviendo demasiado grande, especialmente en:

• Daily Scrum: Si superas el límite de tiempo de 15 minutos durante los scrums diarios y ves que la gente comienza a perder interés.

• Planificación del sprint. Si terminas en puntos muertos durante la planificación del sprint con más y más frecuencia.

• Retrospectiva. Si comienza a notar que se está volviendo más difícil alcanzar compromisos durante las retrospectivas.

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

• Priorizar reuniones. Piensa en qué ceremonias ágiles valen tu tiempo y cuáles pueden ignorarse.

• Participar con Scrum Masters. Utiliza Scrum Masters como tus proxies de equipo y reúne información de ellos.

• Expandir el equipo de producto. Agrega personas para que trabajen con usted y ayuda con las tareas repetitivas diarias o realiza una investigación de usuarios y un análisis de mercado.

Al utilizar estas sugerencias, deberías poder tener una división de equipo sostenible. Si tus equipos siguen creciendo y agregas aún más equipo en el futuro, debe leer sobre Scaled Agile Framework, que proporciona sugerencias de estructura y proceso para Agile a escala.

Artículo Original: https://www.toptal.com/product-managers/agile/scrum-team-size?fbclid=IwAR3pNn3F7gdKx3TZGFiUmeojBgK5nywA3NkHQCJ7beDuTX2xStab8DBR4JI&utm_campaign=Social+Media&utm_source=topt.al