"Hacer Scrum" tiene tan poco sentido (y es tan imposible) como crear una instancia de una clase abstracta. Scrum es un framework para sacar a la superficie las disfunciones organizacionales. No es un proceso y no es prescriptivo. El framework básico de Scrum (como ya lo vimos) no hace nada. Es, en un sentido, un contrato que ponemos entre quienes buscan valor y quienes lo construyen. Pero un contrato no produce nada. Una interfaz es pasiva. Necesitamos una implementación.
Scrum comienza a funcionar cuando las personas lo entienden lo suficientemente bien como para crear una implementación concreta, para que surja un proceso propio. Comprender y respetar el framework de Scrum y su conjunto de reglas nos permite alinearnos con otros, tener un conjunto común de valores y principios con los cuales operar.
Scrum puede verse como algo similar al conjunto de reglas de un juego. El ajedrez, el fútbol. Es fácill aprender las reglas, y al conocerlas podemos jugar con otros. Las reglas son lo que nos mantiene juntos. Pero saber las reglas no signifca nada en términos de sacar placer del juego. Necesitamos jugar, estar involucrados. Jugando es que se obtienen resultados, no sabiendo las reglas. Para jugar bien necesitamos desarrollar una estrategia, y en juegos de equipo necesitamos crear relaciones e interacciones de confianza.
En cualquier juego, una vez que empezamos a romper las reglas todo se viene abajo, nadie va a querer jugar con nosotros. Lo mismo ocurre con Scrum.
Entonces, respetar el contrato, las reglas (o en términos de software, las interfaces) nos permite crear un proceso que se adapta a nuestro contexto - y nuestro contexto es muchas cosas... personas, industria, negocio, mercado, producto, ubicación, idioma, entorno físico, cultura, personas. Empieza y termina con personas. Scrum no hace nada, las personas hacen. El proceso de Scrum emergerá a través de las interacciones de las personas, y será diferente en cada equipo y organización. Y aquí es donde las personas se tropiezan; muchas piensan que para crear su propio proceso necesitan romper las reglas. No. Si hacen eso, van a fallar antes de empezar.
El proceso de Scrum que se genere debe operar dentro de los parámetros acordados, debe seguir las reglas. Todos los métodos de la clase abstracta tienen que estar implementados, sino la clase no va a compilar, no va a funcionar. Si tratan de mover un alfil en línea recta en el tablero de ajedrez, el contrincante va a retirarse del partido. Si agarrás la pelota de fútbol con la mano te vas a ganar una tarjeta roja.
El framework de Scrum es un mecanismo poderoso para sacar a la superficie problemas organizacionales y personales. Y es este mismo poder el que hace que las personas intenten esquivar las reglas, tomar atajos. No quieren ver. Pero los problemas no desaparecen por no mirarlos, tan sólo demoramos el choque inevitable. No en vano uno de los valores de Scrum es el coraje.
Entonces no tiene sentido comparar a Scrum con prácticas de implementación, como Extreme Programming u otras técnicas. Cada uno de estos movimientos ofrecen excelentes herramientas para implementar una sólida práctica de Scrum, para hacer concreto lo abstracto. Scrum ofrece un framework robusto y un ritmo insesante para quitar el polvo acumulado durante los años.
No podemos "hacer Scrum" pero definitivamente podemos adoptarlo, y mientras más coraje tengamos más robusto será el proceso emergente.
