El equipo no cumple constantemente los objetivos del sprint

Somos una pequeña empresa de software con un solo producto.

Usamos scrum , y nuestros desarrolladores eligen las características que desean incluir en cada sprint. Desafortunadamente, durante el último período de 18 meses, el equipo no ha entregado ni una vez las características con las que se comprometió durante un sprint.

He leído muchas publicaciones / respuestas que indican algo como "el software se hace cuando se hace, no antes, no más tarde ... no ayuda a presionar al equipo, a poner más gente en él, ... "Recibí comentarios similares de uno de los desarrolladores sobre mi pregunta de cómo podemos mejorar la tasa de éxito de los sprints. Ah, y sí, utilizamos retrospectivas .

Mi pregunta es básicamente:

¿Cuándo es justo buscar el problema en la calidad de los desarrolladores?

Estoy empezando a pensar que si eliges tu propio trabajo / características y aún fallas cada sprint: - No puedes supervisar la complejidad de tu propio código; - o el código es tan complejo que nadie puede supervisar la complejidad.

¿Me estoy perdiendo de algo?

Primero debes preguntar, 'a quién le importa'?

Completar los sprints se siente bien y, en algunas empresas, se obtienen cookies del scrum parent. Pero la prueba final es si la compañía está cumpliendo sus objetivos.

Lo anterior es gracioso. Si la compañía tiene éxito sin completar el contenido planeado de un sprint, también podría usar Kanban: clasifica el trabajo atrasado, trabaja en lo más importante y no se preocupa tanto por las iteraciones definidas.

Uno de los valores de las iteraciones definidas es impulsar la mejora del proceso (o expulsar a los de bajo rendimiento en algunas mentalidades). No estás entendiendo eso ahora. Por lo tanto, puede adoptar el resto del proceso que mejora el proceso (y eventualmente completa los sprints), o puede decidir que le gusta lo que tiene.

¿Me estoy perdiendo de algo?

¡SI!

Pasaste 18 meses , o en algún lugar en el vecindario de 36 sprints con retrospectivas, pero de alguna manera no pudiste solucionarlo. ¿La administración no responsabilizó al equipo, y luego su administración no los responsabilizó por no responsabilizar al equipo?

Te estás perdiendo que tu empresa es ampliamente incompetente .

Entonces, cómo solucionarlo. Usted (el desarrollador) deja de comprometerse con tanto trabajo. Si las historias son tan grandes que no puedes hacer eso, entonces debes dividir las historias en trozos más pequeños. Y luego tienes que responsabilizar a las personas por hacer lo que dicen que harán. Si resulta que solo pueden obtener una pequeña característica en cada sprint, entonces descubran por qué y mejoren (lo que puede implicar reemplazar al desarrollador). Si resulta que no pueden descubrir cómo comprometerse con cantidades razonables de trabajo, los despide .

Pero antes de eso, miraría a la gerencia que dejaba las cosas por tanto tiempo, y descubriría por qué no están haciendo su trabajo.

Me gustaría sugerirle que haga un pequeño cambio y pruebe Kanban durante un par de semanas en lugar de Scrum . Puede funcionar mejor para su equipo.

Mientras Scrum impulsa la productividad al limitar el tiempo de trabajo disponible en un sprint, Kanban impulsa la productividad y la velocidad al limitar la cantidad de problemas activos y concurrentes. La estimación del tiempo ya no es parte del proceso. ( fuente )

En pocas palabras, ¿qué es Kanban?

Kanban también es una herramienta utilizada para organizar el trabajo en aras de la eficiencia. Al igual que Scrum, Kanban alienta el trabajo a dividirse en fragmentos manejables y utiliza un tablero Kanban (muy similar al tablero Scrum) para visualizar ese trabajo a medida que avanza en el flujo de trabajo. Cuando Scrum limita la cantidad de tiempo permitido para realizar una cantidad particular de trabajo (por medio de sprints), Kanban limita la cantidad de trabajo permitido en cualquier condición (solo algunas tareas pueden estar en curso, solo muchas pueden estar en -lista de tareas.)

¿En qué se parecen SCRUM y Kanban?

Tanto Scrum como Kanban permiten que las tareas grandes y complejas se desglosen y completen de manera eficiente. Ambos valoran mucho la mejora continua, la optimización del trabajo y el proceso. Y ambos comparten un enfoque muy similar en un flujo de trabajo altamente visible que mantiene a todos los miembros del equipo informados sobre WIP y lo que está por venir.

