Tenemos una velocidad de cero

El primer paso es obtener cualquier estimación para incluir a todo el equipo. En lugar de solo los desarrolladores estimando el esfuerzo de desarrollo, la estimación debe consistir en el esfuerzo y la complejidad de todo el equipo necesario para terminarlo y realizar pruebas con éxito. Si combina esto con no volver a estimar y no obtener ningún crédito hasta que se termine el trabajo, también puede reducir la bola de nieve. Me gustaría entender por qué el equipo tiene una reacción adversa a algunas de estas ideas ya propuestas y abordarlas.

Mejorar el refinamiento también puede ayudar. No estoy del todo seguro de lo que quiere decir con la "fase de descubrimiento", pero parece que los equipos están incorporando trabajo al Sprint que no ha sido bien refinado. Si algo es crítico y sensible al tiempo, puede tener sentido comenzarlo antes de que esté bien refinado. La mayoría del trabajo debe estar bien refinado y estimado para la Planificación de Sprint, de modo que el equipo tenga una buena idea del alcance y el esfuerzo necesarios para completarlo.

Una buena Definición de Listo puede ayudar tanto con la estimación como con la planificación. Esta es una forma de garantizar que el equipo comprenda en qué estado se supone que debe estar cada unidad de trabajo, así como el sistema en su conjunto, al final del Sprint.

La automatización de pruebas también ayudaría significativamente, especialmente en sistemas complejos. Tener pruebas automatizadas de unidad, integración y sistema puede ayudar a encontrar problemas temprano si se integran en el proceso de construcción. También puede hacer que sus probadores manuales dejen de ejecutar siempre pruebas de regresión y pasen a realizar pruebas exploratorias y de usabilidad, que requieren el pensamiento humano y conocimientos y experiencias externos.

Me gustaría saber por qué los miembros del equipo están siendo retirados del equipo durante un Sprint. Esto hace que cualquier tipo de toma de decisiones empíricas sea extremadamente difícil. Uno de los valores centrales de Scrum es el enfoque: el equipo debe poder concentrarse en el trabajo y los objetivos del equipo. Esto también se alinea con el principio de desarrollo de software ágil de crear trabajo en torno a equipos de personas motivadas: los equipos generalmente no tienen personas que van y vienen en medio de un juego.

Parece que el mayor problema aquí es la incapacidad del equipo para probar algo nuevo y experimentar. Me gustaría profundizar más en el enfoque de "no es así como lo hacemos aquí". Me pregunto si no hay más preocupaciones fundamentales de confianza o seguridad en el equipo. El equipo necesita estar en un entorno que favorezca la experimentación continua en nombre de la mejora continua. No todos los experimentos pueden ser una mejora, pero esa es la ventaja de las iteraciones rápidas: está haciendo cambios rápidos en el producto para obtener comentarios, pero también puede hacer cambios rápidos en la forma en que hace el producto para obtener comentarios sobre cómo está. construyendo el producto.

Están sucediendo tantas cosas aquí que si tratas de enumerarlas, te sentirás frustrado, como sospecho que ya lo estás.

Comencemos con un simple reconocimiento de que su equipo no está, de ninguna manera, practicando Scrum. Pueden estar haciendo un gran trabajo, pero ni siquiera están tratando de usar Scrum Framework. Esto no pretende ser un juicio sobre el equipo, pero necesita saber dónde se encuentra en este momento.

La siguiente pregunta es: ¿qué es lo que realmente quieren hacer como equipo? ¿Tiene un conjunto fijo de trabajo por el que está pasando y quiere hacerlo sin problemas? Si es así, deje Scrum a un lado y tal vez use algo de Kanban para suavizar su proceso. Por otro lado, si está buscando lanzar pequeños incrementos de productos utilizables que se puedan enviar (y por usted, me refiero a todo el equipo), entonces tal vez comience con eso: al final de cada sprint, enviamos algo, incluso si eso solo significa promocionar a un entorno de ensayo que las partes interesadas pueden probar. Una Definición de Listo será útil para determinar qué significa potencialmente entregable, pero si tiene alguna otra forma de medirlo, está bien. Yo empezaría aquí. Las oportunidades para introducir el resto de las prácticas surgirán a medida que surja la necesidad de ellas.

Me parece que su equipo quiere trabajar, pero no quiere resolver, planificar o rendir cuentas. Bastante común en mi experiencia, generalmente una reacción a la presunción de que la gerencia responsabilizará al equipo por los resultados negativos, pero no por los resultados positivos.

. . . [hay] una explosión combinatoria en la forma en que se pueden usar, de modo que puede ser un desafío probar todos los caminos posibles a través del producto.

En la reunión de planificación, volvemos a estimar las tareas que quedaron del sprint anterior y los desarrolladores vuelven a estimar la mayoría de ellas como esfuerzo cero, ya que están "en revisión" o "en prueba". Al final del sprint, la mayoría de las historias en la columna terminada tienen una estimación de cero puntos de historia y las que no tienen facciones de un punto.

No soy un iniciado en la religión scrum, pero entiendo que una de las suposiciones es que el software no está terminado hasta que se prueba, y el equipo está en el gancho hasta que esté terminado. Lanzar módulos por encima de la valla para realizar pruebas parece estar en tensión con los principios de scrum. Si están en revisión o en prueba, ese es un trabajo que debe hacerse; un equipo multifuncional autoorganizado debe reorganizarse para hacer ese trabajo y debe estimar ese trabajo.

Especulo que la desconexión fundamental es que el equipo está organizado a la defensiva en torno al objetivo de evitar la atención de la gerencia; Creo que el objetivo de scrum es que el equipo se autoorganice en torno al objetivo de enviar software y satisfacer a los clientes.

