El advenimiento de las metodologías ágiles ciertamente ha sido un fenómeno similar a la revolución de los años 60. Creo que es una especie de Woodstock de la informática, que, como suele suceder en la vida, solo vi desde lejos.
Sin embargo, sigo conociendo a personas que estuvieron allí y que siempre se detienen a contarme que tal evento nunca volverá a suceder y cómo los programadores del pasado se amaban, intercambiaban coronas de flores, etc. Bueno, en resumen, el meme de Robert Downey Jr. lo explica perfectamente.
Mi legado histórico como consultor me ha enseñado que hablar sobre Agile en el contexto de la administración pública pone de mal humor a todo el mundo y te hace parecer uno de esos personajes listos para ser lapidado en La Vida de Brian.
Por el contrario, en contextos de startups, mostrar un diagrama de Gantt puede causar narcolepsia y mareos.
Sin embargo, los no ortodoxos saben que ambos pueden aplicarse en contextos donde Cynefin nos permite enmarcar el problema en términos de complejidad, caos, simple y complicado.
Pero una vez que se toma un camino Agile, comienzas a evaluar qué framework elegir, y ahí comienza otra guerra, más pequeña pero no menos sangrienta.
¿Scrum llegó antes que Agile, o Agile antes que Scrum? Aunque la metodología Scrum es un framework de Agile, su forma primordial fue presentada por primera vez por Jeff Sutherland, John Scumniotales y Jeff McKenna en 1986 en la empresa de consultoría «Easel Corporation». Inicialmente, el término «Scrum» fue tomado del contexto del rugby para describir una forma colaborativa de jugar, haciendo eco de las acciones del scrum.
En 1991, Jeff Sutherland presentó Scrum en la conferencia OOPSLA (Object-Oriented Programming, Systems, Languages & Applications), contribuyendo a formalizar los conceptos de Scrum. Durante este período, Ken Schwaber estaba trabajando de manera independiente en métodos de desarrollo iterativo y se unió a Sutherland para ampliar y promover Scrum. En 1995, Schwaber y Sutherland publicaron el primer artículo sobre el Proceso de Desarrollo Scrum. Durante este período, comenzaron a definir roles clave en Scrum, como Product Owner, Scrum Master y Development Team, junto con eventos como Sprint y Sprint Review.
«Si entrevistamos a 3 expertos en Scrum, lo describirían de manera tan diferente que parecería estar en una famosa película de Kurosawa».
En 2001, Schwaber participó en la redacción del Manifiesto Ágil en Snowbird, Utah, que enfatiza los principios fundamentales de los enfoques ágiles en el desarrollo de software. Como se puede leer en la página que recuerda el evento, Scrum fue uno de los frameworks clave mencionados en el Manifiesto Ágil.
En 2009, Ken Schwaber y Jeff Sutherland publicaron la primera versión de la «Guía de Scrum«, un documento que define de manera clara y concisa los roles, eventos y artefactos de Scrum. La Guía de Scrum se ha convertido en el recurso oficial para comprender Scrum.
Scrum ha ganado popularidad más allá del desarrollo de software, extendiéndose a otras disciplinas como la gestión de proyectos, la gestión de productos e incluso el marketing, pero algunos incluso lo usan para cocinar. Su aplicación se ha extendido a varios sectores más allá del tecnológico, y hoy en día Scrum es uno de los frameworks ágiles más utilizados, ofreciendo un enfoque flexible y colaborativo para el desarrollo de productos y la gestión de proyectos. La Guía de Scrum se revisa periódicamente para reflejar las mejores prácticas emergentes y mantener actualizado a Scrum.
Pero ¿qué es la metodología Scrum? Si entrevistamos a 3 expertos en Scrum, lo describirían de manera tan diferente que parecería estar en una famosa película de Kurosawa, así que pongamos todos los avisos del mundo sobre lo que sigue. Incluso la descripción dada por scrum.org afirma que Scrum «ayuda a las personas y los equipos a entregar valor incrementalmente de manera colaborativa. Como framework ágil, Scrum proporciona suficiente estructura para permitir que las personas y los equipos integren la forma en que trabajan, al tiempo que agregan las prácticas adecuadas para optimizar sus necesidades específicas.» Comienza con la frase lacónica «Si estás comenzando con Scrum, piénsalo como…» lo que significa que el viaje es mejor que el destino, y apenas estás comenzando.
En la práctica, proporciona una estructura para el trabajo colaborativo dentro de los proyectos (los complejos). Está diseñado para permitir el desarrollo y la entrega rápidos de productos de calidad, centrándose en la flexibilidad y en responder a las necesidades del cliente o del mercado. Así que es:
Iterativo e incremental: Scrum organiza el trabajo en iteraciones llamadas sprints, cada una generalmente con una duración de una a cuatro semanas. Durante cada sprint, se produce un incremento del producto.
Roles definidos: Scrum define claramente los roles principales, incluido el Product Owner (responsable del producto), el Scrum Master (facilitador del proceso) y el Development Team. Cada rol tiene responsabilidades específicas.
Backlog del producto: El Product Owner mantiene un backlog de productos, una lista priorizada de elementos de trabajo que representan características deseadas o objetivos para el producto final.
Planificación de sprint y reuniones de Scrum: Al comienzo de cada sprint, el equipo se reúne para planificar qué elementos del backlog se completarán durante la iteración. Al final de cada día, se lleva a cabo una breve reunión llamada Scrum diario para supervisar el progreso e identificar cualquier obstáculo. Hasta la fecha, los eventos más sangrientos después de las reuniones de condominio.
Revisión y retrospectiva: Al final de cada sprint, el equipo realiza una revisión para demostrar los resultados logrados durante el sprint y revisar el backlog. Posteriormente, se lleva a cabo una retrospectiva para reflexionar sobre el rendimiento del equipo e identificar mejoras para los próximos sprints. Aquí, también se mide la infame «velocidad del equipo».
Transparencia e inspección regular: Scrum es sinónimo de transparencia. A través de herramientas como el backlog y el gráfico de quemado, permite la inspección constante del progreso y la corrección de rumbo, si es necesario.
Adaptabilidad: Scrum está diseñado para adaptarse a los cambios en los requisitos del producto o las prioridades del cliente. La adaptabilidad está integrada en el framework, lo que permite al equipo responder rápidamente a los comentarios y los cambios solicitados. Por lo general, en estos contextos, el menos adaptable resulta ser el scrum master.
¿El método scrum es un problema?
Las opiniones sobre Scrum, o cualquier framework o metodología, varían según las experiencias personales, las necesidades del proyecto y el equipo en cuestión.
Muchas personas encuentran que la metodología Scrum no encaja bien en su contexto o que hay desafíos específicos en su implementación, pero esta es la primera reacción ‘conservadora’ de cualquier empresa frente a una novedad, y sabemos después de numerosos estudios y tantos memes que la frase más peligrosa en la economía moderna es «siempre lo hemos hecho así».
Si profundizamos un poco más, podemos encontrar algunas críticas comunes:
Complejidad: Muchos argumentan que Scrum puede parecer complicado y requerir una curva de aprendizaje considerable para ser implementado correctamente. Claramente, esto depende mucho de quién haya intentado implementar Scrum en la empresa.
Como sabemos, el camino al infierno está pavimentado de buenas intenciones, y si tuviera un euro por cada persona inexperta que intentó Scrum en las empresas, dejándolo morir después de un tiempo, ahora tendría al menos el equivalente a un Bitcoin.
Adaptabilidad: Algunos cuestionan la capacidad de Scrum para adaptarse efectivamente a todos los tipos de proyectos, especialmente aquellos de pequeño tamaño o altamente complejos. Personalmente, funciona muy bien para los pequeños, pero para los altamente complejos, no puedo dar fe de ello porque aún no he enviado cohetes a la luna (todavía).
Enfoque en la cantidad de trabajo: Más de una vez, muchos se quejaron de que el enfoque en sprints y la planificación basada en la cantidad de trabajo (estimación de puntos de historia) llevó a una falta de atención a la calidad del producto. Y desafortunadamente, he experimentado esto varias veces. El equipo está formado por personas (por ahora 😄), y las personas, según su antigüedad, ignoran que el aspecto cualitativo nunca debe pasarse por alto. Un problema cultural que está en la raíz del fracaso de la adopción de Scrum en casi todos los contextos.
Roles rígidos: Algunos equipos pueden encontrar que la estructura de roles rígidos de Scrum (Scrum Master, Product Owner, Equipo) puede no adaptarse bien a su cultura corporativa o dinámica de equipo. Nuevamente, no es la rigidez de Scrum, recordemos que es un framework, sino la rigidez de las personas lo que hace que parezca menos adaptable en contextos no convencionales.
Cambios culturales difíciles: Implementar Scrum puede requerir cambios culturales significativos dentro de una organización, y las personas pueden resistirse a tales cambios. Creo que este es el problema principal. No es posible adoptar Scrum donde hay resistencia cultural al cambio y las personas no comprenden completamente los beneficios de dicho cambio. No solo corres el riesgo de no implementar el framework, sino que incluso puedes salir mucho menos convencido de que Scrum puede ser la solución a muchos problemas, haciéndonos dudar de su adaptabilidad.
Casi todas las críticas a Scrum se derivan de interpretaciones o implementaciones incorrectas, en lugar de defectos intrínsecos en el framework. Muchas organizaciones encuentran Scrum extremadamente útil para mejorar la transparencia, la comunicación y la entrega de valor.
Como con cualquier metodología, es importante adaptar y personalizar Scrum en función de las necesidades específicas del equipo y el proyecto. Pero sobre todo, siempre es mejor probar la disposición de la organización para el cambio.
