Los siguientes comentarios son motivados por un artículo publicado en medium.com titulado: the dark side of Scrum, y compartido vía twitter por offrayLC en el cual muestran ciertas debilidades y se pone en entredicho que Scrum realmente sea un marco de trabajo ágil, concentrando la crítica en tres puntos:

  • Lentitud de los sprints o ciclos de desarrollo
  • El product backlog conduce a tomar malas decisiones sobre el producto
  • Las reuniones producen un ambiente de incertidumbre

Con respecto al primer punto el artículo afirma que los sprints agregan cargas innecesarias, en primer lugar por la estimación que se realiza del alcance del sprint, lo que significa hacer una proyección de las historias de usuario a entregar en un determinado tiempo, labor que desde luego no es sencilla y que está sometida a diversas variables como por ejemplo el tamaño y experiencia del equipo. Aquí quiero detenerme un poco, dado que el artículo menciona: (traducción realizada por mí):

"... Básicamente un sprint te obliga a comprometerte a desarrollar algo que posiblemente no puedas entregar. La única forma de llegar a un rendimiento predecible en un sprint está sujeto a que: El desempeño del equipo nunca cambie, las tareas a desarrollar tenga un alto grado de predecibilidad y no se presenten tareas urgentes o más importantes en el camino."

Pienso que hay que realizar una serie de aclaraciones sobre lo que establece Scrum y lo que he venido aprendiendo con base en mi experiencia:

El equipo

Uno de los factores claves para el buen desarrollo de un proyecto utilizando una metodología ágil es el equipo, o dicho en otros términos: las personas. Por eso uno de los puntos del manifesto ágil enfatiza en que las interacciones y las personas están por encima de los procesos y las herramientas. Así, desde mi punto de vista Scrum no establece ni de forma explícita ni implícita que, como lo dice el artículo, el equipo deba tener un rendimiento invariable, cuestión que es realmente complicado lograr -las personas salen de las empresas, se enferman, tienen problemas, etc-, inclusive la naturaleza de un proyecto puede ser una fuente de motivación o de aburrimiento para muchos integrantes del equipo. Lo que Scrum enfatiza es en la construcción de un equipo que involucre a todos los interesados y eso desde luego significa un cambio cultural que a muchos les cuesta asumir y es ahí donde pienso que radican las fallas de muchos proyectos: no existe el suficiente "pegamento" entre los integrantes del equipo para llegar a construir el producto hasta el final. Adicionalmente, las restricciones de tiempo, presupuesto y alcance agregan limitaciones, que desde luego en ciertos ámbitos es díficil manejar. La experiencia de un equipo que viene trabajando desde hace dos años no es comparable con aquellos que empiezan a trabajar o cuando la tecnología -hablando específicamente de productos de software- es nueva. Scrum propone un marco de trabajo que brinda guías para que cada equipo construya sus propias métricas con base en la experiencia.

El producto

La segunda crítica se centra en el manejo del product backlog y estoy totalmente de acuerdo en que en muchos proyectos se convierte es una enorme lista de características que jamás se implementarán. Sin embargo, en mi opinión el manejo del backlog depende de la claridad que se tenga con respecto al producto que se quiere desarrollar. La propuesta de manejar el backlog como un roadmap me parece muy válida, teniendo en cuenta que durante el desarrollo de un proyecto son varias las cosas que pueden cambiar, sin embargo si es necesario establecer metas claras y deadlines.

Las interacciones

El tercer punto realiza una crítica con respecto a las reuniones que propone Scrum, puntualmente sobre las reuniones diarias. El autor del artículo hace hincapie en tres debilidades:

  • No siempre es fácil recordar lo que se hizo el día anterior
  • Hay dificultad en hacer seguimiento de lo que dicen todos los asistentes
  • La reunión se puede sentir como un interrogatorio

Antes de comentar sobre las debilidades mencionadas, debo aclarar que en mi experiencia entre más se eviten las reuniones, mucho mejor; se gana tiempo y las discusiones por los detalles se llevan a planos donde los directamente interesados participan y toman las decisiones. Partiendo de esa base, considero que la reunión de seguimiento diaria es importante dado que mantiene el contacto del equipo y permite articular soluciones por el simple hecho de comunicar cara a cara un problema. Lo anterior no significa que haya que emplear tiempo excesivo en la ejecución de la misma, puesto que una reunión de más de 30 minutos empieza a producir molestias y sensación de pérdida de tiempo. La reunión diaria debe abarcar lo esencial y como lo dice el artículo concentrar la discusión en aquellos aspectos que representen bloqueos o dificultades.

Para finalizar, pienso que Scrum debe pensarse como un marco de trabajo flexible más allá de una metodología que impone una serie de pasos a seguir.



Comments

comments powered by Disqus