Vea el resto de los detalles de este enlace

Mi pregunta es básicamente: ¿cuándo es justo buscar el problema en la calidad de los desarrolladores?

No hay suficiente información en su publicación para responder esa pregunta. No hay forma de saber si están fallando porque son incompetentes, o si están fallando porque se comprometen a hacer más trabajo de lo razonable.

Si soy un desarrollador increíblemente talentoso, en un equipo de desarrolladores increíblemente talentosos, y no terminamos las historias X en dos sprints (¡o 36!), ¿Somos incompetentes? O, ¿acaso apestamos en la estimación? Eso depende de si las historias fueron "crear una pantalla de inicio de sesión" o "enviar a un hombre con seguridad a Marte".

El problema comienza con malas historias y / o malas estimaciones.

La estimación es difícil. Realmente difícil. Los humanos lo chupan, por eso Scrum nos hace dividir el trabajo en bloques que no deberían tomar más de un día o dos, y reunir pequeños grupos de esos bloques que estamos seguros de que podemos completar en un corto período de tiempo. . Cuanto más grandes son los bloques, y cuanto más largo es el período de tiempo, menos precisas son nuestras estimaciones.

¿Cómo son tus tiendas? ¿Están bien escritos, con buenos criterios de aceptación? ¿Son lo suficientemente pequeños como para hacerlos en unos pocos días? Sin historias bien escritas (que es culpa de todo el equipo de desarrollo, incluido el propietario del producto), no se puede esperar que el equipo haga una buena estimación.

El problema se agrava por las malas retrospectivas.

Lo que estás haciendo mal, aparentemente, es que no estás aprovechando las retrospectivas. Has pasado 18 meses sin resolver este problema, por lo que el equipo no se da cuenta del problema o no lo aborda en sus retrospectivas.

¿Cada retrospectiva finaliza con al menos un elemento de acción para que el equipo realice, para mejorar en el próximo sprint? ¿Cada retrospectiva incluye hablar sobre los elementos de acción del sprint anterior para ver si se realizaron y si fueron efectivos?

La solución no es culpar, es aprender

El primer paso debería ser dejar de buscar la culpa y, en cambio, comenzar a trabajar para mejorar el equipo. Su equipo probablemente no sea incompetente, solo es malo en la estimación y planificación. Obliga al equipo a terminar un sprint, incluso si eso significa que escogen una sola historia y terminan una semana antes. Si no pueden hacer eso, entonces son incompetentes o las historias son simplemente demasiado complejas. La respuesta a esa pregunta debería ser obvia.

Una vez que puedan terminar la historia, sabrán con certeza razonable que pueden hacer X cantidad de puntos de historia en un sprint. Las matemáticas simples ayudarán a responder la pregunta de si pueden hacer más historias o no.

La mejora continua es la solución.

Una vez que terminan una historia en un sprint, es hora de ver si pueden hacer dos. Enjabonar, enjuagar, repetir. Cuando comienzan a fallar los objetivos de sprint, has encontrado el límite para sus habilidades de estimación. Regrese a la cantidad de puntos de la historia anterior y manténgalo por un tiempo.

En todo momento, tome en serio las retrospectivas. Si no terminaron un sprint, descubra por qué y actúe en consecuencia. ¿Tenían demasiadas incógnitas? ¿Tienen la combinación incorrecta de habilidades? ¿Qué tan buenas fueron sus estimaciones? Si estimaron que una historia tenía X puntos, ¿requería una cantidad relativamente igual de trabajo que las historias de priorato que valían X puntos? Si no, use eso para ajustar los puntos de las historias en el futuro.

Dices que "usas retrospectivas". Pero, ¿qué hace realmente el equipo en estas retrospectivas? Como llevas 18 meses sin abordar este aspecto de tu proceso, supongo que la respuesta es: nada muy útil.

Para mí, la retrospectiva es la parte más importante del proceso. Deseche o cambie cualquier otra cosa sobre scrum todo lo que desee (por mutuo acuerdo del equipo durante una retrospectiva, por supuesto), pero comprométase a tomarse el tiempo regularmente para hablar sobre cómo funciona el proceso para todos, compartir lo que funcionó y lo que no hizo. trabaje y proponga ideas para mejorar. Sigue intentando mejorar tu proceso poco a poco cada sprint y, tarde o temprano, puedes tener algo que funcione bastante bien.

