Durante muchos años he defendido que evitemos usar Scrum para hacer proyectos ya que su verdadero propósito es el desarrollo de productos. Este debate es relevante, Scrum no te puede asegurar una fecha con un alcance y un coste. Scrum se centra en la entrega de valor. Las fechas y costes se miden como parte del proceso de desarrollo de producto pero nunca como un fin que marque el éxito del equipo.
Sin embargo, he estado repasando la guía Scrum y me he llevado una sorpresa. En la definición formal del marco de trabajo han eliminado la palabra producto respecto a las versiones anteriores.
¿Para qué sirve Scrum?
Definición
Acudamos a la propia definición formal del marco que da la guía oficial:
“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems”
Dado que es una definición escueta vamos a explicar cada término.
Por un lado, Scrum se define como un marco ligero. Este concepto se utiliza para especificar que es un marco incompleto al que debemos añadir prácticas propias del problema que queremos resolver. Por ejemplo, si aplicamos Scrum para un equipo de desarrollo software deberemos de añadir prácticas de desarrollo software avanzado como Pair Programming o Continuous Delivery.
Por otro lado, la definición de Scrum específica que se utiliza para resolver problemas complejos. Si estamos tratando de resolver un problema que contiene una cantidad inmanejable de variables que escapan a nuestro control. En ese caso, no podemos planificar una solución detallada, tendremos que usar una estrategia de inspección y adaptación constante.
Por último, la definición de Scrum apunta a que se utilizan soluciones adaptativas, esto es lo que podríamos entender como Product Management. Podemos definir un Producto como una entidad que evoluciona a lo largo del tiempo a base de inspección y adaptación en función de los retos que van surgiendo y con foco en generar valor.
En resumen, Scrum es un marco incompleto que busca resolver problemas complejos a base de adaptación.
¿Qué entendemos por un problema Complejo?
A pesar de que empecé a escuchar la palabra Scrum en 2008 mientras acababa la Carrera Universitaria, no fue hasta el 2014 cuando recibí mi primera formación avanzada impartida por Carmen Lasa. Carmen enfocó la primera parte de su formación a trabajar el concepto de complejidad a través del modelo Stacy. Es curioso, nos están explicando un marco de trabajo nuevo y empiezan hablando de complejidad en vez de herramientas y reuniones.
Sin embargo, no fue la única. En el año 2017 recibí una formación por parte de Jerónimo Palacios sobre Product Owner. En esta formación se dedica todo un tema a hablar de complejidad y, “casualmente”, era el primero.
Con el tiempo, me he dado cuenta que, cuando hablamos de Scrum, tenemos que hablar de complejidad y sus implicaciones. De hecho, si a las personas que nos dirigimos no les explicamos el concepto de complejidad, les costará entender la propuesta de Scrum.
La complejidad aparece cuando estamos ante un problema que tiene una cantidad ingente de variables que no podemos controlar. Esto tiene una derivada clara, es imposible planificar. Si lo pensamos fríamente los grandes retos de la humanidad siempre han sido complejos y se han resuelto mediante soluciones adaptativas. El método científico ya transmite esa idea de inspección, adaptación y transparencia. El conocimiento para resolver el problema se adquiere de la experiencia y para ello debemos probar y analizar el resultado de nuestra prueba. ¡Experimentación pura!
¿Por qué el software es complejo?
Muchas personas se preguntan por qué el software se considera una disciplina compleja. Incluso escucho a muchas personas afirmar que con chat GPT y motores de inteligencia artificial generativa podremos superar la complejidad del software ya que el desarrollo será algo baladí.
Uno de los grandes errores que cometen las empresas es que equiparan el desarrollo software con fabricar coches o construir una casa. Esto les lleva a creer que pueden planificar todo lo que se va a construir antes de poner una sola línea de código. De hecho, muchas empresas creen que el gran reto es planificar muy bien y controlar las desviaciones a lo largo del tiempo, lo que nos enseña la certificación PMP.
La primera dificultad consiste en entender que la misión del software no es tener un producto o un proyecto. El objetivo es resolver un determinado problema: aumentar las ventas, mejorar la experiencia de usuario, atraer más usuarios… La clave es centrarnos en el problema (que casi siempre es de negocio) y no tanto en la solución software que construímos.
Si planteamos el desarrollo software desde el problema complejo entenderemos lo difícil que es planificarlo y dar una fecha. Pero si lo planteamos en términos de construir un producto nos seguirán exigiendo planes detallados con todas las tareas. ¿Cuánto tiempo voy a tardar en hacer Facebook y que tenga 1000 millones de usuarios diario? ¿Cuándo voy a conseguir que Youtube sea una plataforma de referencias para creadores de contenido? Estas preguntas no se pueden responder, debemos probar y adaptarnos continuamente.
Nuevo paradigma, nuevas soluciones
En el momento en el que el desarrollo software se enfoca desde la resolución de problemas complejos toda la propuesta del marco Scrum gana sentido.
Por ejemplo, tener un producto que va evolucionando a medida que te estamos resolviendo el problema tiene mucho más sentido que un plan estático construido sin hablar apenas con los cliente. El hecho de tener un Product Backlog dinámico es muy interesante ya que cuadra perfectamente con la idea de que al aproximarnos a la solución nos encontraremos nuevos retos. Aproximación empírica a un problema que no tiene una solución trivial. Es clave recibir feedback por parte de personas ajenas al equipo, de esta manera, para entender si vamos por el buen camino o tenemos que adaptarnos.
Cada vez que tengamos un reto para la implantación de Scrum, las preguntas que tenemos que hacernos son: ¿Para qué construimos esto? ¿Qué problema queremos resolver? ¿Cómo vamos a medir que lo estamos resolviendo? Sólo cuando seamos capaces de responder a estas preguntas podremos empezar a ser ágiles. A partir de ahí, construimos nuestro Product Backlogs con aquellas acciones que lanzaremos e iremos midiendo nuestro acercamiento a la solución.
Y tú, ¿Resuelves problemas complejos con Scrum?
