Nuestro equipo está formado por 12 personas que trabajan en un solo producto. Mientras que Scrum dice que el tamaño del equipo debe ser de 3 a 9 personas. Entonces, ¿no deberíamos usar Scrum solo por el tamaño del equipo? Probablemente no podamos dividir el equipo, porque en su mayoría estamos trabajando en diferentes tareas o historias relacionadas con un producto. Entonces, aunque esas historias y tareas están interconectadas de alguna manera, no es que todas las tareas pertenezcan a una sola historia.
El problema en este momento es que nuestro Daily Scrum no es una reunión de 10 minutos, sino que toma alrededor de 30-35 minutos, lo que no creo que sea un uso eficiente del tiempo de todos. Y no todos los detalles están relacionados con todos los miembros del equipo. Pero a veces es útil en la forma en que todos los miembros tienen una idea de lo que está pasando en el equipo y si hay dependencia entonces todos están allí para resolverlo, ya que las diferentes historias están interconectadas en algún momento o probablemente alguien en otra historia irrelevante. puede responder alguna pregunta para resolver la dependencia.
¿Entonces qué sugieres? ¿Deberíamos mantener el Daily Scrum como está? ¿O deberíamos hacer equipos más pequeños de alguna manera? No sé cómo podemos dividirlo. Hay desarrolladores móviles, desarrolladores back-end, QA, Devops y BI. Entonces, ¿cómo debemos dividirlo? ¿O deberíamos seguir haciéndolo de la misma manera pero con algunos cambios que puedas sugerir?
Si su standup dura entre 30 y 35 minutos, incluso con 12 personas, el problema no es la cantidad de personas, sino para qué está utilizando el standup. Standup no es para actualizaciones de estado. Es para la identificación del bloqueador. Repasemos el flujo tradicional del discurso de pie de alguien:
Entonces, si las personas tardan 3 minutos en repasar eso en promedio , entonces están súper bloqueados por un montón de cosas y deberías sentarte con ellos y trabajar fuera de línea, o simplemente lo estás haciendo mal. Si hay más de una o dos preguntas de seguimiento, dígales que lo desconecten.
Es importante reconocer que Scrum no dice que un equipo debe tener entre 3 y 9 personas. La Guía de Scrum dice que Scrum es más efectivo con un Equipo de Desarrollo de entre 3 y 9 personas. Un Equipo Scrum (incluido el Product Owner y Scrum Master) tendría un tamaño ideal de 4-11. Los equipos de desarrollo que tienen menos de 3 personas o más de 9 personas pueden experimentar algunos problemas con las reglas que Scrum ha establecido: para los equipos más pequeños, puede agregar una sobrecarga innecesaria en la forma en que se administran los eventos y los artefactos; para equipos más grandes, es posible que no tenga suficiente tiempo dentro de los marcos de tiempo y los canales de comunicación adicionales pueden ralentizar al equipo.
Pero eso no resuelve el problema: tiene un equipo de 12, que es más grande de lo que sugiere Scrum.
Lo ideal sería dividir el equipo. Debido a que los equipos de Scrum se organizan a sí mismos, el equipo determinaría cómo dividir mejor al equipo.
Hay dos guías que toman Scrum y lo escalan: Nexus (de Ken Schwaber y Scrum.org) y Scrum@Scale (de Jeff Sutherland y Scrum, Inc.) . También hay una serie de otros marcos ágiles escalados, pero esos pueden ser un poco pesados en este momento. Incluso Nexus y Scrum@Scale están diseñados para casos de 3 o más equipos, pero algunos de los conceptos siguen siendo relevantes.
En este momento, realmente solo necesita dividir el equipo de desarrollo. La guía común es que tiene un Product Owner para cada Product Backlog y solo hay un Product Backlog para un producto en particular. Dado que solo tiene un Producto, solo necesita un Product Backlog y, por lo tanto, un Product Owner. El Scrum Master puede, en teoría, también facilitar a ambos equipos, pero eso casi seguramente haría que el Scrum Master fuera un rol de tiempo completo.
La forma en que se divide el equipo depende del equipo, aunque la empresa probablemente debería participar. Scrum tiene algunas reglas sobre la composición del equipo, principalmente que cada equipo de desarrollo debe tener todas las habilidades necesarias para crear un incremento de producto. Es decir, un equipo debería poder tomar un elemento de la cartera de productos y llevarlo a Listo sin necesidad de salir del equipo.
Después de dividir el equipo, el resultado de cada Sprint debe ser un Incremento Completamente Integrado y Listo.
Pero digamos que no puedes dividir el equipo. Todavía hay algunas otras cosas que puedes hacer.
Primero, trate de hacer cumplir mejor las cajas de tiempo de los eventos. Un Daily Scrum no es una reunión de estado: las personas no necesitan entrar en los detalles de su trabajo. Concéntrese en cosas de interés para el grupo (por ejemplo, terminar algo que estaba impidiendo a otra persona) o en los impedimentos actuales que impedirán que el equipo logre la meta. Lo mismo es válido para los otros eventos: concéntrese en sus intenciones y sea disciplinado para llegar al propósito.
En segundo lugar, trabajar en la gestión de dependencias al ordenar el Product Backlog y en Sprint Planning. Trate de mantener a todos activos y comprometidos. No haga que las personas comiencen un trabajo que está bloqueado porque otras personas están trabajando en otras cosas. Esto es un desperdicio (en el sentido Lean de la palabra). Al mismo tiempo, siga intentando entregar un valor visible a las partes interesadas al final de cada Sprint.
Tercero, reducir el tamaño de las personas involucradas en los diferentes Eventos Scrum. Por ejemplo, limite los asistentes del Daily Scrum solo al Equipo de desarrollo. Si hay personas en roles secundarios, puede invitarlos como observadores silenciosos (y hacer cumplir las reglas del observador silencioso) y pedirles que se vayan si interfieren con el evento. Para eventos como Sprint Planning y Backlog Grooming, invite solo a las personas necesarias. Algunos buenos ejemplos serían que roles como Diseñador de UX y Analista de negocios apoyarían al Propietario del producto; solo el Propietario del producto tendría que asistir a los eventos con el equipo (y puede delegar si no está disponible por algún motivo). Esto puede ayudar a reducir la cantidad de personas y hacer que las reuniones y los eventos fluyan sin problemas.
Finalmente, comience a entrenar de forma cruzada. Si su organización continúa creciendo, es casi seguro que tendrá que cambiar su proceso ya que Scrum no será adecuado para un equipo tan grande o dividir su equipo. Si sigue el camino de dividir el equipo, querrá asegurarse de que los equipos tengan las habilidades adecuadas para ese futuro. También considere esto si contrata nuevas personas en la organización.
Thomas Owens tiene una buena respuesta y solo quería ampliarla.
El objetivo del Scrum Master es informar al Equipo Scrum sobre cómo funciona Scrum y luego quitarse de en medio. Usted (supongo que es el Scrum Master) debe asegurarse de que el equipo esté bien informado sobre los por qué de los problemas (y, si lo desea, puede proponer posibles soluciones) que prevé, pero finalmente no solo deje cómo , pero también si para solucionar esos problemas le corresponde al Equipo.
El equipo también puede presentar más problemas, soluciones o problemas con soluciones que los presentados aquí, una vez que comience la discusión. Plantéelo en la reunión retrospectiva y luego deje que el equipo llegue a una solución acordada por sí mismos.
El último equipo de Scrum del que formé parte tenía fácilmente 20 miembros, y nuestras reuniones diarias rara vez excedían los 15 minutos. El scrum fue por un estado rápido. En qué trabajé / terminé ayer, en qué estoy trabajando hoy, qué obstáculos tengo. Cualquier cosa que no le interesara a todo el equipo se pospuso para una discusión paralela después del standup. Esto funcionó bien. Todos descubrimos dónde estábamos, en qué estaba trabajando la gente y cuáles eran los problemas. Las soluciones a los problemas no se discutieron en el standup a menos que fuera del orden de "Joe, ¿puedes encargarte de eso?". Con frecuencia descubrimos cosas que necesitaban ser discutidas más a fondo. Estas cosas generaron discusiones más enfocadas para las partes interesadas después del standup.
La respuesta rápida es que el tamaño del equipo no es el principal problema aquí. El problema es lo que la gente está haciendo en el stand up.
No debe dividir el equipo solo para obtener el recuento "correcto".
El equipo debe enfocarse en los objetivos principales del stand up, que es garantizar que el equipo sepa qué hacer y que pueda hacerlo de manera efectiva (sin bloqueos, etc.). Los medios para eso son las siguientes preguntas:
Scrum Master debería abordar esto, ya que definitivamente es un impedimento para el equipo y supongo que podría haber otros problemas relacionados.
nvoigt
ctrl-alt-delor