En su caso, ese proceso no parece estar funcionando. Dado que no se están cumpliendo los objetivos de sprint, es prudente que un enfoque retrospectivo de por qué este es el caso. Obviamente, el equipo asumió demasiado trabajo para el sprint. ¿Pero por qué hicieron eso?

• ¿Subestimaron la complejidad del trabajo?
• ¿La gerencia los presionó para que hicieran más trabajo del que el equipo pensó que podría manejar?
• ¿Tuvieron demasiadas interrupciones / emergencias que le quitaron recursos para completar el trabajo planificado?
• ¿Experimentaron cuellos de botella que retrasaron la finalización del trabajo (por ejemplo, esperando los activos de un equipo de diseño externo)?
• E incluso: ¿fueron uno o más miembros del equipo incapaces de hacer el trabajo?

Este es el tipo de preguntas que el equipo debería haberse hecho cada sprint durante los últimos 18 meses. Luego, armados con las respuestas, pueden proponer mejoras de proceso sugeridas para el próximo sprint. Estos pueden incluir:

• Haz menos trabajo en el próximo sprint (¡duh!)
• Sea más conservador en las estimaciones.
• Dígale a quien nos esté presionando para que hagamos más trabajo para acabar, ya que estamos asumiendo más de lo que podemos lograr en este momento
• Administre mejor las interrupciones y ajuste la cantidad de trabajo en el próximo sprint para acomodar emergencias inevitables
• Arregle los cuellos de botella o planifique los que no puede evitar.
• No asigne historias a los miembros del equipo que no pueden cumplirlas (y separadamente, calcule la respuesta de la gerencia para abordar una situación con un miembro del equipo con bajo rendimiento, desde la capacitación y la tutoría hasta el despido)

Este es el tipo de conversación que debería haber sucedido en cada sprint durante los últimos 18 meses. No se trata de presionar al equipo o agregar más recursos, sino de usar sus retrospectivas para mejorar su proceso de forma continua. Eso claramente no está sucediendo aquí.

Uno pensaría que para el 15 ° sprint con goles perdidos, el equipo habría discutido esto en su retrospectiva tantas veces, hasta el punto en que decidieron asumir los objetivos de sprint más mínimos posibles solo por el hecho de completar uno. Para el 25 ° sprint incompleto, solo haría un sprint con un solo cambio de cadena y nada más. Si el equipo no puede manejar eso en un sprint, los problemas son aún peores de lo que usted deja ver.

Para ser claros, como varios aquí ya han señalado, los objetivos de sprint son pronósticos, no compromisos de hierro, y los objetivos perdidos no son en sí mismos indicativos de nada más que hacer pronósticos inexactos. Un gran equipo puede perder toneladas de goles porque son malos pronosticadores, mientras que un equipo horrible puede cumplir con todos y no ofrecer ningún valor real. Pero si sus pronósticos son incorrectos en la misma dirección durante 18 meses seguidos, esa parte de su proceso no está funcionando. Use sus retrospectivas para arreglar el proceso de modo que sus pronósticos estén razonablemente cerca de la realidad real de lo que el equipo puede entregar en cada sprint.

"El software se hace cuando se hace, no antes ni después".

Esto es cierto, pero para cada tarea en la que sus desarrolladores comienzan a trabajar, ¿ entienden todos los miembros de su organización la Definición de Hecho para cada tarea?

Parece que uno de sus mayores problemas es la Estimación , pero los desarrolladores solo pueden proporcionar una estimación realista cuando tienen una 'definición de hecho' inequívoca y claramente especificada. (Que incluye problemas de procesos de la compañía, por ejemplo, documentación del usuario, paquetes de trabajo en una versión formal, etc.)

No es sorprendente que la sobreestimación esté causando un problema, dado que la mayoría de los desarrolladores ven que estimar el tiempo requerido para completar una tarea es lo más difícil que se les pide.

Sin embargo, la mayoría de los desarrolladores tienden a tener un manejo razonable (aunque optimista ) de la cantidad de esfuerzo que pueden realizar, durante un período de tiempo determinado.

El problema a menudo es que los desarrolladores luchan por crear una relación entre una tarea y la cantidad total de esfuerzo que se requiere cuando se trata de información incompleta, especialmente si se les presiona para que presenten todas las respuestas por adelantado a una tarea realmente enorme. .

Naturalmente, esto lleva a que las estimaciones de tiempo se desconecten de la realidad y pierdan de vista cosas como el proceso de compilación y la documentación del usuario.