Al menos en mi experiencia, la percepción de la realidad por parte del equipo es más precisa que la meta del scrum. Según mi experiencia, es muy poco probable que la gerencia reconozca y apoye a los equipos autoorganizados, y es mucho más probable que aliente/facilite/respalde la cultura de gestión tradicional, por lo que es probable que el equipo se esté comportando racionalmente en el contexto de su gestión. (Podría estar equivocado; solo usted y su equipo saben si su estructura de administración/recompensas está basada en scrum o es tradicional).

Entonces, ¿qué haría yo en tus zapatos?

1. Haga la transición del equipo a scrumbut: reconozca que la organización quiere una gestión tradicional con vocabulario scrum.

2. Discuta con el equipo el futuro de su curso de acción. Continuar con la estimación de cero complejidad eventualmente resultará en el envío de cero productos y eso resultará en salarios de cero dólares. Estimar no es un ejercicio para evitar el castigo, es una inversión en trabajo. O estima honestamente, o acepta que trabajará según la estimación (tácita, desinformada) del jefe con el cabello más puntiagudo, el ego más ruidoso y el menor compromiso con la realidad.

3. Discutir con el equipo el valor de la gestión de proyectos. En mi experiencia, los técnicos quieren trabajar en el proyecto. No quieren ir a reuniones, responder preguntas sobre fechas de vencimiento o lidiar con requisitos que cambian como la espuma cuántica. Una pequeña inversión por parte del equipo en una estimación honesta dará como resultado un PM informado que pueda hacerse cargo de las comunicaciones de gestión. Un PM que pueda negociar entre la necesidad de la gerencia de planificar y estimar y la necesidad del equipo de trabajar en la complejidad real de resolver problemas puede ser una gran ayuda para ambas partes.

4. Eso lo libera para trabajar en el problema real: ¿quién es responsable de las pruebas y el control de calidad? Hay formas de trasladar eso al equipo: variaciones del desarrollo basado en pruebas y marcos de pruebas automatizados.

No vuelva a estimar los puntos de la historia que se han caído del sprint anterior, le está diciendo al equipo que su compromiso y los puntos no son importantes y socava el proceso. Tienes que llegar al fondo del por qué. Cuando introduce esta regla, el equipo puede decir que todo el trabajo está hecho, lo que debería llevar a una conversación sobre por qué las tareas no se completaron por completo. Las posibles razones podrían ser...

• La historia se pasó al control de calidad en el último minuto, esto se puede remediar reduciendo su velocidad y monitoreando los efectos. También debe asegurarse de que haya un flujo de trabajo de contenido para los controles de calidad.
• El equipo puede decir que un problema externo o interno los está ralentizando o bloqueando. Debe eliminar este problema o, en el peor de los casos, permitir que se cierren las historias mientras se diseña una solución (se generará una deuda).
  • Usa tus retros para descubrir qué está pasando

Estimación: asumí que estás usando puntos en lugar de tiempo, si es así, asegúrate de jugar al póquer de señalar y adherirte a las reglas simples que todos señalan exactamente al mismo tiempo, esto te ayudará a identificar las discrepancias en las historias, quién no está prestando atención. , Ambigüedad, cuando alguien dice 3 y otro dice 21 sabes que algo pasa. El uso de la complejidad también garantizará que el equipo no se comprometa con el tiempo, sino con la velocidad, lo que los hace menos vulnerables.

Reseñas: todo lo que no estaba en la historia original debe agregarse a la lista de pendientes y priorizarse, no debe simplemente dejar la historia abierta.

Efecto de bola de nieve: esta es probablemente una mezcla de desconocidos, desconocidos y otros factores, como historias mejor refinadas, todas las cosas que necesita explorar en su retro. Espere que su proyecto aumente de tamaño dada la complejidad, asegúrese de que todo el trabajo nuevo tenga prioridad y trabaje en lo que es importante para el propietario del producto.

Con un sistema altamente interdependiente como el que usted describe, las "historias" pueden no ser suficientes como herramienta de medición o como herramienta de diseño de tareas. Necesita incorporar una comprensión... sin duda proporcionada por los expertos del propio equipo... de cómo las "historias" se relacionan realmente con los componentes del sistema subyacente. Porque, "aquí es donde los trabajadores están trabajando realmente, y en lo que están trabajando realmente, para lograr la 'historia'". Pídales que identifiquen qué partes del sistema se verán afectadas por (los diversos elementos de...) cada "historia" y utilícelas para impulsar tanto la estructura de desglose de tareas como su informe.

Porque, seamos realistas... "el software es un nido de dependencias". Y la estructura del sistema no siempre se asigna tan claramente a (digamos...) "historias de usuarios" como la Guía Scrum predica que "debería". Bien, entonces, encuentra lo que funciona para este sistema. Es posible que las historias deban descomponerse, luego asignarse a las interdependencias dentro del sistema, luego reordenarse de alguna manera para reflejar cómo las interdependencias dependen (!) unas de otras, para finalmente llegar a algo que pueda programar y, por lo tanto, administrar. Lo que no quiere que suceda... y que ahora mismo podría estar sucediendo... es "hágalo usted mismo". Donde ocurre el colapso que acabo de describir ,

Aproveche en gran medida a los miembros del equipo para guiar esta idea: ellos conocen mejor el sistema. Son las pymes de aquí. Y muéstreles que, si trabajan con usted en esta idea, el trabajo y la carga de trabajo de todos mejorarán. (¡Y ciertamente, el tuyo también!)