S de Scrum

Creado por Ken Schwaber y Jeff Sutherland en los años 90, Scrum se ha convertido en un framework tan extendido que la mayoría de la gente lo identifica erróneamente con Agile. Tanto Schawber como Sutherland son firmantes originales del Manifiesto Ágil, que es de 2001. Es importante tener en mente lo que hemos mencionado en el capítulo dedicado a Agile: Scrum es una más de las propuestas metodológicas de desarrollo de software cuyos proponentes buscaron un punto de encuentro en el Manifiesto. Es importante entender que Scrum no nace de Agile.

Scrum está codificado en una Guía, cuya primera versión data de 2010. Y es importante señalar esa codificación, porque los propios autores mencionan que si no la sigues de pe a pa, no estás haciendo Scrum y si no funciona, no es su culpa:

La Guía Scrum contiene la definición de Scrum. Cada elemento del marco sirve a un propósito específico que es esencial para el valor global y los resultados realizados con Scrum. Cambiar el diseño o las ideas básicas de Scrum, dejar fuera los elementos, o no seguir las reglas de Scrum, cubre los problemas y limita los beneficios de Scrum, potencialmente incluso haciéndolo inútil.

Así que cuando te digan “aquí hacemos Scrum a nuestro modo”, la realidad es que no se está haciendo Scrum. Es otra cosa que se le parece.

Y, ojo, no estoy diciendo que eso esté mal. De hecho, Agile dice que cada equipo debe buscar la forma de trabajar que mejor le vaya. Así que si a un equipo le funciona para tener una entrega de valor constante y sostenible, miel sobre hojuelas.

Scrum es un framework, o sea, la codificación de ciertas prácticas metodológicas que, realizadas de forma sistemática, deberían conducir a una entrega sostenida de valor en equipos de desarrollo de software. Esta codificación se concreta en la Guía Oficial de Scrum, que es su única referencia válida.

Scrum es una metodología relativamente simple y diría que bien aplicada puede ser una buena forma de que un equipo que no sabe trabajar ágilmente pueda empezar a aprender. Con el tiempo, un equipo genuinamente ágil probablemente abandonará Scrum porque puede llegar un punto en que la metodología suponga un freno.

No hay nada mejor que leerse la guía de scrum para entender cómo funciona. Así que aquí vamos a centrarnos solo en sus elementos más característicos y muy a grandes rasgos. La guía de Scrum (edición de 2020) tiene tan solo 17 páginas.

El equipo de desarrollo Scrum está formado por Scrum Master (SM), Propietaria de Producto (Product Owner o PO) y desarrolladoras. Se trata de un equipo multifuncional, o sea: tiene todas las habilidades necesarias para crear valor. Y es autogestionado, por lo que toma sus propias decisiones. La recomendación es que el equipo sea pequeño: no más de 10 personas.

Si los equipos son demasiado grandes, deberán reorganizarse como equipos más pequeños, compartiendo el mismo objetivo de producto y Propietaria de Producto.

Desarrolladoras: la función de las desarrolladoras es construir el incremento de valor del producto, para lo cual deben crear un plan, llamado Backlog de Sprint, trabajar con calidad y adaptar el plan diario.

Propietaria de Producto o Product Owner: su tarea básicamente consiste en maximizar el valor del producto resultante, para lo cual gestiona el Backlog, partiendo de las peticiones y necesidades de todas las partes interesadas en el producto (stakeholders). El Backlog es el registro del trabajo pendiente, de las cosas que habría que hacer para que el producto aporte valor. Contrariamente a lo que se ve en algunos equipos, el rol de PR no implica dirigir el equipo o decidir lo que hay que hacer. La figura tiene sentido en tanto y cuanto no es posible tener a la cliente o usuaria real en conversación con el equipo. Una buena Product Owner puede ser un gran recurso a la hora de entender qué es lo más valioso que el equipo debería estar haciendo, algo que sí aporta a un equipo ágil.

Scrum Master: su tarea es velar por el proceso Scrum, ayudando tanto a desarrolladoras, como propietaria del producto y stakeholders. Es un rol muy poco comprendida, en gran parte porque no se sigue Scrum por la guía.

Muchos proponentes de Agile reniegan de Scrum, no sin buenos motivos. Esto ocurre por varias razones, pero quizá las más importantes sean:

• El énfasis en el proceso, mientras que Agile pone las personas por encima de los procesos. Lo que dice Agile es que cada equipo debe buscar, constantemente, su propio forma de trabajar.
• Ha sido secuestrado por el management como forma de control del trabajo de los equipos de desarrollo.
• Las certificaciones han prostituido la naturaleza ágil de Scrum.
• Se han confundido roles, tales como el de product owner o el de scrum master, con puestos. La necesidad de dotar de sentido a estos puestos, ha creado nuevas capas de management intermedio y burocracia… Justo lo que Agile trataba de evitar.