La desconexión tiende a comenzar desde el principio cuando se describe la tarea; y generalmente está compuesto por una persona no técnica que elabora una lista de requisitos sin tener idea de la cantidad de esfuerzo necesario.

A veces, las personas en la alta gerencia especifican tareas e ignoran por completo los problemas del proceso de la compañía; No es raro que la alta gerencia piense que cosas como la definición de pruebas, o la creación de una compilación formal lanzada, o la actualización de un documento de usuario sucede mágicamente sin tiempo ni esfuerzo. necesario.

A veces los proyectos fallan antes de que un desarrollador haya escrito una línea de código porque alguien, en algún lugar, no está haciendo su trabajo correctamente.

Si el equipo de desarrollo no está involucrado en la aceptación de los requisitos o la captura de los criterios de aceptación, entonces eso es un fracaso de la administración, porque significa que alguien que no tiene una comprensión suficiente del código y los problemas técnicos ha comprometido a la empresa a un conjunto incompleto de requisitos, y dejó el proyecto abierto a interpretaciones erróneas, fluencia del alcance, chapado en oro, etc.

Si el equipo de desarrollo está involucrado en la captura y el acuerdo de los requisitos, entonces podría ser una falla del equipo, quienes son responsables de aclarar los detalles (y los criterios de aceptación, es decir, "¿Cómo se ve el producto entregable? ¿Cuándo se hace ?" ) El equipo de desarrollo también es responsable de decir NO cuando hay otros problemas de bloqueo en el camino, o si un requisito no es realista.

Entonces, si los desarrolladores están involucrados en la captura de requisitos:

• ¿Tiene el equipo la oportunidad de sentarse con el gerente de producto para aclarar los requisitos / definición de hecho?
• ¿El equipo hace suficientes preguntas para aclarar los requisitos implícitos / asumidos? ¿Con qué frecuencia se responden satisfactoriamente esas preguntas?
• ¿Exige el equipo los criterios de aceptación (definición de hecho) antes de proporcionar una estimación?
• ¿Qué tan bien se capturan los criterios de aceptación para cada tarea? ¿Es un documento vago con pocos detalles o describe una funcionalidad tangible y una redacción que un desarrollador podría traducir inequívocamente en una prueba?

Lo más probable es que la productividad de su equipo no sea un problema; su equipo probablemente esté haciendo todo el esfuerzo que puedan poner en relación con el desarrollo. Sus problemas reales podrían ser uno o más de los siguientes:

• Requisitos incompletos y vagos.
• Requisitos / tareas que son demasiado grandes en primer lugar.
• Mala comunicación entre el equipo de desarrollo y la alta dirección.
• Falta de criterios de aceptación claramente definidos antes de entregar las tareas al equipo.
• Especificación incompleta o vaga / ambigua de las pruebas de aceptación. (es decir, definición de hecho)
• Tiempo insuficiente asignado para definir / acordar los criterios de aceptación.
• Los desarrolladores no consideraron el tiempo para probar el código de línea base existente o corregir errores existentes
• Los desarrolladores probaron el código de línea base existente pero no detectaron los errores como problemas de bloqueo antes de proporcionar estimaciones sobre los requisitos.
• La gerencia vio los problemas / errores y decidió que no es necesario corregirlos antes de escribir un nuevo código.
• Los desarrolladores están bajo presión para dar cuenta del 100% de su tiempo, aunque posiblemente el 20% (o un número similar) de su tiempo probablemente sea ocupado por reuniones, distracciones, correos electrónicos, etc.
• Las estimaciones se acuerdan a su valor nominal y nadie ajusta el margen de error o contingencia (por ejemplo, "Decidimos que esto debería tomar 5 días, por lo que esperamos que se haga en 8").
• Los estimados son tratados por todos (desarrolladores y administración) como números únicos en lugar de números de "rango" realistas, es decir
  • Estimación del mejor caso
  • Estimación realista
  • Estimación del peor de los casos

... la lista podría durar mucho más que eso.

Debe hacer algunos "hallazgos de hechos" y descubrir exactamente por qué las estimaciones están constantemente desconectadas de la realidad. ¿Es malo el software de línea base existente? ¿Carece de cobertura de prueba unitaria? ¿Sus desarrolladores evitan la comunicación con la administración? ¿La administración evita la comunicación con los desarrolladores? ¿Existe una desconexión entre las expectativas de la administración y las expectativas del desarrollador cuando se trata de "Definición de hecho" ?

¡Mi consejo para reiniciar el equipo es elegir la historia más pequeña posible por equipo, por sprint y completar esa historia, y solo esa historia!

