Recientemente encontré la opinión de que, si un Sprint tiene éxito debido a razones estadísticas (por ejemplo, el equipo cometió grandes errores durante la planificación pero el equipo entregó sus historias de todos modos), entonces eso es tan bueno como si el éxito se lograra gracias a una estimación precisa y un compromiso informado. por el equipo Por lo tanto, me pregunto si esto realmente está de acuerdo con los procesos ágiles y los principios detrás de esos procesos.
La pregunta se puede dividir en dos partes:
Cuando se utilizan procesos iterativos y ágiles como Scrum o Extreme Programming, ¿qué conclusiones se pueden sacar de los Sprints exitosos o fallidos?
Si su Sprint fue "accidentalmente exitoso", entonces el Sprint sigue siendo un éxito. Simplemente significa que los futuros Sprints podrían no tener éxito sin un cambio de proceso.
Cuando se utilizan procesos iterativos y ágiles como Scrum o Extreme Programming, ¿qué conclusiones se pueden sacar de los Sprints exitosos o fallidos?
Esta es una gran pregunta porque va directamente al corazón de las prácticas ágiles y explora la naturaleza de los controles explícitos e implícitos que subyacen en marcos como Scrum y XP.
Un Sprint exitoso generalmente cumple con todos los siguientes criterios:
Sin embargo, la definición de éxito deja de lado deliberadamente cuestiones de velocidad, estimaciones de puntos de la historia, procesos internos o cambios de alcance aprobados por el Product Owner que no comprometen el Sprint Goal.
Si su Sprint cumplió con los objetivos, probablemente debería declarar el éxito y abordar cualquier problema de mejora continua dentro de la Retrospectiva del Sprint. Por ejemplo, si su Sprint fue exitoso pero el proceso del equipo no fue confiable o repetible dentro de los límites de variación aceptables, eso no significa que el Sprint fracasó, solo significa que el siguiente podría no tener éxito sin un cambio en el proceso.
En realidad, esto es más difícil de definir, porque un Sprint puede tener éxito a través del fracaso. Por ejemplo:
Una vez más, tenga en cuenta lo que se deja deliberadamente fuera de la definición. Se puede cumplir un Sprint Goal incluso si el Sprint Backlog no se completa; por sí mismo, un Sprint Backlog incompleto no significa que el Sprint fracasó. Del mismo modo, una Revisión de Sprint que no deleita a las partes interesadas solo significa que el circuito iterativo de retroalimentación del Sprint está funcionando según lo diseñado.
Por supuesto, si no se cumplió el Sprint Goal y no hay un lado positivo para el equipo o la organización, entonces es justo decir que el Sprint ha fallado. Sin embargo, incluso un Sprint fallido rara vez es una pérdida total; por lo general, hay al menos algún valor residual de la iteración, lo que permite que incluso los Sprints "fallidos" brinden algún beneficio marginal.
Analizar fallas es uno de los propósitos de una Retrospectiva de Sprint. Ofrece la oportunidad de realizar una autopsia e identificar posibles mejoras en el proceso del equipo.
Sin embargo, desde el punto de vista general del proyecto, una falla aislada es solo un único punto de datos. Hasta que tenga un patrón de fallas, las únicas conclusiones que razonablemente puede sacar son:
Por supuesto, si realmente tiene un patrón de fallas, depende del equipo y de las partes interesadas analizar por qué el proceso falló repetidamente y si el proceso o el proyecto se pueden salvar.
No puedo hablar de los principios detrás de los procesos ágiles, pero desde una perspectiva general, opino que los resultados que logramos con el trabajo, o cualquier acción en realidad, están influenciados principalmente por variables estocásticas. En otras palabras, tenemos menos control sobre nuestros resultados de lo que nos gusta creer.
Cuando hacemos autopsias de un esfuerzo recientemente terminado, cuando las cosas van bien, nos gusta atribuir esos resultados a nuestras grandes decisiones y palancas que elegimos tirar cuando elegimos tirar de ellas. Del mismo modo, cuando las cosas van mal, hacemos lo contrario e identificamos todas aquellas cosas sobre las que no teníamos control. La atribución errónea y la ilusión de control gobiernan estos procesos de pensamiento y comportamientos.
Creo que es valioso identificar aquellas cosas que influyeron en un buen resultado; sería demasiado fatalista no hacerlo. Sin embargo, un análisis profundo de esas variables debe incluir algún equilibrio con lo que sucede de manera aleatoria. De lo contrario, terminaremos con un montón de falsas creencias de causa y efecto donde en realidad no las hay. Y hay un montón de ejemplos de esto en los negocios.
En mi opinión, el "éxito debido a razones estadísticas" como se describe en su pregunta no es tan bueno como el éxito que se logra debido a una estimación precisa y un compromiso informado porque el primero no se puede reproducir de manera confiable. De hecho, el "éxito debido a razones estadísticas" probablemente sea más peligroso a largo plazo porque enmascarará problemas fundamentales en sus prácticas de planificación.
A modo de analogía, es posible elegir un equipo de fútbol ganador aunque su análisis sea profundamente defectuoso. Esto será un "éxito" porque ganarás algo de dinero esta semana. Pero a la larga, perderá dinero en comparación con la persona que elige a su equipo mediante un análisis sólido.
Todd A. Jacobs