Buenas a todos!
La verdad es que no sé muy bien como empezar… y este siempre ha sido un buen comienzo jejeje.
Hace más o menos un año, conseguí que aceptaran mi propuesta de cambiar la forma de gestionar el proyecto “Estrella” de la división donde trabajo. Este cambio vino ocasionado por el semi-caos en el que nos encontrábamos a causa de problemas internos. En realidad, tuve suerte en este aspecto, fue recibido con buenos ojos, aunque con escepticismo, por parte de la dirección. Los cuales me dijeron “Adelante, necesitamos cambiar esta forma de llevar las cosas, y que todo el mundo vuelva a estar ilusionado con su trabajo”.
Realmente este era uno de los principales problemas, gente desmotivada y quemada por siempre hacer lo mismo año tras año. El otro gran problema, fue el ir dando trabajo a cada miembro del equipo, según iba llegando, asignando tareas según carga, especialidad de cada persona, y urgencia. Es decir, saliendo adelante como bien se podía. La gestión del caos dirían algunos.
Pues bien, Lo primero fue concienciar e informar a todo el mundo, de qué era eso de Scrum y la Agilidad. Tarea muy agradable y fácil para alguien que se había empapado bien de cómo funcionan estos temas, además de estar totalmente de acuerdo con los principios que ello conlleva (Manifiesto Ágil). Después de que todo el mundo diera su aprobado, nos pusimos manos a la obra.
Lo siguiente que hicimos, fue repartir papeles.
- Propietario del producto (Product Owner). Esto fue fácil de elegir, cliente interno, mi responsable técnica de división.
- Equipo. También fue fácil, las 7 personas de mi equipo a las que gestionaba en el proyecto.
- Scrum Manager. Yo mismo, al menos por el principio, ya que era el que me había implicado más en este cambio y el que más conocía estos temas.
Yo como “Scrum Manager” junto con el “Product Owner” definimos como tenía que ser la estructura del “Product Backlog” en un principio, y junto con el equipo, definimos el documento “Sprint Backlog”. Estos dos documentos han ido evolucionando en progresión junto con nosotros y nuestras necesidades.
Teniendo todos los papeles asignados, decidimos una fecha que encajase, para que todas las tareas pendientes de terminar en ese momento, se finiquitaran y pudiésemos empezar el 1º Sprint, lo más limpio que se pudiera. Yo por mi lado, acaparé una pizarra de la sala de reuniones y la acondicioné, para eso que me llamaba tanto la atención “Gestión de tareas por Posit” con un tablero Kamban. Y después de tener todo organizado para empezar, dimos el primer gran paso, la reunión de inicio del 1º Sprint!!!
El 1º Sprint fue el más complicado, pero también el más motivador, tanto para mí, como para el equipo. Creo que lo que más agradable fue ver como los miembros del equipo se divertían “jugando” a estimar con la técnica de “Planning Poker” y como se abalanzaban sobre las tareas para autoasignarselas.
Los principales problemas que detecté en este Sprint, fue la difícil adaptación de los miembros del equipo hacia la auto-gestión y auto-organización. Desde el 1º día esperaban a que yo, como su antiguo jefe de proyecto, les diese las pautas de como implementar y realizar sus tareas, además de esperar igualmente a que les dijese que tarea tenían que asignarse después de terminar otra. Poco a poco esta “manía” se les fue quitando y al tercer o cuarto Sprint ya había desaparecido.
Impresionante-mente al finalizar este 1º Sprint, todas las tareas estaban terminas y funcionando para pasar a producción.
La demo también fue bastante motivadora, enseñando orgullosamente todas las funcionalidades implementadas. Más motivación al canto!
A medida que fuimos metiéndonos en un Sprint tras otro, algunos problemas fueron aflorando. Principalmente la dificultad al estimar la duración de las tareas. Esta ha sido recurrente hasta ahora, y creo que siempre estará ahí. Ya que, aunque las estimaciones cada vez se han ido afinando mas, y la mayoría de veces son acertadas, muchas veces nos encontramos con problemas imprevistos que no supimos ver al discutir sobre la estimación de determinada funcionalidad.
Después de discutir mucho sobre este tema en las retrospectivas, hemos llegado a la conclusión, de que la mejor forma para evitar estos problemas es, dividir al máximo las tareas complejas, para así evaluar más acertadamente las tareas resultantes mas simples.
Después de discutir mucho sobre este tema en las retrospectivas, hemos llegado a la conclusión, de que la mejor forma para evitar estos problemas es, dividir al máximo las tareas complejas, para así evaluar más acertadamente las tareas resultantes mas simples.
Otros problemas con los que hemos tenido que lidiar han sido los siguientes:
- Cambios de tareas a mitad de sprint. Este problema fue de fácil solución. Solo dejamos añadir tareas, si hay alguna/as que el “Product Owner” esté dispuesto a retrasar a siguientes Sprints, que sumen lo mismo que esa nueva en su estimación, que no afecte a ninguna otra y si realmente es necesario para el cliente.
Supongo que habrá gente que no esté de acuerdo con esto, y que diga que Scrum no permite estos cambios, pero yo pienso que así es la agilidad, adaptarse a las necesidades en cada momento 
- Mala comunicación con la parte comercial al no poder estar presentes en las demos. Nuestro centro está en Valladolid (Boecillo) y nuestros comerciales en Tres Cantos (Madrid). Con lo que no les suele ser fácil desplazarse cada dos semanas a la demo. Para solucionar este problema, junto con el “Product Owner” hacemos un documento de resumen de la demo, explicando cada nueva funcionalidad del producto, además de otro tipo de demos especiales para ellos, en las que digamos juntamos varias de las nuestras. Ahora estoy mirando para poner un streaming de vídeo de las mismas y que puedan verlas desde donde quieran, aunque ya sé que no es lo mismo, es mejor que perdérselas ;D
- Implementación de una tarea, haciéndola algo diferente a lo que el “Producto Owner” había pensado. Por ejemplo exportar informes a formatos Office, el equipo hacerlo a formatos de OpenOffice en vez de Microsoft Office como se quería. Esto al principio solía ser habitual, pero lo hemos corregido (casi del todo) actualizando diariamente un servidor de desarrollo interno, en el que se pueden ver las funcionalidades que se van implementando. También me encargo de tener un documento explicativo de cada funcionalidad, antes de la reunión de inicio de Sprint, escrito entre el “Producto Owner” y yo. Así queda todo mucho más claro y los miembros del equipo, pueden pensar en cada tarea antes de esta reunión y tener las dudas preparadas.
- Aparición de errores en las implementaciones después de la demo. Este problema es uno de los peores. Aquí hemos puesto varios frentes. El 1º, empezamos a meter poco a poco técnicas de TDD y Extreme Programing, intentando plagar todo con test para que exploten al mínimo fallo (aún nos queda mucho). Y 2º metimos una 4º columna en el tablero Kamban, en la cual otra persona de la que ha hecho la implementación, tiene que probar la historia de usuario, para que este terminada-terminada, incluyendo revisión de código.
Ha habido muchas cosas que destacar sobre cómo empezamos al principio y cómo vamos evolucionando con la opinión y experiencia de todos. Pero para no alargar esta entrada demasiado, os pongo solo unas pocas:
- Al empezar a meter técnicas de Extreme Programing, la que más suele chocar es la programación en pareja. Normalmente se suele pensar, que se tira el tiempo de una persona, al ponerse dos a trabajar en el mismo ordenador.
Pero como yo me convencí de que esto es erróneo, fue al poner a dos personas con unas habilidades, destacadamente distintas a programar juntas. Una sabe programar, estructurar el código y utilizar el lenguaje de programación bastante mejor que la otra. Y por su parte la otra, sabe abstraerse de la solución, pensar más globalmente y contener en su mente problemas más complejos. Esta combinación de mentes, a la hora de resolver un problema y plasmarlo en código es la mejor que me he encontrado, haciendo que los resultados sean impresionantes. Sin hablar ya, de todos los beneficios que conlleva, como el aprendizaje mutuo, la doble revisión, rápida entrada en estado de flow, mejora de moral, propiedad colectiva del código, etc. Si tenéis la suerte de poder probarlo, no dudéis en hacerlo, veréis los beneficios.
- Como decía antes, el ajuste de las estimaciones suele ser bastante conflictivo. Pero con tan solo un año de ellas a nuestras espaldas, hemos podido comprobar la mejora evolutiva muy a detalle. Un ejemplo que suelo poner, es la estimación de un nuevo informe dentro de nuestro producto. Nuevos informes nos surgen continuamente, todos muy parecidos, pero con necesidades diferentes. Pues bien, en los primeros Sprint, el equipo solía coincidir muy poco en su estimación, unos decían 5 días, otros 1, etc. Con lo que nos salía una media de 3 normalmente. Después de todo un año estimando y todo el equipo repartiéndose los cíclicamente, ahora cada vez que sale uno a estimar, hasta el Product Owner se ríe y murmura 2, antes de que el equipo estime.
Con esto quiero decir, que no solo ahora todo el equipo sabe de sobra que un informe medio se haga en 2 días, sino que, una tarea que hace un año tardábamos 3, ahora la hacemos en 2. Beneficios de la autoasignación de tareas y repartición del conocimiento al autoasignárselas. Posdata hemos conseguido recortar una media de un 33% una tarea que suele aparecer con frecuencia en nuestro trabajo.
- La motivación ha sido otro de los puntos fuertes dentro del cambio. Antes de empezar con él, creo que casi ningún miembro del equipo, estaba contento día a día con su trabajo. Ahora puedo afirmar con seguridad, que todos y cada uno de ellos, no solo se sienten bien y trabajan mucho más y mejor que antes Sino que están tan convencidos de ello, que cada vez que me preguntan algo sobre Scrum delante de alguno, saltan antes de mi respuesta y les explican todo el funcionamiento de principio a fin entusiasmados. Esto es mi mayor motivación diaria.
Aún nos faltan muchos pasos por andar y aún nos faltan muchas cosas por afinar y aprender. Pero sin duda, el producto ha mejorado muchísimo y tanto el equipo, el Product Owner, los superiores y yo mismo, estamos muy contentos con la dirección que todo va tomando poco a poco. Me gustaría hacer más a menudo retrospectivas y unificar en la rueda, la integración continua, la gestión de bugs, testing y despliegues, pero todo se va viendo más cerca y vamos poco a poco.
En resumen, cada día que pasa haciendo Scrum, me convence más, de que para este tipo de proyectos, es la mejor gestión que existe, o que al menos yo conozco.
Salu2!
.