Estoy de acuerdo con los otros carteles, o el equipo es incompetente o están tratando de hacer demasiadas cosas.

Comience con las cosas más pequeñas, las historias más cortas y complete un solo sprint. Haga que el equipo termine un sprint y tenga éxito, y les ayudará a ver cómo priorizar sus compromisos de tiempo y trabajo. Con el tiempo, el equipo podrá asumir más y más trabajo hasta que alcancen su máxima productividad.

Debería recopilar datos y generar niveles de confianza basados ​​en el rendimiento anterior.

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

El ejemplo más simple es con sprints de tiempo constante, como cada dos semanas. Calcule cuántos puntos de historia terminará el equipo dentro de las dos semanas. Luego, después de que termine el sprint de dos semanas, vea cuántos puntos de la historia se completaron realmente. Con el tiempo, es posible que vea que estima 15 puntos, pero solo termina 10. En ese caso simple, puede comenzar a avanzar con un ajuste de velocidad, por lo que solo planifica 10 puntos por sprint. O que planea terminar el 66% del trabajo estimado.

Al construir niveles de confianza con desviaciones estándar, puede decirle a la gerencia: de acuerdo con los objetivos actuales del proyecto, esperamos solo un 50% de confianza que podemos terminar en 3 semanas, pero un 95% de confianza que podemos terminar en 5 semanas.

La idea detrás de Agile y Scrum es crear un ciclo de retroalimentación ajustado para que pueda evaluar su proceso. Tienes que preguntar "¿Dónde se rompió eso?", Ya que parece haberse descompuesto por completo.

1. Planifique lo que va a hacer y haga una lista
   • Esto debería consistir en elegir elementos de una lista de elementos pendientes que deben completarse. Antes de que algo sea incluido en la lista de tareas para el sprint, el equipo debe estar de acuerdo en que lo entienden completamente y que estiman aproximadamente que tomará menos de un sprint en completarse.
   • Idealmente, la cartera de pedidos está ordenada por prioridad (para el negocio) y usted puede obtener el orden de prioridad.
   • Si los elementos de la cartera de pedidos son demasiado grandes, divídalos en trozos más pequeños. Luego divida los fragmentos en tareas individuales que se pueden completar en un día o menos.
   • No esperes que esta planificación sea fácil o rápida.
2. Ejecutar en elementos de la lista durante un período de tiempo definido (un sprint)
3. Revisa lo que lograste
   • ¿Qué historias se terminaron?
   • Si no se terminaron las historias, ¿qué tareas se inventaron?
   • Si no se terminaron las tareas, ¿qué hicieron exactamente todos el lunes pasado? El martes pasado, etc., en este punto, es hora de una introspección severa ...

4. Solucione los problemas (analice los comentarios y adáptelos)

   • ¿Cuánto tiempo tomaron las cosas que terminaron?
   • ¿Qué evitó que se completaran las tareas?
   • ¿Los miembros del equipo dividen las historias (características) en tareas que se pueden completar en 1 día o menos? Si no, haga esto y hágalo parte de la lista de tareas.
   • ¿Qué cambios se hicieron en la lista de tareas o en los elementos de la lista de tareas durante el sprint? ¿Era esto una causa para no terminar? Si es así, no cambie la lista o las características. Lanza la función modificada en la cartera de pedidos hasta que sea estable.
   • ¿Cómo se puede reducir el tamaño y el alcance de algunos elementos a algo que se pueda terminar en un sprint? Elija algo pequeño como una mejora en el registro, una simple corrección de errores, un error tipográfico, solo para terminar algunas cosas y permitir que el equipo obtenga una idea de lo que pueden hacer. Si no puede hacer esto, deje de correr y vuelva a planificar .

5. Regrese al paso uno y repita hasta el lanzamiento ...

¿Hay obstáculos de documentación, problemas de acoplamiento que crean dependencias, problemas de comunicación, información insuficiente en los requisitos? ... ¿Qué? ¿Los desarrolladores pasaron su tiempo tratando de aprender nuevas tecnologías? ¿Pasaron grandes cantidades de tiempo en diseño? ¿Se incluyeron cosas como el aprendizaje en la lista de tareas de sprint?

¿Creías que tu equipo creía que habían aislado sus problemas en cada retrospectiva? ¿Actuó el equipo para corregir los problemas? ¿El equipo no respondió y la administración simplemente dictó las soluciones y el curso de acción?

