Tal vez un título muy generalista pero antes de contar el porqué comenzaré por el principio :)
La Historia
Tras unos años en el mundo del desarrollo de software, acostumbrado a proyectos gestionados en cascada y con roles con responsabilidad determinada, en un proyecto con un proveedor de outsourcing comienzo a oír la palabra “Scrum”. Nos encontrábamos embarcados en un proyecto “bicicleta”, se habían recortado funcionalidades para poder entrar en costes, pero el lado comercial era un coladero de funcionalidades con poca comunicación con la parte técnica. La parte técnica era la que estaba involucrada en el proyecto junto con el proveedor. La toma de decisiones con el cliente llegaban a la parte técnica del proyecto con “Es que hay que hacer esto porque se lo hemos dicho al cliente…”
Aunque el acceso a los jefes de proyecto y de área era muy lineal, al final a la hora de exigir responsabilidades cada uno se mantenía en su escalón aunque aguantábamos la carga general conjuntamente. Estábamos obcecados en tener un control excesivo del proyecto, notábamos falta de control y comunicación. El intentar cerrar el acuerdo con el cliente a base de contratos, el recurrir a la oferta y al contrato con el cliente para defender batallas internas de responsabilidades de la perdida que estaba generando el proyecto se estaba convirtiendo en algo frecuente y con ello la sensación de entrar a la oficina con la coraza puesta dispuesto a luchar con el que se ponga por delante.
Al final el proyecto salió, a base de horas, esfuerzos personales y negociaciones con el cliente. Aunque no era el responsable de números, estaba claro que ese proyecto fue una perdida para la empresa.
Os puedo asegurar que tuve muchos dolores de cabeza y roces con compañeros a nivel profesional a causa de este proyecto. Cuando pasa el tiempo te lo tomas a “broma” aquellos días en los que te quedas trabajando 12 o 13h porque “Hay que entregarlo mañana…”, “Es para ayer…”, “Tiene que estar hecho…” y el trabajo de un día de 13h se echaba a perder. A nadie le gusta invertir su tiempo en algo que luego se tira, aunque a final de mes tengamos la nómina asegurada. Esto causa desmotivación y por lo tanto bajo rendimiento.
Pero algo bueno salió de este proyecto. Scrum llegó a mis oídos y a los de mi jefe de proyecto. Comenzamos a valorar la opción de intentar aplicar Scrum en el equipo y a conocer un poco la metodología. El proveedor de servicios lo utilizaba y a él le funcionaba con sus clientes, ¿por qué no tendría que funcionar con nosotros?
En el siguiente proyecto intentamos aplicarlo. Nos creamos nuestro product backlog a base de funcionalidades y a crear sprints de desarrollo. Funcionaba! el desarrollo comenzaba a ser más visible y el dueño de producto priorizaba las funcionalidades e iba viendo su resultado.
A día de hoy
Bien esto paso hace ya casi un año, ahora en mi nueva etapa profesional he tenido la suerte de toparme con una empresa que cree fielmente en esta metodología.
Hoy ha finalizado un curso de Scrum Master impartido por Angel Medinilla en donde me he sentido identificado en muchos de los ejemplos que ha ido exponiendo a lo largo del curso. Es difícil encontrarse con un comunicador de este calibre, una persona que a parte de transmitir su experiencia, inculcarnos la manera de trabajar de manera ágil también hace ameno el aprendizaje. Sinceramente, la sensación tras finalizar el curso ha sido de: “Vamos a comenzar a utilizar esto al 100%, ya!!… ” Con motivación!!
Al identificarme en muchos de los casos de “error” en el desarrollo de software no puedes evitar el que te venga a la mente todos aquellos proyectos en los que “sufriste el parto” y aún así recordar que en ese momento pensabas que lo estabas haciendo de la manera correcta. Ahora simplemente lamento haber conocido esta metodología “tan tarde” pero a tiempo!! que es lo importante y con la suerte de que no tengo que “Luchar” para incorporar esta metodología de trabajo dentro de la empresa, si no que la empresa apuesta por esta metodología al 100%.
Está claro que en la parte técnica es fácil que pueda cuajar esta metodología, pero no es sólo trabajo de los “pica teclas”. Introducir esta metodología en una empresa con una estructura piramidal firme y acostumbrada a desarrollar proyectos de manera convencional seguro que es una tarea difícil. Tiene que ser un esfuerzo conjunto por todos los roles que forman parte de la corporación, ya que sin esta convicción el equipo de desarrollo nunca será ágil y la lucha “Técnico vs Comercial” se mantendrá por la eternidad…
Desde mi incorporación hemos utilizado esta metodología y fui adquiriendo conocimientos que no tenía de Scrum, pero el curso ha sido una manera de reflexionar y reforzar esos conocimientos que me estaban transmitiendo mis compañeros de trabajo.
Desarrollar utilizando Scrum es divertido, tengo que reconocer que tengo una fiebre extrema por los gráficos burn down que me presenta Jira pero he aprendido a hacerlos a mano y como interpretarlos con un simple vistazo. No sólo nos han explicado como funciona Scrum, si no la combinación con otras metodologías como Extreme Programing y Kanban.
Conclusión
Hoy estoy tan convencido del uso de Scrum que me estoy planteando la opción de utilizar Scrum para la gestión de mi agenda personal :-) Scrum-Alone
Referencias de interés
Scrum Definición de Scrum en Wikipedia
Programación Extrema (XP) Definición de Programación Extrema en Wikipedia
Kanban Definición de Kanban en Wikipedia
http://www.presionblogosferica.com/ Blog de Angel Medinilla
http://www.agile-spain.com/ Comunidad sobre métodos ágiles.
Manifiesto Ágil
http://groups.google.es/group/agile-spain Lista de correo de la comunidad de Agile Spain
