Creo que fue Heráclito el que dijo que "todo fluye", bueno según Wikipedia dijo "En un río entramos y no entramos, pues somos y no somos", mucho más poético y críptico... Pues bien, en Frogtek no sabemos si todo fluye o no, si somos o dejamos de ser, y de momento, lo de entrar en el río, dado que fuera (en Morillo) a la orilla del río Cinca, hay unos tres grados bajo cero, no nos lo planteamos. Lo que no ha dejado de cambiar desde que empezamos con los método Ágiles ha sido nuestra tabla de Kanban, ni nuestra forma de trabajar. Resumamos en unas lineas nuestros "vagabundeos" por este mundo de las metodologías ágiles.

Tras darnos cuenta enseguida de que Waterfall no nos servía para Frogtek, empezamos queriendo implementar Scrum, y con toda nuestra buena voluntad tratamos de adquirir todos y cada uno de los artefactos que Scrum define. Nos surgieron varios problemas, a saber, reuniones interminables de planificación, estimaciones poco afortunadas, cliente ausente... Lo del cliente merece una explicación, nosotros creamos software para pequeños tenderos en países emergentes, hay millones de ellos pero nunca se van a involucrar real y profundamente en un proceso de diseño como el nuestro (suficiente trabajo y problemas tienen), además nuestro potencial cliente no era uno sólo de ellos o un grupo de tenderos, si no los tenderos del mundo en general, casi nada. El resultado es que David, el CEO, hacía de PO, diseñaba las funcionalidades en función del feed-back informal que recibía en sus visitas por las calles de Bogotá y las empaquetaba en Sprints para que nosotros programáramos.

Pronto nos dimos cuenta que necesitábamos algo más flexible, las reuniones de planificación no es que fueran muy útiles (3 horas de reunión es la receta perfecta para el aburrimiento), no entendíamos bien los datos, burn-down charts, que nos proporcionaba nuestra excesivamente completa herraminenta AgileBuddy, no dábamos ni una con las estimaciones y sobretodo el feed-back recibido por los tenderos no era ni formal, ni periódico, ni definitivo, por lo que las prioridades cambiaban rápido, incluso demasiado para Scrum. Así que Kanban nos pareció más adecuado: implementemos sobre la marcha lo que el PO decida que necesitamos en cada momento y saquemos 10 ó 20 versiones de pre-producción al día (gracias a Dios, bueno y a Julio, por la Integración Continua y HUDSON) y versiones de producción bajo demanda. Perfecto cuando tienes 5 tiendas. Además puedes diferenciar entre US y Bugs, medir la velocidad semanal.

El problema surge cuando en lugar de 5 tiendas alrededor de nuestro apartamento de Bogotá tenemos 25, 30 o más repartidas por toda la ciudad. Y qué ciudad. Moverse de una tienda a otra puede costar cerca de dos horas en algunos casos, la conexión para que los tenderos puedan actualizarse automáticamente TiendaTek (como hacemos en segundos en España) funciona de pena. En resumen aunque la tecnología esté preparada para escalar sin problemas, los temas operativos a pie de calle son un verdadero reto, y cada vez que sacábamos una nueva versión era un dolor de cabeza considerable, primero por lo costoso del despliegue y segundo porque aparecían bugs que nos complicaban todo más si cabe.

Así que se acabó el aquí te pillo aquí te mato (fue bonito mientras duró) y empezamos a plantearnos evolucionar poco a poco hacia Scrum de nuevo. Básicamente retomamos los Sprints de entre 1 y 2 meses, ya no era viable hacer versiones del software del teléfono cada 2 semanas, nos olvidamos de herramientas personalizadas online y recuperamos las reuniones de planificación, aunque seguimos sin estimar de manera propiamente dicha (ya hablaremos de esto pronto), sin embargo la manera que tiene Kanban de tratar con la gestión de Bugs nos seguía gustando... Y en estas apareció Medinilla, su presentación de Scrumban en la Agile Open Spain y casi nos "corren a gorrazos" porque el pobre Pedro definió lo que hacíamos en Frogtek en una de las sesiones como "Kanban puro". Puro, el que nos metieron.

La consecuencia fue una magnífica reunión de retrospectiva donde dimos unos cuantos pasos adelante y entre los más importantes, el pomodoro síncrono (¡que funciona!) y migrar a un Scrumban más académico. O "lo que es lo mismo" una nueva versión de nuestra tabla, con dos filas (por proyecto, aunque esto realmente da igual) una para las US de Scrum (las que hemos planificado para el Sprint), la superior, otra para los Bugs (los errores que surgen sin previo aviso) y US de Kanban (las que no estaban planificadas, pero surgen por urgencias de todo tipo o mala planificación), la inferior.

Esto nos permite medir nuestra velocidad de Scrum, nuestra velocidad de Kanban "bueno" y la de Kanban "malo". O lo que es lo mismo, si definimos:

• [VS], velocidad Scrum
• [VK+], velocidad Kanban bueno
• [VK-], velocidad Kanban malo
• [VT] = [VS] + [VK+] + [VK-]

podemos saber cosas como:

• El nivel de trabajo máximo al que nos podemos comprometer en un momento dado, [VS] + [VK+]
• El nivel de trabajo medio que sacamos normalmente adelante, [VS].
• La tasa de fallos que tenemos, [VK-] / [VT].
• El "focus factor", o cómo de enfocados estamos, [VS] / ([VS] + [VK+])

Con un buen equipo de programadores [VK-] debería ser pequeño, con un buen PO y Scrum/Kanban Manager (y un buen cliente, por pedir que no quede) [VK+] debería ser pequeño y por lo tanto el Focus Factor grande cercano al 100%. El objetivo, acercarse al Nirvana de cualquier start-up, "hacemos lo que estaba previsto hacer y a la primera lo hacemos bien". Si ya encima te pudieras asegurar de que la US en cuestión era lo que quería el cliente y la va usar realmente...

Al final del proceso y si cuentas las US y Bugs que se terminan cada semana te sale una gráfica como la siguiente*.

* En la gráfica a parte de ver los puntos de Scrum (en azul y morado), los de Kanban bueno (en amarillo y naranja) y los de Kanban malo (en rojo) tenemos una diferenciación más: entre US que aportan nueva funcionalidad al usuario y US de infraestructura que que no aportan directamente pero son necesarias para optimizar o como base tecnológica para hacer luego alguna otra cosa. Tuvimos que meter esa diferenciación para controlar el trabajo en las "catacumbas" de nuestros productos, ya que a veces pasar la escoba es necesario y hasta divertido, pero no tenemos que olvidar que nuestra prioridad es el cliente y que "lo mejor es enemigo de lo bueno".