En una empresa, han estado tratando de implementar scrum por algo menos de un año y han logrado un buen progreso. Sin embargo, en los últimos 4-5 meses y antes del lanzamiento del software, la gerencia y el PO han estado agregando cosas en el sprint todo el tiempo ., alterando así la prioridad y el enfoque del sprint. Al final de los sprints, las cosas están a medio hacer, o no han comenzado en absoluto, y algunas están hechas. Sin embargo, esto parece estar bien, ya que se entregarán en el próximo sprint, o en el sprint posterior. El PO y la gerencia saben que no deberían estar haciendo esto, sin embargo, el tiempo es muy limitado para lanzar el nuevo producto y si no hay negocios, no hay equipo y, por lo tanto, no hay scrum. Los scrums de la mañana son un informe al gerente de lo que está sucediendo y un ping pong de sugerencias para posibles soluciones. El técnico insiste en que este es el foro adecuado para coordinar al equipo.
Por otro lado, el gerente ha informado que quiere mantener los valores de scrum y progresar en el equipo, es solo que en este momento, el tiempo es esencial y las cosas deben entregarse lo antes posible antes de la fecha límite. El Scrum Master, al ver el problema, entiende que las prioridades seguirán surgiendo, los sprints seguirán cambiando y ha renunciado a intentar cambiar esto; también entiende que ciertas piezas del software tienen que llegar con urgencia para poder ser entregadas. Además, se añaden "adiciones de último momento", aunque imprescindibles, en el sprint o backlog, que hay que hacer mañana (a veces estas últimas son, objetivamente hablando, no negociables, ya que tienen que ser entregadas para que el software funcione) .
Para colmo, la empresa tiene problemas en su infraestructura, como entornos que no funcionan y el desarrollo se detiene aproximadamente el 20 % del tiempo debido a dependencias externas.
La empresa tiene compromisos con los clientes que está tratando de cumplir. Por lo tanto, por un lado quieren hacer scrum, por el otro parece una metodología en cascada etiquetada como "scrum".
¿Hay esperanza en esta empresa en términos de apreciar lo que se necesita hacer para comenzar a implementar scrum? ¿Cómo pueden dejar de agregar cosas en la acumulación de sprints y concentrarse en entregar sprints completos en lugar de tener historias a medio hacer al final?
En primer lugar, cada vez que se agregue algo al Sprint, pregunte al PO qué historia o historias deben eliminarse. Esto no es opcional. (A menos que descubras que realmente subestimaste para ese Sprint y realmente tienes espacio para agregar cosas. Sin embargo, esto no debería suceder con frecuencia). entonces los gerentes quieren agregar otros 3 puntos de historia, no podrás completar mágicamente 13 puntos de historia . Hay que sacar tres puntos, manteniendo así la estimación del sprint. Esto no solo combate el problema de tener muchas historias 'a medio completar' al final de un sprint (suponiendo que la estimación original fuera adecuada), sino que también tiene el beneficio adicional de reducir algunos de los costos de estas 'adiciones de último minuto'. ' claramente visible.
"Quiero la historia G".
"Está bien, ¿le gustaría que eliminemos la historia A, o las historias B y C, para dejarle espacio?"
"No, no puedes eliminar ninguno de ellos".
"Está bien, entonces no podemos completar la historia G. Elija dos para conservar: A, B y C, o G".
"Bien. Quita A, entonces."
(Lapso de tiempo)
"¡¿Por qué la historia A no está completa?!"
"Bueno, aquí tenemos este correo electrónico que lo explica..."
Si bien puede parecer que está completando las cosas más rápido, ese no es realmente el caso. O intenta completar todas las historias y no hacer nada en el sprint 1 y hacer todo en el sprint 2, o completa las historias B, C y G realizadas en el sprint 1, luego termina la historia A en el sprint 2. Esa es una ventaja de Scrum vs. Waterfall - obtienes algo antes.
Para colmo, la empresa tiene problemas en su infraestructura, como entornos que no funcionan y el desarrollo se detiene aproximadamente el 20 % del tiempo debido a dependencias externas.
No es realmente tan inaudito, y no es fundamentalmente incompatible con Scrum. Simplemente trátelo como si tuviera un factor de enfoque más bajo; es decir, significa que su equipo puede comprometerse con una cantidad menor de puntos de historia por sprint (en comparación con la cantidad que podrían comprometerse sin estos problemas).
La empresa tiene compromisos con los clientes que está tratando de cumplir. Por lo tanto, por un lado quieren hacer scrum, por el otro parece una metodología en cascada etiquetada como "scrum".
Como expliqué anteriormente, asumir más trabajo que en realidad no puede completar puede hacer que parezca que su equipo va más rápido, pero en realidad no va más rápido. Seguir Scrum no debería impedirle cumplir con los compromisos de los clientes.
¿Hay esperanza en esta empresa en términos de apreciar lo que se necesita hacer para comenzar a implementar scrum?
Sí. Agregar Scrum a un taller de Waterfall a menudo es tan terriblemente lento como eventualmente gratificante. Síguelo.
¿Cómo pueden dejar de agregar cosas en la acumulación de sprints y concentrarse en entregar sprints completos en lugar de tener historias a medio hacer al final?
Con suerte, una vez que los costos de hacer esto se vuelvan visibles, la administración se detendrá. O bien, la necesidad de hacerlo podría desaparecer, una vez que las cosas se calmen un poco. Si ninguno de estos sucede y su proyecto realmente es algo tan volátil que no puede manejar la planificación con sprints de dos semanas, considere la posibilidad de que Scrum realmente no encaje. Sin embargo, no tiene que quedarse con Waterfall: considere una metodología ágil diferente, como Kanban.
dqm
nathan cooper