Durante los últimos años hemos asistido a una gran evolución de Scrum y, sobre todo, de la visión que tenemos de Agile. Después de dos décadas donde, en ciertas empresas han visto como Agile y Scrum aportan poco valor, ha llegado la hora de repensar el uso de Scrum.
Si los proyectos fallan con Scrum y los productos también, ¿cómo podemos enfocar Scrum? ¡Vamos a ello!
Primera versión de Scrum
Aunque Scrum fue presentado en 1995, se empezó a hacer famoso a raíz del Manifiesto por el Desarrollo Ágil de software de 2001. Durante los años siguientes, Scrum fue poco a poco pervertido. Así que, en 2010, se publica la primera versión de la Guía Scrum, en la que se intenta definir las bases del marco con el ánimo de que sea más útil.
La definición que se daba de Scrum es esta:
“Scrum has been used to develop complex products since the early 1990s. This paper describes how to use Scrum to build products. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. The role of Scrum is to surface the relative efficacy of your development practices so that you can improve upon them while providing a framework within which complex products can be developed. “
Curiosamente, Scrum hablaba de Product Management, tiene sentido, por la cantidad de elementos que nos recuerdan a Producto: Product Owner, Product Backlog… Al final, Scrum se centra en producto, aunque ya habla de complejidad, uno de los elementos clave para entender la diferencia entre Scrum y otros marcos.
Evolución de Scrum (2011-2017)
Los siguientes años, la guía tomó forma y evolucionó rápidamente para mejorar la propuesta de Scrum. En el año 2011 aparece una nueva definición que se ha mantenido durante casi 10 años.
Versión 2011
“Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is:
Lightweight Simple to understand Extremely difficult to master”
Si nos fijamos, en esta definición, se habla de resolver problemas complejos y adaptativos, de manera productiva y creatividad para generar valor. Pero, curiosamente, se habla de desarrollar Producto. En esta época se estaba poniendo de moda el concepto de Producto Digital.
El problema de la definición de Producto es que, para muchas empresas, se aleja de su día a día, están acostumbrados a proyectos.
Las versiones siguientes (2013, 2016, 2017) mantuvieron la misma definición. De alguna manera, se mantuvo la idea de que Scrum es un marco cercano a producto
Scrum se reinventa (2020)
La versión vigente es 2020, donde se actualiza toda la guía para ampliar Scrum a más sectores (y no solo el tecnológico) y para clarificar muchos de sus elementos. Entre estos cambios, la propia definición del marco cambia y ahora dice así:
“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”
Lo más curioso de esta definición es que se elimina la palabra producto. ¿Ya no hacemos Producto Digital? Realmente, hay un mensaje subyacente importante, es más importante resolver el problema que hacer el producto.
Producto, proyecto y solución
La visión que transmite el Project Management Institute sobre los proyectos es que, como gestores, debemos desarrollar un plan y tratar de que se haga realidad. Los proyectos, en problemas complejos, son poco útiles porque precisamente la incertidumbre hace que planificar en detalle sea un infierno.
Ahora bien, en Producto estamos cometiendo errores parecidos. Un producto es más que un software propio o sobre el que tienes la prioridad. Un producto debe enfocarse en un problema. Cuando hacemos un producto en una empresa, generalmente grande, lo seguimos enfocando como un proyecto pero con “análisis de mercado”. Finalmente, la aproximadamente es muy similar a los proyectos. En startups, encontramos a personas que se han enamorado de su producto y no del problema que quieren resolver. ¡Nos falta el foco en los resultados!
Sin embargo, Scrum no da la clave, ni proyecto ni producto, soluciones. La palabra solución debería ser la clave de todos los equipos que se enfrentan a problemas complejos.
Próximos pasos de Scrum
Siguiendo la línea de cambiar Producto por Solución. Debemos evolucionar el propio marco, cambiar Product Owner por Solution Owner o Product Backlog por Solution Backlog. Quizás, de esa manera, entendamos mejor el gran potencial de Scrum.
De hecho, una recomendación habitual que suelo hacer es rodearnos de métricas que nos guíen. Hay problemas complejos que nunca se solucionan al 100% pero que las aproximaciones que damos resuelven de manera razonada. Por ejemplo, la vacuna del COVID ha sido una solución razonable pero mejorable: cubrir el 100%, tener menos secuelas, hacer que sea perenne…
Y tú, ¿Evolucionas Scrum hacia soluciones?
1 pensamiento sobre “Proyecto, Producto o Solución”