El equipo constantemente no hace sprints

El propósito de los Sprints no es entregar puntos, sino entregar valor. El equipo no se compromete a entregar un determinado conjunto de puntos o un conjunto de elementos de la cartera de productos. En cambio, el equipo pronostica cuánto trabajo pueden realizar como parte de Sprint Planning. A lo largo del Sprint, el equipo debe centrarse en lograr el Objetivo del Sprint, en lugar de completar un cuerpo de trabajo en particular o terminar tantos puntos o alguna otra medida de salida.

Mirando las prácticas específicas, puedo ver varios problemas potenciales u oportunidades de mejora.

Su proceso de refinamiento parece faltar. Las revisiones recientes de la Guía Scrum sugieren que alrededor del 10 % de la capacidad del Equipo de desarrollo debe asignarse para el Refinamiento de la cartera de productos. Si tiene un equipo de desarrollo de 3 personas y una semana laboral estándar de 40 horas, esperaría unas 12 horas por semana asignadas al refinamiento. No hay un método definido para realizar el refinamiento. Algunos de los equipos con los que he trabajado tenían a todos reunidos varias veces a la semana. Otros tenían personas que trabajaban individualmente en el refinamiento y luego se reunían durante aproximadamente una hora a la semana para alinearse. El equipo necesita descubrir qué funciona para ellos, pero es importante que sea una actividad de equipo completo para difundir el conocimiento y lograr que todo el equipo acepte el trabajo que se está realizando.

Creo que el refinamiento deficiente está dando lugar a una serie de problemas descritos, incluida la falta de comprensión completa de las funciones que se les pide que construyan y el retraso en el desarrollo de las funciones. Es muy probable que la falta de comprensión lleve a tiempos de desarrollo más largos.

La "Planificación 1" y la "Planificación 2" no me quedan claras. Sprint Planning es una sola sesión. Hay dos aspectos: el primero es determinar qué construir en función de la previsión y el segundo aspecto es determinar cómo construirlo. Más específicamente, los resultados principales de la primera parte de Sprint Planning son un Sprint Goal y el resultado de la segunda parte es un plan para lograr ese Sprint Goal.

El tamaño y la composición del equipo también pueden ser problemas.

Aunque Scrum no impone reglas sobre un tamaño de equipo mínimo o máximo, Scrum es más efectivo con un tamaño de Equipo de desarrollo de entre 3 y 9. Tiene 13, tal vez 15 (dependiendo de si los Líderes de equipo son parte del Equipo de desarrollo) . Eso se siente muy grande y la comunicación se vuelve difícil con tanta gente.

También señalaría que Scrum no reconoce un "líder de equipo". Este concepto tiende a llevar a que el trabajo se imponga a las personas que realizan el trabajo en lugar de llevarlo a un Sprint y luego al desarrollo. Tampoco promueve equipos autoorganizados.

No se menciona el Daily Scrum o el Sprint Retrospective, pero sospecho dos cosas. Primero, con un equipo tan grande, no puede realizar un Daily Scrum de manera efectiva en un período de tiempo razonable. En segundo lugar, muchos de estos problemas pueden surgir en una Retrospectiva de Sprint bien administrada.

El mayor problema que veo es la mala comunicación. El tamaño del equipo y la falta de colaboración constante son probablemente los dos factores más importantes.

Parece que estás tratando con un equipo grande y tengo la impresión de que estás haciendo scrum o elementos de él. Si este no es el caso, probablemente pueda ignorar el resto de esta publicación.

Dados los problemas que describe, le sugiero que divida su gran equipo en varios equipos más pequeños que trabajen con el mismo trabajo pendiente. Es un gran cambio organizacional, por lo que no se debe tomar a la ligera, pero es un consejo que le daría a la mayoría en esta situación. Los equipos pequeños pueden ser ágiles y reaccionar más rápido.

Algunas observaciones de la información que proporcionó:

• Parece que es posible que desee al menos revisar la rendición de cuentas/responsabilidades en su equipo/organización de desarrollo. ¿Quién es responsable de la entrega de los resultados del equipo? ¿Cuáles son las responsabilidades de los líderes del equipo y de los demás miembros?

• Parece que el equipo no se siente completamente responsable de su trabajo y producción. ¿Qué pasa con cada miembro individual del equipo? ¿Cómo se sienten acerca de la situación? ¿A qué atribuyen este "fracaso"?

• Tener menos miembros puede ayudar a identificar cualquier problema subyacente que no surja en su constelación actual. ¿Cada miembro individual está trabajando a plena capacidad o luchando con problemas recurrentes?

• Tener menos miembros del equipo en un grupo puede ayudar a empoderar al grupo, haciéndolo más eficiente.

