Si Scrum se aplicara al desarrollo de software, sería más o menos así: (...) formar al equipo eligiendo cuidadosamente a una persona de cada una de las [fases tradicionales de desarrollo]. (...) Usted entonces les da una descripción del problema a resolver y (...) los desafía, diciendo que deberán producir el sistema en, digamos, la mitad del tiempo y dinero, así como que este debe duplicar el rendimiento de otros sistemas. A continuación, les dice que el cómo lo harán, correrá de su cuenta (DeGrace & Stahl, 1990).
Jeff Sutherland y Ken Schwaber citan a menudo al artículo “The new product development game” (o “El nuevo juego en el desarrollo de nuevos productos”), publicado en 1986 por Takeushi y Nonaka en la revista Harvard Business Review, como la principal fuente de información inspiradora directa para la creación del marco Scrum. En este artículo, los autores japoneses utilizaron una analogía con el rugby para explicar la forma en que los equipos de desarrollo de nuevos productos (como coches, impresoras, fotocopiadoras y ordenadores personales) realizaban su trabajo en los años 80.
La palabra "scrum", que aparece encabezando uno de los apartados del artículo, es una formación para la reposición del balón en el rugby. Así fue como, a partir de ahí, los creadores de Scrum bautizaron al framework.
Hay, sin embargo, muchos indicios que sugieren que Sutherland y Schwaber no cuentan toda la historia. Vea el pasaje que abre este post. Ha sido extraído del libro “Wicked problems, righteous solutions”, publicado en 1990. En él se sugiere, por vez primera, la idea de utilizar en el desarrollo de software el conjunto de prácticas descritas por los dos autores japoneses en la prestigiosa revista mencionada. Y en ese mismo libro, sus autores, DeGrace y Stahl, bautizaron a esta nueva forma de trabajar como "Scrum".
Para ser justos, es importante señalar que el libro no proporciona un método mínimamente detallado ni utilizable acerca de la forma de poner esas ideas en práctica. A Sutherland y Schwaber les cupo el honor de crear el marco propiamente dicho con sus reglas, papeles, eventos y dispositivos, así como ponerlos en funcionamiento.
En ese mismo libro, los autores explican por qué el modelo en cascada (o "waterfall") no funciona para el desarrollo de software, y ofrecen posibles alternativas. Scrum aparece como una de ellas. El libro gira en torno a la idea de que el software es un tipo de problema que no puede definirse claramente ni detallarse antes de que se le ofrezcan soluciones al mismo (un “wicked problem”). En otras palabras, cada intento de crear una solución modifica la propia definición del problema.
A mis alumnos trato de demostrarles este concepto preguntándoles lo siguiente: "¿De qué estamos seguros que sucederá cuando ponemos una nueva funcionalidad a disposición de un usuario?" El usuario seguramente va a responder algo como: "ahora que veo cómo funciona esto, no lo necesito, necesito otra cosa, esto no debería ser así...”, etc. Así no podemos detallar por adelantado todas las funcionalidades que el software deberá tener para resolver el problema propuesto, solo podemos desarrollarlo a partir de hipótesis. La definición del producto emerge a lo largo de su desarrollo y uso. O, como siempre me gusta decir, el uso define al producto.
Jeff Sutherland cita el libro “Wicked problems, righteous solutions” en, al menos, dos artículos escritos por él en los inicios de la historia del Scrum. Destaca esta obra como de gran influencia en la introducción del Scrum en Easel Corporation. Jeff también destaca el modelo “Todo-de-una-vez” (“All-at-once”), usado por el libro para describir el Scrum como un enfoque en el que el equipo multidisciplinar realiza simultáneamente todo el trabajo necesario para generar las partes del producto que funcionan de un extremo al otro.
En 2017, cuando Knowledge21 llevó a Jeff por primera vez a Brasil, pasé una tarde con él y tuvimos la oportunidad de conversar sobre diversos asuntos relacionados con la historia del Scrum. Pero, hasta donde sé y pude comprobar, ni Jeff ni Ken en ningún momento dieron oficialmente el debido crédito a los autores del libro ni mencionan su importancia con respecto a la idea original.
De ninguna de las maneras estoy afirmando que Jeff y Ken no sean los creadores del framework Scrum, ya que ellos definieron y aún evolucionan sus reglas, papeles, eventos y dispositivos, y los pusieron en práctica. Pero, ciertamente, no fueron ellos quienes tuvieron la idea original de aplicar al desarrollo de software el enfoque descrito por los japoneses, y ciertamente no fueron ellos quienes la bautizaron como Scrum.
¿Quiere saber más sobre el Scrum?
• Lea más artículos sobre el framework
• Participe en la formación Certified ScrumMaster
Referencias:
DEGRACE, P.; STAHL L. H. Wicked problems, righteous solutions: a catalogue of modern software engineering paradigms. Nueva Jersey: Yourdon Press, 1990.
SUTHERLAND, J. “Agile can scale: inventing and reinventing SCRUM in five companies”: Cutter IT Journal, v. 14, pp. 5-11, 2001.
SUTHERLAND, J. “Agile development: lessons learned from the first Scrum. Cutter Agile Project Management Advisory Service”: Executive Update, v. 5, n. 20, pp. 1-4, 2004.
TAKEUCHI, H.; NONAKA, I. “The new product development game”: Harvard Business Review, Boston, MA, Estados Unidos, v. 64, n. 1, pp. 137-146, enero/febrero 1986.
