Cuando comencé con esto de Scrum, una de las lecturas que me recomendaron fue “Explicarle Scrum a tu abuela”. Aunque no quiero criticar al autor (él hablaba de autoorganización cuando yo apenas llevaba 2 meses desarrollando software),visto con perspectiva actual, me parece una lectura poco afortunada para quien quiera empezar.
El objetivo principal del artículo era contar Scrum de una manera resumida, por tanto, quiero hacer mi propia evaluación de esta lectura. ¿Cómo podemos resumir Scrum en tres ideas?
Scrum se basa en entregar software terminado en 30 días o menos (en equipos software obviamente). Si no eres capaz de llevar ante un usuario final software terminado en menos de 30 días, olvídate de Scrum.
La segunda esencia es que hay que maximizar valor, es decir, definir el propósito de este software para saber cómo lo vas a medir, y además, para saber en cada iteración si estás maximizando o no. Si no mides valor, no puede ser Scrum porque entonces… ¿qué estás maximizando?
Por último, el equipo debe estar continuamente mejorando. Un equipo Scrum aprende de todo lo ocurrido y toma decisiones para funcionar mejor en el futuro; si no mejoras, no puedes ser Scrum.
Y todo lo demás da igual. Los roles, artefactos o eventos no son relevantes, lo realmente esencial es entregar software en menos de 30 días, entregar software que dé valor, y mejorar. Todo lo demás es secundario. Lo que ocurre es que cada elemento de Scrum busca ayudar a esos tres factores, veamos cómo.
¿Qué elementos de Scrum me ayudan a entregar software en 30 días o menos?
El Sprint aquí es la clave: al tener una fecha de cierre corta, nos ponemos como reto el terminar tareas y eso fomenta que en menos de 30 días entreguemos. De cara a garantizar que “terminar” suponga llevarlo hasta producción y para que un usuario final disfrute este software, existe la Definition of Done. Es cierto que subir a producción depende del Product Owner, pero no lo usemos como excusa para estar meses y meses sin subir nada.
Otro elemento clave es el Sprint Goal ya que, de todo lo que podríamos hacer en el Sprint, el goal nos marca dónde poner el foco. Así, garantizamos que entregamos software terminado, y no muchas cosas medio hechas. Para fijar el Sprint Goal, disponemos de dos elementos: por un lado, la Sprint Planning que nos ayuda a definirlo, y, por otra, la Daily Scrum que nos ayuda a coordinarnos para acometerlo.
Las personas que crearán este software tienen que hacerlo rápido, en menos de 30 días: es un reto para muchas organizaciones. Para eso, tenemos un Development Team, un equipo con unas características muy especiales: no tienen definidos roles, se quiere evitar el modelo “llave-puerta” entre compañeros; se busca que piensen como un grupo para conseguir ese software y se eviten comportamientos del tipo “estoy esperando a que el analista termine”. Así, se necesita conseguir dos principios claves, que los equipos se autoorganicen y que tengan todas las skills necesarias para hacer ese software, lo que conocemos como equipos multidisciplinares.
Además, Scrum les da a este equipo un Sprint Backlog, un plan que les ayuda a inspeccionar y adaptar diariamente su trabajo para alcanzar ese goal y tener software terminado.
¿Cómo ayuda Scrum a que maximicemos valor?
Por un lado, para saber qué es valor, poder medirlo y poder tomar decisiones que nos lleven a maximizar se crea la figura del Product Owner. Esta figura es individual por un motivo fundamental:, si varias personas tienen que decidir qué es valor, podemos retrasar tanto la toma de decisiones que sea inviable que entreguemos software en menos de 30 días.
El Product Owner tiene que tomar muchas decisiones. Para empezar, ordenar el trabajo del equipo para que no pierdan el foco, y para ello utiliza el Product Backlog. El PB proporciona una lista ordenada, lo que obliga a que decidamos qué queremos en cada momento y así, fomentar que acabemos entregando. Además, podemos usarlo para testar con los stakeholders de cara a descubrir qué es valor para maximizar lo que entreguemos.
Otro elemento clave para la maximización de valor es la Sprint Review. Muchas veces el valor es teórico hasta que un usuario lo reciba y se beneficie de él. La Sprint Review nos permite inspeccionar lo que hemos terminado y entregado (incremento) para adaptarnos en la siguiente entrega y que acertemos. La Sprint Review es buen momento para analizar las métricas que definimos, de cara a saber si nos acercamos a lo que queremos conseguir con nuestro producto software.
¿Qué hacemos para mejorar de manera contínua?
Por último, nos falta un elemento clave de Scrum que es el más importante: la retrospectiva. Este elemento lo utilizan muchos equipos, y se puede hacer con juegos de mesa, en un bar con una copa, en un almuerzo, en una terraza… Todo eso es maravilloso, pero si el equipo en el siguiente Sprint no trabaja mejor, ¡no sirve de nada!
Este es el motivo por el que las Retros-post-mortem, que se hacen después de que un equipo haya tenido problemas, pueden ser útiles para desahogarse, pero desde un punto de vista Scrum son poco prácticos porque no ayudan a nada.
Recientemente, se añadió que en el Sprint Backlog se incluyera una mejora y que esta fuera priorizada en el siguiente Sprint para garantizar que, de verdad, mejoramos. Esta regla busca fomentar que mejoremos.
Si hay un elemento clave de Scrum que ayuda a la mejora contínua es el Scrum Master. El Scrum Master tiene como misión enseñar Scrum al resto de roles y a la organización. Debe hacerlo no solo aplicando las reglas, sino usando los valores, principios y herramientas.
El Scrum Master no parará de encontrar nuevas técnicas que ayuden a este equipo a esa entrega: cómo priorizar, cómo desarrollar o introducir cambios en la organización que permita hacer todo esto…
¿Scrum es flexible entonces?
Hay personas que argumentan que Scrum nació como una manera de hacer las cosas pero que su esencia es poder cambiar los elementos para adaptarlos a tu realidad. Si piensas así, me parece bien, pero siempre que entregues software en menos de 30 días, maximices valor y no pares de mejorar. Para los que nos encanta Scrum, creemos que cada elemento que tiene ayuda a hacer eso y por ello, no queremos cambiarlo, por eso preferimos adaptar el equipo a Scrum que al revés aunque sea un camino muy duro. Y que quede claroque tampoco vale seguir las reglas al dedillo si finalmente estamos dando un servicio pésimo.
Y vosotros ¿hacéis Scrum o solo seguís las reglas al dedillo?