Dado el largo período de tiempo, algo está mal sistémicamente, no simplemente con los desarrolladores. En algún momento (antes de un año subió) alguien en el equipo (incluyendo el scrum master) debería haber pedido, lo que, por pequeño que sea, puede que logramos?

En su situación, las retrospectivas son demasiado tarde.
¿Está celebrando reuniones diarias y realmente está obteniendo el estatus de las personas sobre lo que hicieron en las últimas 24 horas?
¿El scrum master está usando esas reuniones para medir el progreso de cada desarrollador con respecto a sus objetivos?
Debe usar esa parte de la metodología Scrum para monitorear el progreso a medida que avanza. Debería darle una buena idea de lo que la gente está haciendo.
¿Están distraídos? ¿Pasas demasiado tiempo tomando café, o ayudando a otras personas en SE / SO, o leyendo las noticias, o haciendo inspecciones que no se tienen en cuenta? ¿O están realmente caídos, a toda máquina y completamente comprometidos? La vista diaria debería darte una buena idea. También ayudará a mantener a los desarrolladores centrados en la tarea en cuestión, para que no tengan que admitir que no hicieron nada ayer.
Y, por supuesto, si informan un progreso constante durante todo el sprint y aún no se entregan al final, entonces estaban mintiendo y podría ser hora de un nuevo desarrollador.

Es difícil estimar el esfuerzo y el tiempo necesarios para completar una tarea compleja, como el código de programación. Como dice Joel Spolsky :

A los desarrolladores de software realmente no les gusta hacer horarios. Por lo general, intentan escapar sin uno. "¡Se hará cuando esté hecho!", Dicen, esperando que un zinger tan valiente y divertido reduzca a su jefe a un ataque de risitas, y en la jovialidad resultante, se olvidará el horario.

Sin embargo, las empresas necesitan plazos para operar. Como sugirió Joel, intente usar la programación basada en la evidencia que generará estimaciones de tiempo con probabilidad asociada, con lo que la administración puede relacionarse como cualquier tipo de riesgo.

Scrum hace algunas cosas.

Primero, alienta la priorización. El proveedor de trabajo tiene que decir lo que quiere que se haga primero, y no decir "todo es igualmente importante".

En segundo lugar, genera un producto algo utilizable, incluso si no todo está terminado. Ese es el punto de tener un "producto potencialmente exportable" al final de cada iteración.

Tercero, da un ciclo de retroalimentación más estricto. Al insistir en que las cosas se "hagan" al final de un sprint, se evita el problema "90% de características completadas, pero solo a mitad de camino"; al presionar por los plazos, puede apartar las cosas que deben hacerse a un lado para que parezca que casi alcanza el plazo, o puede fingirlo. Al tener una definición de hecho e insistir en que se hagan las cosas, usted sabe si algo es más difícil de lo que parece antes que tarde.

En adelante, evita el inventario al acercar la planificación detallada a hacer el trabajo. Planificar las cosas a distancia es una forma de inventario: capital gastado en recursos que no están disponibles para la venta o el uso inmediato de los clientes. Dicho inventario puede pudrirse (los planes cambian bajo los pies, la nueva información lo hace obsoleto), desalinearse con las necesidades (resulta que no necesitamos una red distribuida, porque lo que lo usaba no valía la pena) y reducir el valor de los productos enviados (si en el último año la mitad de su tiempo se dedicó a la planificación para el próximo año y más allá, podría haberse enviado el doble si hubiera trabajado en cosas para estar listo por ahora). Si puede acercar la planificación a la ejecución sin pérdida (¡complicado!), Puede disminuir el inventario.

No es la única forma de resolver estos problemas. Parece que está utilizando scrum donde proporciona una secuencia de trabajo para que los desarrolladores trabajen en cada período de tiempo, agregando periódicamente nuevos trabajos para hacer y verificando el progreso.

Esta es una forma útil de usar patrones de scrum-esque. Mantiene el flujo de trabajo, sigue planificando cerca de la producción, proporciona algunos bucles de retroalimentación, etc. Incluso tiene ventajas ya que no distorsiona el desarrollo y las pruebas para que coincida con el sistema (si la prueba se realiza mejor con el trabajo básicamente está terminado , ¡tratar de terminar y probar las cosas dentro del mismo sprint obliga al back-end del sprint a no involucrar nuevos desarrollos!)

El hecho de no poner exactamente lo que van a hacer en un sprint no evidencia que sus desarrolladores no estén haciendo un gran trabajo. Significa que no están siguiendo SCRUM desde lo alto, sino que usan partes del marco.