Considere si 1 líder + 2 desarrolladores + 1 QA + 1 PO podrían formar un equipo. ¿Ves alguna razón por la que esto no funcionaría? ¿Están tus historias/backlog preparadas para ello? ¿Tu repositorio de código está listo para ello?

Si lo anterior pudiera funcionar, ¿puedes crear tres de estas constelaciones con los miembros actuales del equipo? ¿Hay suficiente conocimiento del dominio en cada equipo? No se preocupe si una o dos personas necesitan unir dos equipos. Esto se puede superar con la contratación o la reconfiguración más adelante si cree que está en el camino correcto.

Pídales que aborden menos historias e intenten terminar un par de sprints. Establezca la velocidad para cada equipo. Sólo entonces asumir más historias.

La mejor de las suertes independientemente de las medidas que elija implementar.

Espero que su equipo se beneficie de un poco de entrenamiento/tutoría, ya que parece haber algunos problemas complejos de los que realmente no se están haciendo cargo.

Algunas observaciones. Usted menciona un total de 15 personas, lo que es inusualmente grande para un equipo Scrum. Divídase en varios equipos y manténgalo en menos de 10 por equipo. ¿Qué papel juegan los líderes del equipo? No hay un "cliente potencial" en Scrum, pero el hecho de que esté haciendo esta pregunta sugiere que tampoco son clientes potenciales muy efectivos. ¿Por qué planificar el próximo sprint durante la semana 2 del sprint actual? Eso parece contraproducente porque está desviando al equipo en un momento crítico. Haga la planificación el día 1 de cada sprint y déjelo así.

Dado que tienen dificultades para estimar dos semanas de trabajo, puede valer la pena acortar los sprints a una semana. Eso podría aliviar un poco las dificultades de estimación, reducir los cambios de alcance inesperados y el equipo probablemente se beneficiará de la disciplina necesaria para los sprints cortos. También intente prescindir de las estimaciones basadas en puntos durante un tiempo. La razón por la que los equipos estiman es para averiguar qué puede encajar en el sprint. Los puntos no parecen estar funcionando para ellos y tal vez sea más simple pedirles que elijan las cosas que están seguros de que pueden hacer desde la parte superior del trabajo pendiente.

Estos son problemas muy reales que enfrentan muchas personas.

Intentaré dar algún consejo/opinión (no es necesario que lo acepte) sobre sus puntos.

Tenemos sprints de 2 semanas: ese es un buen comienzo Durante el sprint, el equipo de productos recibe solicitudes del cliente y recopila los requisitos, pasando los detalles al equipo/líder técnico antes de priorizar el trabajo pendiente (sin embargo, no tenemos una sesión de preparación dedicada). las historias se desarrollan adecuadamente antes de la planificación 1) Los jueves de cada dos semanas, hacemos la planificación

Entonces, al indicar la planificación 1, asumo que hay una planificación 2, sugeriría cambiar el nombre de estos a preparación de la acumulación y planificación de Sprint, ambos tienen funciones diferentes. En la preparación de Backlog, debe asegurarse de que el equipo tenga toda la información en los tickets, deben trabajar juntos y no esperar que hagan cosas (como crear sus propias historias, etc., esto normalmente es para equipos muy maduros), así que asegúrese seguro que tiene una definición de listo y una definición de hecho.

Haga que el PO trabaje con ellos a través de cada ticket y cree la tarea/historias, luego, cuando toda la información esté allí, pídales que calculen (ahora, al principio, esto puede llevar tiempo, pero cuanto más lo hagan, mejor lo harán)

Re durante los sprints: esta es una línea muy fina aquí, un sprint es un sprint en el que no pones más trabajo en un sprint si ya ha comenzado, solo detienes un sprint una vez que el objetivo del sprint es obsoleto, pero sé que en el suceden cosas del mundo real y obtenemos P1 que son críticos, normalmente se abordan de 2 maneras, si es absolutamente crítico, detenga el trabajo (cree un pico) y solucione el problema, luego continúe con el sprint; esto puede ser confuso, otra opción es hacer que espere hasta el final del sprint (pero normalmente no es el caso ya que es una misión crítica): la comunicación con las partes interesadas, etc. es clave aquí (pero también tiene la opción de tener un equipo BAU que se encargue de ese tipo de cosas).

Esta sesión está a cargo del equipo de producto, tratamos de estimar la mayor cantidad posible de historias en la cartera de pedidos, la cartera de pedidos se ordena en función de la prioridad actual.

¡Eso es perfecto!

Los viernes de cada dos semanas, hacemos la planificación.

Esta sesión está a cargo del líder del equipo, se espera que el equipo se tomó un tiempo entre la sesión 1 y la 2 para realizar el trabajo requerido para ajustar las estimaciones, pero entramos en detalles más técnicos del cambio requerido La planificación 1 es para las estimaciones iniciales , esto puede cambiar durante la sesión de planificación 2. El equipo se deja durante 2 semanas, hay casos en los que se produce un aumento del alcance; sin embargo, trate de limitarlo tanto como sea posible, ya que tenemos un desarrollador dedicado para trabajar en problemas de producción que no forman parte de trabajo de velocidad

