¿Qué sucede si no cumple un plazo en un sprint?

Cuando un sprint “falla”, el equipo analiza las razones de ese error durante la retrospectiva y corrige sus fallas en la próxima iteración; se espera que los sprints fallen en ocasiones, y que los equipos no podrán cumplir con su compromiso total a veces, pero que aún entregarán valor en lo que pudieron lograr durante ese sprint.

Disparar, reprender, escribir a alguien o castigar abiertamente a un miembro de un equipo por esto es tan contrario a los principios de los equipos ágiles y autónomos que es un antipatrón fuerte y desconcertante que debe abordarse de inmediato .

¿Qué sucede si los desarrolladores pierden una fecha límite durante un sprint?

En todas las empresas para las que he trabajado, tanto en funciones de PM como de desarrollador, nadie es despedido. Por lo general, despedir a alguien por no cumplir un plazo es excesivo. Ciertamente no es parte de ágil.

Por lo general, hay un par de posibles razones para la falta de entrega:

1. El trabajo total fue más allá de lo que originalmente se definió.
2. Se agregó más trabajo (alcance / función de arrastre)
3. Los recursos del equipo cambiaron para que la cantidad de trabajo excediera la capacidad del equipo.

El proceso ágil debe incluir las paradas diarias para que se puedan evaluar problemas como los anteriores. El primer ministro tiene dos responsabilidades principales, las comunicaciones y las expectativas de gestión.

Si el equipo estaba haciendo las cosas bien, el hecho de que se iba a perder la fecha límite debería haber surgido durante los levantamientos para que el primer ministro pudiera comunicarse con las partes interesadas para informarles que la fecha límite no se cumpliría. Luego, el plan debería haberse modificado para otorgar más tiempo (extender el sprint) o reducir el trabajo restante para centrarse en las características para la fecha límite.

Al final del sprint, se debe hablar sobre el razonamiento del deslizamiento, para obtener más información sobre lo que lo causó y cómo manejar mejor esos problemas.

El despido de personas tiende a reducir la participación del equipo, ejerce presión sobre los sprints futuros (ya que los recursos disponibles han cambiado) y puede significar más plazos incumplidos.

Dicho esto, si la causa fue que un miembro del equipo no hizo su trabajo, entonces puede ser necesario sacudir al equipo. Es difícil decir de su descripción que se requiere.

En raras ocasiones, eso significa un problema de desempeño o personal en nombre de los desarrolladores involucrados y la administración debe tomar medidas correctivas.

Más comúnmente, eso significa que la planificación se arruinó de alguna manera. La acción correctiva sería saber por qué el tiempo estimado fue BS y descubrir cómo hacerlo mejor la próxima vez. A veces es el exceso de optimismo del ingeniero, a veces es la descomposición inadecuada del problema, y ​​a veces es una dependencia externa (como un cambio de API ascendente) que no se tuvo en cuenta correctamente. Podría, por supuesto, ser una combinación o algún otro factor también …

En general, no es un gran problema; La mayoría de nuestros proyectos tienen un poco de holgura incorporada para dar cuenta del deslizamiento ocasional (o frecuente: – /).

Esto es anormal Tu administración es estúpida y no entiendes nada sobre Scrum.

El desarrollo de software es complejo y es por eso que practicamos Scrum, lo que significa que también es difícil de predecir, por lo que el control empírico del proceso ayuda a inspeccionar nuestro progreso y adoptar cambios si es necesario.

Si el equipo no cumple, entonces deje que el equipo descubra la razón detrás para que puedan mejorar y entregar mejor en futuros Sprints.

Parezca que su administración todavía está en modo de comando y control y asigne trabajo de trabajo al equipo y espere que el equipo entregue lo contrario, el equipo será castigado.

Scrum no puede practicar en un entorno hostil, por lo que el primer entorno de mejora.

Eso parece extremo. Debería ser una cuestión de introspección para el equipo. Después de todos los plazos deben importar. Pero al mismo tiempo es una actividad que vas a realizar muchas más veces. Reaccionar de forma exagerada ante un solo fracaso significa que las personas serán demasiado cautelosas y conservadoras en el futuro. Sobreestimar porque tienes miedo es tan malo como subestimar porque no estás prestando atención.

Para nosotros, lo que decimos que hacemos, y sabemos que deberíamos estar haciendo, es hablar de ello durante la retrospectiva. Averigüe por qué ocurrió y comprométase a planificar mejor en el futuro. Esto no siempre sucede, lo admito, pero es lo que debería suceder.