Si hubieran reducido a la mitad (o descuartizado) cuánto se comprometieron con cada sprint, pero mantuvieron todo lo demás igual, ¡entonces habrían terminado más de lo que se comprometieron con cada sprint! Tendría la misma cantidad de código producido. Claramente, las "fallas de sprint" no son la parte importante, porque eso es solo un detalle interno del proceso. El objetivo de la compañía es hacer una mierda, y esa mierda sea buena; no seguir algún proceso específico, a menos que su objetivo sea un cierto tipo de certificación de proceso ISO.

El proceso existe subordinado al objetivo de las cosas hechas.

Por otro lado, debido a que no están siguiendo las reglas de SCRUM, no estás recibiendo el mismo tipo de comentarios. Debe examinar las cosas resultantes para ver si el tipo de defectos producidos son los defectos con los que SCRUM fue diseñado; ¿Hay historias que viven como zombies para siempre, y solo mueren muy tarde? ¿Hay historias que parecen fáciles, explotan y en una retrospectiva donde no vale la pena el trabajo total? ¿El producto se puede enviar en el momento en que lo necesita / desea enviar?

"El software se hace cuando se hace, no antes, no más tarde" es una receta para el fracaso si no ha definido cómo se ve "hecho".

La mayoría de los ingenieros tratarán de producir la mejor solución posible, pero esto puede conducir fácilmente al enchapado en oro, especialmente con ingenieros menos experimentados. Las únicas responsabilidades de la administración son definir exactamente dónde está el objetivo y mantener a sus ingenieros en esa dirección. Con frecuencia, los ingenieros tratarán de dar un giro lateral para mejorar las características, y depende de la gerencia decidir si ese giro lateral acelerará las cosas a largo plazo, o si solo está mejorando por lo mismo de mejorar.

El punto de desarrollo ágil es que cada nuevo trabajo debe ser tan bueno como sea necesario para cumplir con ese sprint ¡ Y NO MEJOR! Sí, ese es el mayor énfasis que puedo agregar en StackOverflow, y todavía no es suficiente énfasis. Si encuentra que las personas están agregando cosas que no se requieren en este momento, entonces necesitan capacitación sobre cómo hacer un desarrollo ágil correctamente.

Ah, y sí, utilizamos retrospectivas.

Oh bien, entonces sabes por qué tu equipo está fallando, ¿verdad? Has tenido 36 oportunidades de hablar sobre lo que funcionó y lo que no funcionó, por lo que los maestros de scrum deberían entender completamente cómo resolver los problemas, ¿verdad?

Tengo el presentimiento, por la descripción que da, de que su empresa ha caído en la mentalidad "SCRUM nos hace productivos". La verdad es que SCRUM no te hace productivo. Más bien, es una herramienta para ayudarle a hacer usted mismo productiva de una manera que identifica realidades del desarrollo que están a menudo pasada por alto por la administración y desarrolladores por igual.

¿Qué ha identificado el scrum master como posibles problemas con el equipo? ¿Están asignando constantemente el doble de trabajo que pueden manejar? Si es así, el scrum master debería sugerir gentilmente que trabajen menos, porque el scrum master puede observar la velocidad del equipo.

¿Cuándo es justo buscar el problema en la calidad de los desarrolladores?

El momento en que uno debe buscar el problema en la calidad de los desarrolladores es el momento en que está seguro de que ese es el problema. Este no es un problema nuevo creado por SCRUM. Esta es la realidad de los negocios. SCRUM debería brindarle mucha más información sobre las capacidades de los miembros de su equipo que los enfoques tradicionales. Debe saber si el problema es "los desarrolladores de software no son lo suficientemente buenos" frente a "las expectativas de gestión no son realistas" en un grado mucho mejor de lo que lo entendería con un enfoque tradicional. Este es el momento para que la gerencia haga lo que mejor hace la gerencia: averiguar las personas adecuadas para el trabajo, para que la empresa pueda ganar dinero. Si no puede saber dónde está el problema, ¡imagine lo difícil que sería saberlo sin todas esas retrospectivas!

Si cree que las personas podrían ser lo suficientemente buenas (lo que implica que su contratación no fue un error por parte de la gerencia), entonces mi consejo sería comenzar a pensar fuera de la caja. Si el trabajo no se está haciendo, considere cambiar la forma del trabajo para los desarrolladores. Una de las formas más sencillas que he encontrado para cumplir con los plazos de finalización del sprint es ajustar los criterios HECHOS para que esté satisfecho con el resultado, sin importar cómo se haga. Por lo tanto, completarse se convierte en una tautología.

