Muchos libros y artículos de Scrum dicen que un sprint fallido (cuando el equipo no completa algunas características del Backlog de Sprint) no es algo tan malo, sucede de vez en cuando, y puede ser útil si el equipo aprende de sus errores y mejora algo en los siguientes sprints. Y el equipo no debe ser castigado por no completar el trabajo al que se comprometieron.
La forma de "castigar" este tipo de comportamiento es limitando la cantidad de trabajo que los que no terminaron pueden realizar el próximo sprint. Las posibilidades de trabajar en cosas interesantes están desapareciendo. La recompensa por hacer un buen trabajo es más trabajo.
Esto se ve muy bien desde el punto de vista del desarrollador, sin embargo, supongamos que tenemos una compañía de software "Scrum-Addicts LLC" desarrollando algo para clientes serios ("Money-Bags Corporation"):
Los gerentes de Scrum-Addicts sugieren hacer un software para Money-Bags Acuerdan una lista de características, y Money-Bags solicita que se les proporcione una fecha de envío. Los gerentes de Scrum-Addicts consultan a su equipo de scrum y el equipo dice que tomará 3 semanas Sprints de larga duración para completar todas las funciones El administrador de Addumts de Scrum agrega 1 semana para estar seguro, promete enviar el software en 1 mes y firma un contrato con Money-Bags Después de 4 sprints (fecha límite de envío) El equipo de Scrum solo puede entregar el 80% de características (debido a la inexperiencia con el nuevo sistema, la necesidad de corregir errores críticos en características anteriores en el entorno de producción, etc.) Como sugiere Scrum, en este punto, el producto es potencialmente transportable, pero Money-Bags necesita 100% de características, como se menciona en el contrato. Entonces rompen el contrato y no pagan nada.
Scrum-Addicts está al borde de la bancarrota porque no obtuvieron dinero de Money-Bags, y los inversores quedaron decepcionados con los resultados y no están dispuestos a ayudar a la empresa.
Si el lunes te apuesto $ 100 a que lloverá el jueves y no lloverá hasta el viernes, estarías en lo correcto al tomar mi dinero. Si, en lugar de una oportunidad de jugar, lo que desea es un pronóstico del tiempo, entonces necesitamos un contrato que me permita darle un pronóstico actualizado el martes.
Obviamente, ninguna compañía de software quiere estar en el lugar de Scrum-Addicts. Lo que no entiendo sobre Agile y Scrum es cómo sugieren que los equipos deben lidiar con la planificación y los plazos para evitar la situación descrita anteriormente.
Piensa en POR QUÉ MB quiere llevarse la pelota e irse a casa. MB no exigió que el trabajo se realizara en un mes desde el principio. SA prometió el 100% de las funciones críticas en un mes y no cumplió. SA estableció la fecha límite no MB. SA incluso agregó arbitrariamente una semana a la fecha límite. Entonces, ¿por qué es una fecha límite?
Ocasionalmente, cuando compiten por el trabajo, las compañías de software ceden a la tentación de presumir y prometer la luna. Los profesionales establecen cuidadosamente si incluso se requiere una luna. ¿Cuál es la necesidad más crítica de MoneyBags? ¿El 100% de las funciones o un producto en funcionamiento en un mes? ¿Saben siquiera lo que es realmente crítico? ¿Hay algún evento próximo que establezca una fecha límite difícil?
Si yo fuera Scrum-Addicts negociando este contrato, me gustaría saber mucho más sobre las necesidades comerciales de Money-Bags y estructurar el contrato para otorgar tanta flexibilidad como Money-Bags se sienta cómodo. Les enseñaría cómo funciona el proceso ágil para que sepan qué esperar de nosotros.
De esta manera, en lugar de esperar que todo funcione de repente perfectamente en un mes, estarían esperando evaluar el primer producto en 1 o 2 semanas.
Entonces, para resumir, tengo 2 preguntas:
¿A quién culpar? Gerentes, porque es su trabajo hacer la planificación adecuada
El equipo, porque se comprometieron a hacer más trabajo del que podrían
Alguien más
Cualquiera podría haber detenido esta parodia antes de que tengamos un mes más adelante.
Podría ir tan lejos como culpar a Money-Bags Corp por contratar a un equipo que obviamente representaba fraudulentamente un proceso en cascada como ágil. El contrato en sí deja en claro que esto no es ágil. La planificación para hacerse en un mes no lo hace ágil.
Si insiste en que es ágil, es ágil con solo un sprint que dura un mes. Lo cual, sí, no recomendaría porque es, de nuevo, lo mismo que una cascada.
¿Lo que se debe hacer?
¿Qué tal ágil? Entregar algo cada sprint? Obtener comentarios antes de la fecha límite? ¿Sprints de una semana? ¿Qué tal renegociar el contrato draconiano en el momento en que sospechas que la fecha límite está en peligro en lugar de esconderte y orar? Como mínimo, puede dejar de perder el tiempo en un proyecto condenado y encontrar un cliente más razonable.
Los gerentes deben mover la fecha límite 2 veces (o 3 veces) más tarde que la estimación del equipo original.
Los multiplicadores de fechas límite son tan útiles como configurar su reloj 15 minutos antes para que nunca llegue tarde. Solo puedes engañarte a ti mismo tanto tiempo antes de darte cuenta de lo que estás haciendo.
Las primeras estimaciones son incorrectas. Intenta capturar lo equivocado. 5 semanas, más o menos, es una expresión simple que le permite expresar cuán incierta es realmente la fecha de finalización. En lugar de tratar de adivinar con precisión, adivina qué tan salvaje es su suposición. Haga un trabajo real y obtenga algunos datos reales. Entonces puede comenzar a hacer estimaciones con un rango más estrecho. Una o dos semanas es tiempo suficiente para hacer esto.
Se debe alentar a los miembros del equipo a hacer todo el trabajo al que se comprometieron sin importar qué (emitiendo sanciones por sprints fallidos)
Los miembros del equipo deben ser alentados. Fallido, cometido o de otra manera. En lugar de construir cualquier consecuencia artificial, como castigos o incluso bonificaciones (zanahoria y palo), los estudios han demostrado que las personas que realizan un trabajo creativo, como la programación, responden mejor si se les proporcionan tres cosas: autonomía, dominio y propósito.
Daniel Pink tiene una charla TED sobre esto. La charla es sobre la motivación no ágil, pero fácilmente vi cómo mapear estos puntos a ágil:
Autonomía: quiero dirigir mi propia vida. Permítanme elegir el trabajo del trabajo atrasado.
Dominio - Quiero mejorar en algo que importa - Comentarios de los clientes.
Propósito: quiero ser parte de algo más grande que yo: un equipo colaborativo.
El equipo debería abandonar Scrum porque no se ajusta a la política de fecha límite de la compañía. Scrum puede cumplir una fecha límite con mayor precisión que la cascada. Dado un plazo, el scrum puede cumplirlo. Puede cumplirlo con solo 1 de 47 funciones, dependiendo del tiempo, la función y la habilidad, pero puede cumplirlo.
Un proyecto ágil puede diseñarse tan extremadamente que cada noche, cuando el equipo se va a casa, está listo para enviar. Esto parece una tontería a menos que pienses en el envío como pedirle al cliente que pruebe y proporcione comentarios. Cuanto antes suceda, antes podrá hacer ajustes. Esto llega a todos los plazos posibles. Simplemente no todas las características. Pero te lleva a las características que importan.
Todos deberíamos abandonar el desarrollo de software y unirnos a un monasterio
Bien, como encerrarme en una habitación lejos de la vida real me va a hacer escribir MENOS código.
He editado esta respuesta a medida. Si tienes curiosidad, lee el historial de edición.