Scrum es un marco de trabajo que ha aparecido con fuerza en España en los últimos años. Los más viejos del lugar dicen que allá por el 2008 hubo la primera oleada y fue cuando se creó Agile Spain y eventos de relevancia como la CAS. Scrum está calando y poco a poco se está extendiendo como manera de hacer las cosas.
Cierto es, que como indicaba Ken Schwaber, solo el 15 % de los equipos que dicen hacer Scrum realmente lo hacen. Aún así, digamos que los equipos están empezando a funcionar así.
Mi historia cómo Scrum Master
Quería compartir mi historia de cómo acabé siendo Scrum Master. Empecé un proyecto nuevo para un gran banco como Analista Funcional. El proyecto comenzó como lo hacen todos, creamos un pequeño equipo que se encargó de tener mil reuniones con el cliente para entender el problema y crear un documento que refleje lo que íbamos a construir. Este proyecto era sobre medios de pago, por lo que dependemos de muchas áreas de este banco lo que provocaba que el número de reuniones fuera exponencial.
Tras muchos meses entramos en una fase de análisis-parálisis. El documento no paraba de cambiar, cada reunión sumaba problemas y no habíamos creado ni una sola línea de código. Alguien decidió que ya era hora de construir algo y contrataron a un equipo de desarrolladores.
A este equipo le dieron apenas dos meses para desarrollar lo que ponía en un análisis que se había realizado en 7 y que, además, nunca estuvo terminado. El reto no es que fuera inmenso, es que era imposible. Cada día había reuniones para presionar a este equipo y los nervios estaban a flor de piel.
Lo curioso es que llegó el verano y un nuevo director se unió al equipo. Estuvo unos semanas estudiando la situación y llegó a una conclusión evidente para todos pero que nadie la mostraba “esto no iba ningún lugar”. Entonces decidió apostar por Scrum. El equipo que estaba al lado en la oficina ya lo hacía y había pasado por un proceso similar de tortuoso al nuestro y al implantar Scrum habían mejorado mucho, se les veía en la cara.
Scrum se viraliza
Y así aprendí el concepto de “virus” que se aplica en Scrum. Al final, un equipo empieza a probar con eso tan raro, de pronto se ven resultados muy positivos y el resto empiezo a imitarlo. Es verdad que imitar de manera muy rápida, sin preparación y sin interiorizar valores acaba por ser un poco desastroso pero también es verdad que en muchos casos está funcionando.
Por tanto la viralización de Scrum es relevante. Para hacerlo a nivel de equipos lo ideal es crear equipos que se encarguen de la transformación y apliquen el propio Scrum al cambio. Por ejemplo, defines en tu organización todo aquello que se necesita para que un equipo pueda empezar a trabajar así: tener un Scrum Master y un Product Owner reconocido, una visión de producto, KPIs de valor relevantes y un Development Team sentado junto. Esto podría ser nuestro Definition of Ready de la viralización. Después definimos un proceso de cambio: formar al equipo en Scrum, darle las herramientas que necesita, terminar de buscar los perfiles que hicieran falta y construir un Product Backlog primigenio. A partir de ahí el equipo debería estar arrancado para trabajar en Scrum, para cerciorarnos que este proceso es completo podemos definir una Definition of Done que fije los parámetros necesarios: por ejemplo no permitir un equipo sin Scrum Master o sin licencias de un software necesario.
Tablero Kanban de Transformación
La organización podría disponer de un tablero Kanban para gobernar todos estos equipos con un WIP que limite la cantidad de equipos que viralizas. Lo único malo de este tipo de procesos es que, muchas veces nos centramos solo en el medio y no el fin. Si decimos que un equipo hace Scrum no es que tienen una planning o un Jira, es que realmente aportan valor. Para medir eso lo ideal es utilizar medidores de madurez que nos indiquen si realmente los equipos son maduros en Agile o no. Incluso podríamos utilizar NPS para saber el grado de satisfacción de las personas que se inician en Scrum como un feedback para las personas que transforman.
Por otro lado, tendremos que proponer iniciativas transversales que ayuden a la organización a agilizarse. Por ejemplo, romper nichos tradicionales como el Departamento de QA o el equipo de Sistemas. Este tipo de iniciativas deben acompañar a la viralización para que los beneficios se maximicen, para que no sea un Agile Estético.
Estar bien preparados en Scrum
Por último, mucho cuidado con las viralizaciones. Que tendemos a copiar y a imitar es normal, pero cuidado con la fuente. Si los equipos iniciales no tienen una base fuerte en Scrum entonces imitaremos algo que no funciona y el virus podría matarnos. Asesorate por personas que realmente dominen Scrum, son Agile y sobre todo, tenga el coraje para decir lo que falla en una organización y proponer soluciones.
Mucho cuidado en los sitios donde se enseña y practica un Scrum alterado, al final eso es una manera marketiniana de hacer este cambio. No busques imitaciones falsas, trata siempre de hacer las cosas bien, con apoyo de personas con expertise y con liderazgo. Agile no se copia o se extiende, se es y nadie te puede decir si lo eres, simplemente lo sabes.
Y tú, ¿haces Scrum bien?
