Como no todo es blanco o negro, las metodologías ágiles tienen también muchas cosas buenas. Una de las más sencillas de implementar y con la que conseguir mejoras son las reuniones diarias. Intentamos ya en varias ocasiones hacer Scrum y Kanban, incluso TDD y varias más de las metodologías/prácticas ágiles. Aunque seguimos en el intento, la reunión diaria es la más fácil de seguir y de la que obtener ventajas rápidamente.
La hora teórica de entrada es las 8:00. Habitualmente la gente suele ir llegando sobre las 8:30 y lo primero que hago es ir a tomar café con mi amiguete y luego revisar el correo, el Hudson y el Taskfreak. Imprimo este último y con él, sobre las 9:00 hacemos nuestra reunión de 10/15 minutos. Antes éramos cuatro en la reunión, ahora sólo somos tres.
La reunión la hacemos sentados. Las buenas costumbres aconsejan hacerla de pie para que la gente esté incómoda y la reunión no se prolongue más de la cuenta, pero con el tiempo hemos conseguido no tener ese problema, rara vez dura más de 10 minutos y nos permitimos hacerla sentados.
¿Qué mejoras hemos conseguido con la reunión diaria?
Sensación de grupo
La primera y más importante es la sensación real de la gente de formar parte de un grupo. En nuestro caso concreto, si lo de contar "qué hicimos", "qué vamos a hacer" y "qué problemas tenemos" nos lleva realmente cinco minutos (sólo somos tres), solemos permitirnos unos cinco minutos más de reunión para "cotilleos": comentar como van las pruebas de un proyecto, qué tal le va a uno que está desplazado en la India, los planes del jefe de mover a cierta persona a otro proyecto, etc, etc. Todo esto, además de reforzar la sensación de equipo de trabajo, también refuerza algo los lazos de compañerismo.
Dije que antes eramos cuatro y ahora somos tres. ¿Qué pasó con el cuarto?. Simplemente que le propusieron pasarse a algo más adecuado a su perfil (administrador en vez de programador) y depender de otra persona que no era yo. Pero cuando se lo propusieron, dijo que no quería cambiar del todo, se sentía muy integrado en nuestro grupo y no quería perder eso.
Fue realmente una sorpresa esta objeción. Cuando estaba en nuestro grupo tendía a distraerse de las tareas de programación para dedicarse más a instalar tarjetas de red, configurar routers, instalar software, etc, se le veía claramente que le iba más eso que programar. Le propuse el cambio a mi jefa y ella me dio la razón, pensó que esta persona podía disfrutar más de su trabajo en el grupo de administradores y le propuso el cambio. Y la objeción fue imprevista, efectivamente, dijo que le gustaba más instalar cosas que hacer software, pero que no quería cambiar por sentirse muy integrado en nuestro grupo. Así que el cambio fue gradual, pasó a realizar tareas de administrador poco a poco y siguió acudiendo a nuestras reuniones para hacer su parte de trabajo de programador. Al final la realidad se impuso y realizar dos papeles distintos es imposible, así que dejó cogiendo cada vez más trabajo de administrador y menos de programador y dejó de acudir a las reuniones de forma natural.
De hecho, los tres que quedamos estamos a punto de trabajar en cosas totalmente distintas (tres proyectos distintos, con tres jefes de proyecto distintos y temáticas totalmente distintas). Pero de común acuerdo hemos decidido seguir haciendo las reuniones porque a fin de cuentas el software es software, los problemas son similares y si alguien tiene un problema y lo cuenta a los que ya considera sus compañeros, enseguida se prestan a ayudarle a resolverlo.
Enfocarse en las tareas concretas del día a día
El tener nuestra lista de tareas y decir a primera hora de la mañana "hoy voy a hacer esto" hace que el resto del día tengas claro qué vas a hacer. Supongo que hay algunos que no necesitan este tipo de cosas, pero yo soy de los que tiende a saltar de una cosa a otra. "Comprometerme" con el grupo a que ese día voy a hacer determinada cosa (aunque ninguno de ellos dependa de que yo lo haga), me pone una pequeña traba a distraerme. Me daría vergüenza al día siguiente decir "no he hecho esta tarea porque he estado mirando el correo, navegando por internet, mirando otra vez el correo, un café, probando una herramienta que me he encontrado …."
Así que lo dicho, decir en público "hoy voy a hacer esto", de alguna forma te obliga a centrarte en hacer exactamente eso.
Saber dónde se va el tiempo e incentivo a la mejora
A pesar de todo, en muchas ocasiones, al día siguiente acabas diciendo "No he terminado la tarea que dije ayer" y cuando llegas a la parte de los problemas que has tenido para acabarla dices "me han llamado a una reunión de tres horas", "Se han llevado un ordenador del laboratorio que hacía puerta de enlace de la red del laboratorio y me he quedado sin conexión con los equipos", "me han pedido hacer esto de otro proyecto", etc, etc, etc.
Algunas cosas son inevitables, pero al menos eres consciente de dónde se pierde el tiempo, ya que tienes que decirlo claramente a tus compañeros. Pero cuando esas pérdidas de tiempo tienen arreglo, enseguida "canta" que perdemos el tiempo por algo que hacemos mal y que se puede arreglar/mejorar. Justo lo que pregona Scrum. Aunque en nuestro caso ha quedado un poco fuera la figura de Scrum Master, siempre alguno del grupo coge como tarea mejorar eso que dificulta el trabajo.
Aprovechar la capacidad de los mejores
Y aunque los mejores del grupo o con más capacidad posiblemente no necesiten estas reuniones para centrarse en lo que tienen que hacer o para mejorar su propio proceso de trabajo, no todos tienen esa capacidad.
En estas reuniones las personas de más capacidad se hacen también conscientes de los problemas de los demás, no sólo de los suyos propios. Son capaces incluso de ver posibles mejoras en donde la otra persona ni siquiera ha detectado un problema. De esta forma, todos se benefician de los mejores aunque no vayan específicamente a preguntarle por un problema concreto.
Y los mejores tampoco son infalibles, muchas veces alguien no tan bueno es capaz da una idea o propone algo que se le había escapado
Resumiendo
Resumiendo, que estamos encantados con nuestra reunión diaria y que aunque tiene pinta que el grupo se disgrega (cada uno a su proyecto), por unanimidad queremos seguir haciéndola. Quizás el tiempo nos diga que carece totalmente de sentido… o quizás no.
Y aunque se puede ver claramente que no hacemos una reunión diaria al puro estilo Scrum (no la hacemos de pie, no hay tablero aunque sí lista de tareas, no ha scrum master propiamente dicho), la mejora es apreciable por todos.
Tengo un compañero, informático, que es de los que lleva ya muchos años en la empresa. Hace ya bastante que dejó de codificar y se dedica a llevar proyectos, o sea, Power Points, Project, Word …
Siguiendo un poco con el post anterior, hace tiempo en 
Bueno, parece que últimamente las malas son las metodologías tradicionales y las buenas son las metodologías ágiles, pero a fin de cuentas, ambas son metodologías y las metodologías, en general, presentan sus problemas. ¿Por qué?. 