Esto pone la responsabilidad en la gestión, especialmente el maestro SCRUM. El truco consiste en escribir tareas que, si se completan, son muy valiosas, pero si se dejan incompletas, aún proporcionan suficiente valor agregado a la empresa para que valga la pena su sueldo. Después de 18 meses, esperaría que tus retrospectivas te hayan enseñado algo. Si no lo han hecho, tal vez debería escribir las historias con la intención explícita de historias fallidas para descubrir algo que está mal en su empresa y sacarlo a la luz. Eso proporcionaría a la empresa información inmensa y valiosa, dada la gran frustración que la empresa parece tener con el equipo de desarrollo. El problema puede ser los desarrolladores, como usted pregunta. ¡O el problema puede ser una patología en la mentalidad de la compañía de la que no tenía idea hasta ahora!

Si el problema es con la compañía, no con los desarrolladores, ¡la información que obtenga de estas historias incompletas puede valer más que el producto que recopila de las exitosas! ¡Puede ser la información que salve a toda su empresa! Me parece una información realmente valiosa, y puede usar SCRUM como herramienta para ayudarlo a recopilarla.

"¿Cuándo es justo observar la calidad de los desarrolladores?"

Todo el tiempo. Obviamente, algunas personas son más productivas que otras, no necesita una excusa como empleador para medir su desempeño.

Lo complicado es cómo lo haces. Mi consejo es contratar a algunos contratistas experimentados para que trabajen junto a su personal permanente en el mismo conjunto de tareas estimadas por sus chicos permanentes y ver si tienen una mayor velocidad.

Esto le proporcionará una buena comparación con el mercado actual sin encerrarlo en una contratación a largo plazo.

También podría darles una patada en el culo a los tipos permanentes.

Además, si se quejan de que los contratistas se saltan la calidad, etc. para ganar velocidad, eso conducirá una conversación sobre dónde está el valor comercial. Mantenimiento a largo plazo o productos a corto plazo enviados.

Si se trata de cosas a largo plazo, ¡te obligará a cuantificarlo y dejarlo en el sprint como requisitos!

Ya hay varias respuestas excelentes. En particular, la mala estimación, el exceso de compromiso y / o el trabajo no programado son causas frecuentes de deslizamiento.

Pero tengo curiosidad por saber por qué "[sus] desarrolladores eligen las características que desean incluir en cada sprint". Los desarrolladores generalmente deberían estar trabajando en las características con la prioridad más alta primero, y la prioridad es una decisión comercial, es decir, debe provenir del propietario del producto que actúe como representante de las partes interesadas del negocio.
(Hay excepciones a esto. En particular, las características de alto riesgo generalmente se trabajaron antes. Y en algunos casos, una característica orientada al usuario puede depender de otra funcionalidad, por ejemplo, "realmente necesitamos agregar una base de datos antes de que podamos implementar X". )

Por otro lado, las estimaciones son decisiones técnicas, y no deben ser hechas (o cuestionadas) por personas de negocios. No dice nada sobre esto: planteo el punto solo porque, en mi experiencia, cuando los desarrolladores eligen en qué trabajar, es bastante común que la gente de negocios intente dictar cuánto tiempo debe tomar.

Parece que tienes un proceso bastante disfuncional. Recomendaría no traer consultores de desarrolladores, al menos por el momento, porque eso probablemente tendrá un efecto negativo en la moral. Pero parece que su organización podría necesitar ayuda en el lado de la gestión de proyectos. Ahí es donde comenzaría, trayendo a un entrenador ágil experimentado: si no es para un compromiso a mediano y largo plazo, al menos para una evaluación o "control de salud". Un buen entrenador le dirá si tiene desarrolladores de bajo rendimiento, pero al menos de esta manera, es todo el equipo (no solo los desarrolladores) quienes están bajo escrutinio.

Otra observación: en mi experiencia, es muy difícil hacer que scrum tenga éxito como metodología de gestión de proyectos si no sigue también buenos procesos de desarrollo. ¿Estás haciendo pruebas unitarias automatizadas? o incluso mejor, ¿pruebas de aceptación automatizadas? ¿Están emparejando sus desarrolladores, o al menos realiza revisiones y / o tutoriales frecuentes de códigos? ¿Estás practicando alguna forma de integración continua?