¡Scrum no es una técnica para hacer software! Quizás esta sea una de las grandes confusiones de Scrum y también de que los amantes de las buenas prácticas renieguen de Scrum. Sin embargo, muchas empresas han usado Scrum como una bala de plata que iba a solucionar sus problemas para desarrollar software ¡Ese no es su cometido!
La paradoja de la motosierra
Imagina que todos tus vecinos se compran una motosierra. No tiene mucho sentido, la mayoría de ellos tienen uno o dos árboles en su jardín y tener una motosierra para cortar ramas cada varios años sería poco rentable. Sin embargo, es la moda y nos arrastra. Por lo que decides que vas a adquirir tu propia motosierra.
Además, podemos enseñar nuestra nueva motosierra turbo 3000 a los vecinos, “picarnos” por ver quién tiene la mejor. Incluso podemos hacer un concurso para averiguar quién usa mejor su motosierra, ¿tendría sentido cuando apenas hay diez árboles sumando todos los jardines?
Una motosierra es una herramienta útil si tienes muchos árboles que cortar porque necesitas leña pero inutil si tu problema es diferente. Además, una motosierra es costosa, cara de mantener y encima puede provocar accidentes si no se usa correctamente. ¿nos recuerda esto a Scrum?
Scrum nació lejos del Software
El marco de trabajo de Scrum actual que tenemos en las organizaciones y basado en la Scrum Guide bebe de muchas fuentes diferentes. De hecho, si estudias el libro de Jeff Sutherland, te das cuenta de que muchos elementos de Scrum son copias o adaptaciones de diferentes estudios o equipos. De todas estas fuentes, la más relevante es el artículo The New New Product Development Game que escribieron Nonaka y Takeuchi en la Harvard Business Review en 1986. En este artículo, Nonaka y Takeuchi analizaron diferentes equipos que funcionaban muy bien y sacaron un factor común. En este artículo aparecían conceptos como autogestión, multifuncionalidad o liderazgo servicial. De hecho, los autores contrastan el modelo tradicional “Nasa” contra el modelo llamado “Rugby” (recordemos que Scrum significa melé, una jugada del rugby)
Lo curioso de este artículo es que el análisis se hizo sobre equipos alejados del software: impresoras, cámaras fotográficas… Es decir, la idea de equipo unido que trabaja sobre un objetivo concreto y con autogestión nació lejos de las líneas de código y siendo mucho más ambiciosa.
¿Scrum y software?
Existe una realidad palpable de que Scrum se asocia a software en casi todas las empresas. Para empezar porque Scrum actual nace del trabajo que realizan Jeff Sutherland y Ken Schwaber en equipos de software. De hecho, fue presentado en 1995 en la OOPSLA, un evento de desarrollo de software que se celebra anualmente en Estados Unidos. Además, Scrum se empieza a popularizar con la aparición del Agile Manifesto en 2001, donde Ken y Jeff participaron.
En estos 22 años, el desarrollo de software ha liderado muchos de los cambios que han ocurrido en la humanidad. Con la popularización de internet, la aparición de los smartphones y las redes sociales, hoy en día vivimos de una manera muy diferente. Estos cambios de hábitos generaron una necesidad de cambios en el desarrollo del software.
¿Para qué sirve Scrum?
La definición formal de Scrum actual y que ha evolucionado desde 2010 es la de un marco de trabajo ligero que busca ayudar a personas, equipos y organizaciones a generar valor mediante soluciones adaptativas para problemas complejos.
Su función es entregar valor por encima de hacer software. Sí, cuando tratamos de un problema digital el valor estará en ello. Sin embargo, mayor cantidad de software no garantiza mayor valor, esto dependerá del problema que dicho software resuelva.
Quizás esta sea la principal aportación de Scrum al desarrollo software, lo que denominamos el value thinking. El pensar en valor nos hace entender qué, implementar unos requisitos que nos han definido y conformarnos no es suficiente, hay que garantizar que nuestro trabajo generar un impacto en el cliente, que resuelve su problema o que estaría dispuesto a pagar por ello.
Cuando pensamos en valor, todo cambia
Existe una cierta psicosis en encontrar técnicas o herramientas que permitan a nuestros equipos desarrollar más rápido. Buscamos productividad y nuevas formas de que los equipos mejoren. En el sector del software principalmente tenemos la sensación de que, por algún motivo, se podrían hacer las cosas mejor. Sin embargo, nos cuesta identificar el qué.
Scrum propone un cambio importante: dejar de pensar en tareas y estar ocupados para pensar en valor e impacto. Este cambio es clave, porque ataca a la base de nuestras organizaciones: departamentos tratando de ser óptimos, jefes de proyectos que coordinan equipos, estrategia poco transparente para la mayoría de la empresa…
Cuando medimos valor y hacemos responsable al equipo, empiezan a surgir cambios: ¿Necesitamos reuniones para validar el valor? ¿Por qué este departamento no colabora para conseguir valor? ¿Nos deberíamos reunir con los clientes para entender el valor que necesitan?
Todo suma, y todo cambia una vez que medimos y fomentamos el value thinking.
Y tú, ¿mides valor en tu equipo?
