Después de una reorganización, terminamos con un equipo más grande de especialistas:
¡Gran equipo multifuncional! PERO todos son especialistas. Y necesitan decidir colectivamente lo que el equipo puede incluir en un sprint.
Consideré pensar en ellos como 4 equipos más pequeños con sus propias estimaciones y velocidad histórica. Pero eso suena mal.
¿Qué alternativas tengo?
(Estuve tan tentado de terminar mi respuesta solo con esa palabra).
Hablando en serio, tu problema es que no tienes un solo equipo multifuncional. Tienes cuatro equipos que se llaman a sí mismos/se llaman un equipo.
Sus desarrolladores (y todos ellos se llaman 'desarrolladores' en el lenguaje Scrum) no necesitan ser generalistas, pero el objetivo sigue siendo que tengan forma de T. La única forma en que pueden hacer esto es asociándose entre sí, hablando sobre las especialidades de los demás, aprendiendo y ayudándose unos a otros.
Mientras los desarrolladores de su 'diseñador' miren una tarea de arte 3D y piensen 'eso no tiene nada que ver conmigo', este problema persistirá.
Lo que tienes que hacer es cambiar 'eso no tiene nada que ver conmigo' por 'eso tiene algo que ver con mi equipo'. Me pregunto cómo puedo ayudar?'.
El primer paso es lograr que su Equipo se considere a sí mismo como una sola unidad coherente, en lugar de 4 sub-equipos conectados.
Haz que hablen entre ellos.
Piense profundamente sobre cuándo y dónde los miembros del equipo necesitan colaborar y construya su enfoque basado en eso.
Si las disciplinas individuales se encuentran en flujos de trabajo separados y rara vez necesitan coordinarse, es probable que su solución se parezca menos a un equipo Scrum tradicional. Posiblemente, un marco Kanban sería más apropiado y el intercambio de conocimientos donde pueda ser útil.
Si las disciplinas individuales contribuyen a un flujo de trabajo único y tienen dependencias entre sí, Scrum tradicional tiene mucho más sentido.
En esta situación, es posible que desee considerar un proceso de estimación de dos etapas. La primera etapa es estimar en equipo, considerando la dificultad/facilidad de cada disciplina para realizar el trabajo. La segunda etapa es una verificación de cordura, donde las disciplinas individuales verifican para asegurarse de que no estén sobrecargadas o subcargadas en el próximo sprint.
Por ejemplo:
El equipo tiene una capacidad de 20 puntos de historia y juntos estimaron elementos en su cartera de productos hasta que alcanzaron cerca de 20 puntos para poner en el siguiente sprint. Luego dividimos las historias en subtareas específicas de la disciplina y verificamos que hubiera un buen equilibrio de trabajo dada la composición del equipo. Nos dimos cuenta de que los artistas 3D iban a estar sobrecargados, así que eliminamos una historia en particular y la reemplazamos con algo que tuviera menos 3D involucrado. También nos dimos cuenta de que no había mucho que hacer para los ingenieros de UX, por lo que decidimos incorporar una tarea para analizar la UX en un par de historias planificadas que aún están pendientes.
Solo para agregar un componente a la mezcla:
Esto depende en gran medida de la respuesta de Sarov (si el equipo no habla, no pueden arreglar las cosas), pero este es otro componente importante para hacer que Scrum funcione. Para cualquier equipo Scrum, es probable que sus primeros Sprints se tuerzan de alguna manera: demasiado trabajo, poco trabajo, demasiado trabajo que requiere una especialidad específica, etc. Lo importante es que el equipo se reúna en la Retrospectiva y busca maneras de suavizar esos problemas.
Tenga en cuenta:
Una retrospectiva no es una sesión para asignar culpas. El equipo debe asumir la responsabilidad conjunta del Sprint y considerar juntos formas de mejorar para el próximo Sprint.
Podría ser útil centrarse en el objetivo final: producir un Incremento de producto potencialmente entregable. Dedique algún tiempo a analizar lo que se necesita para que el equipo entregue un Incremento Listo y desglose eso para ver cómo encaja cada especialidad en eso.
Considere formas de dividir verticalmente el trabajo más delgado: ¿cuál es el mínimo absoluto de una función que el equipo podría ofrecer en un Sprint y cómo contribuyen todos a eso? Si una sola característica (por ejemplo, un modelo de personaje que puede caminar) requiere la participación de todos para entregarla, entonces debería ser más fácil para el equipo estimar su tamaño como un todo en relación con otras características.
Tomas Owens
MCW
Felipe