Esto me parece una mezcla de problemas, 1 la diferencia entre las sesiones de planificación: este es un punto difícil, pero hay una orden de compra por una razón y hay un equipo de entrega por una razón, debe usarlos por sus puntos fuertes. y funciones 1. 1. Un equipo debe trabajar en conjunto en la sesión de preparación (planificación 1) y trabajar en las estimaciones como un equipo; no debería haber más expectativas en el equipo aparte de entregar el artículo si cumple con la definición de hecho. – una sesión de preparación puede durar hasta 4 horas (time box it) 2. 2. Solo tenga standups como actualizaciones (los equipos deben centrarse en la entrega y no ser microgestionados) 3. 3. La creación de alcance es un asesino silencioso, pero debe gestionarse en historias y mejoras no solo como evolucionar el mismo boleto más grande 4. 4. Hay más

Los problemas a los que me enfrento son los siguientes:

Equipo no comunica que no cumplirán plazos de sprint

Esto puede deberse a una amplia gama de razones, confianza, transparencia, correr riesgos, subestimación, etc. Ahora, si el líder del equipo es su gerente, eso también podría presentar problemas, ya que las personas no siempre se abren con el líder de su equipo, aunque deberían. y debe haber un vínculo profesional fuerte.

La recomendación está en la preparación (planificación) para dividir las historias lo suficientemente pequeñas como para rastrearlas individualmente: hacer que el equipo decida en conjunto que las estimaciones funcionan juntas y hacerlos responsables.

El equipo parece no comprender completamente las funciones que se solicitan (podría hablar de la falta de requisitos, sin embargo, no lo creo del todo)

Una vez más, me aseguraría de que 1. El equipo se arregle adecuadamente y de que calculen adecuadamente juntos (no individualmente sino al mismo tiempo, luego hagan preguntas y vean por qué las personas piensan que las cosas son diferentes) Pero estoy de acuerdo en que podría haber una falta de requisitos o comprensión de ellos

El equipo tarda demasiado en desarrollar funciones, superando la estimación de entrega esperada. El equipo no toma la iniciativa de revisar historias futuras durante el intervalo entre la planificación 1 y 2

Eso nuevamente me llevará a la preparación (debe ser la única sesión en la que prepare el trabajo pendiente para el trabajo futuro; en sus palabras, es la Planificación 1), luego la planificación (sesión 2) es donde toma y planifica el trabajo en su próximo sprint. Tomar demasiado tiempo para la estimación podría significar que la historia no fue dimensionada/explicada/trabajada correctamente. Para mí, parece que hay una falta de comprensión, proceso y trabajo en equipo (no en general, pero parece que este equipo solo necesita entrar en un ritmo)

Mirando el tamaño del equipo, divídalos en 2 equipos, es demasiado grande para un solo equipo (la recomendación es 7 +- 2) de esa manera puede medir los equipos individualmente y verificar el trabajo, etc. como un equipo tan grande debe ser un desafío administrar

¿Los líderes de equipo están dedicados a los equipos/escuadrones? como si no lo estuvieran, no deberían estar involucrados en la estimación, etc. :)

En algún momento, cuando todo el proceso, etc., se resuelva y aún no funcionen, es posible que deba observar el rendimiento individual, ¡pero ese debería ser el último recurso!

Calcule la velocidad del equipo tomando la cantidad promedio de puntos de historia que el equipo logró entregar en los últimos 3 sprints. Usa la velocidad como la capacidad del equipo para futuros sprints.

Al hacer esto, tendrá una cantidad realista de trabajo en cada sprint y podrá proporcionar una estimación mucho más confiable a su cliente.

Una vez que esté haciendo una cantidad realista de trabajo en cada sprint, puede pasar algún tiempo en las retrospectivas resolviendo los otros problemas.

Otro pensamiento inmediato es que es posible que desee colocar la "recopilación de requisitos" y la "determinación de lo que se necesita para cumplir con esos requisitos" antes o incluso entre sus sprints. Tal vez tenga un par de días sin sprint entre cada sprint en los que se prepare adecuadamente para lo que debería ser el próximo sprint, usando esto para guiar la selección del equipo sobre qué incluir. Deles "un sprint completo de dos semanas para lograr" lo que se propusieron lograr. Llevo mucho tiempo desarrollando software para (koff, koff...) y realmente no veo cómo alguien podría hacer todas estas cosas que describe "en dos semanas". Olvida, por un momento,dice, y busque una secuencia de trabajo diferente que sea más realista para su caso. Cada organización es diferente, y está bien.