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!
Excelente artículo! Ojalá muchas empresas y potenciales clientes lo lean y vean todo lo que pueden ganar
Muy interesante Álvaro. ¡Enhorabuena!
Me ha resultado especialmente inspirador sobre todo la parte de separar las asignaciones de las pruebas y la implementación, y planificar como tareas las revisiones de código, que realiza otra persona y no necesariamente un “superior”.
Gracias por compartir la experiencia.
Lo primero, felicitarte Alvaro, por este año de trabajo. Enhorabuena!!!
De todo el proceso, leo que la primera parte de concienciar a la gente no supuso problema. Alguna recomendación en particular? Usaste tecnicas de persuasion? Manipulacion?
Y la otra parte, que a mi personalmente me gusta, es que no nombras herramientas de gestion de Scrum, utilizais tableros. ¿Os lo habeis planteado?
Gracias por hacernos participes de tu experiencia
Amalia
Excelente artículo Álvaro. Gracias por compartir tu experiencia.
Un par de dudas
- Has adoptado el rol de scrum master pero ¿sigues desarrollando en el equipo o te lleva el 100%? He leído opiniones en contra y a favor y yo personalmente prefiero continuar en el equipo reduciendo sprint a sprint el tiempo de SM hasta que sea prescindible ¿cual es tu opinión?
- Hablas de hacer pair programming juntando dos perfiles muy distintos ¿algún problema cuando intercambian los papeles de driver y navigator? ¿qué tal la experiencia en otras parejas más homogéneas?
Gracias de nuevo
Edu
Lo 1º Muchas gracias a todos por leerlo con tanto interes!
Amalia, la única recomendación que te haría en el aspecto de convencer a la gente, es que les cuentes todo. Es decir, todo lo bueno que tiene, y todo lo malo. Los posibles problemas que pueden surgir trabajando de esta forma, como por ejemplo los proyectos en los que el cliente no coopera o los que te piden todas las fases de desarrollo en cascada, como un análisis profundo al principio para entregar documentos. Bueno, y otra que creo que a mi me salio espontáneamente, explica lo con pasión
Y con el tema de los tableros, utilizamos físicamente solo el kamban en la pizarra. Pero me gustaría probar algún otro. A ver si te animas y nos escribes una entrada sobre tableros
Saludos!
Buenas Edu,
Actualmente no desarrollo con la gente del equipo, excepto en casos puntuales de ayuda. Me dedico más a los despliegues, mantenimiento de los clientes, y resolución de problemas del equipo.
Personalmente en ese aspecto me siento un poco prescindible, aunque aun no del todo. Coincido contigo en que lo mejor sería llegar a conseguir un equipo totalmente autogestionado.
Con el tema de programación en pareja, si que hay muchas veces, que se tiran mucho tiempo sin intercambiar pareja, y tienes que decirles, que prueben a rotar más. Pero por lo demás no hay problema, de echo todo lo contrario, se aprende mucho uno de la forma de pensar del otro.
Con parejas de otro estilo he probado que en modo tutor, un junior puede aprender mucho más rápido. Pero en parejas del mismo nivel…. creo que cuenta mucho la disciplina y la psicología de cada uno. Bueno, es difícil y al llevar poco tiempo haciendo esto, aun no tengo conclusiones.
Ya os informaré
salu2!
Buena entrada Alvaro, me gusta mucho el artículo y como has sabido explicar tu propia experiencia.
Yo personalmente me quedo con la frase en la que dices “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”. Estoy totalmente de acuerdo con esta frase, hay mucha gente que es demasiado dogmática o más bien fanática, aunque para empezar esta bien seguir “el libro de Scrum” al pie de la letra hay que saber adaptarse a las necesidades de cada uno.
Con respecto a lo que comentabas con Amalia acerca de las pizarras, nosotros tenemos la nuestra organizada con Kanban-Boxes (te recomiendo el artículo de Juan Palacio si no lo has leido ya que me da que sí) o algo similar a eso, y nos funciona muy bien, aunque el uso de Kanban es algo que también nos ha ido bastante bien al igual que vosotros.
Muchas felicidades por el trabajo realizado, y a seguir mejorando
Buenas Yeray,
Estoy de acuerdo contigo, creo que en estos temas, los extremismos no son nada buenos.
Si, como no! Juan Palacio ha sido mi mentor y maestro, aunque él no lo sepa jejej.
Gracias por leerme!
Salu2!
Un artículo fantástico, enhorabuena.
Aporta mucho valor leer experiencias reales y no solo “teoría”. Muchas gracias por compartir tus impresiones con nosotros.
Un saludo