Developing Frogtek

El blog del Departamento de Tecnología

Evolucionando hacia Scrumban

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“.

5 Comentarios

  1. Hola,

    Muy interesante y se agradece mucho que las empresas compartáis vuestras experiencias.

    Una cosa que me chirría de vuestro relato es cuando comentáis que tenéis millones de clientes que, claro, no se involucran y que esto os imposibilita aplicar Scrum “correctamente”. Desde mi más sincero desconocimiento, quizá uno de los problemas al aplicar Scrum fue precisamente pensar que tenéis millones de clientes en lugar de pensar que sois una compañía de producto y que el cliente sois vosotros mismos. Entiendo que si se hace Scrum alguien tiene que ocupar ese rol (aunque el “representante” de estos sea el P.O).

    Por otro lado, cuando comentáis que el feedback que recibis es informal. Podriais añadir un apartado en vuestra aplicación (desconozco si ya existe) para que los clientes os envíen las sugerencias, las propuestas de mejora o los errores (entiendo que usáis un bugtracker y que quizá los clientes tienen acceso). Como dicen por ahí: si la montaña no va a Mahoma …

    Quiero aclarar que desconozco mucho vuestro caso (pues llegué a este blog hoy de casualidad) y, tanto Scrum como Agile en la práctica.

    En definitiva, solo quería daros las gracias por compartir estas cosas, aportar mi minúsculo granito de arena y animaros a que sigáis así.

    Un saludo

  2. Guillermo Caudevilla

    22 diciembre, 2010 at 19:10

    Hola SourceRebels,

    Lo primero gracias por comentar. Contesto a tus comentarios.

    Cuando digo que tenemos millones de clientes, me refiero a clientes potenciales (desgraciadamente, jeje). Bueno dicho esto, tienes toda la razón, somos una empresa que está creando un producto y tenemos un PO que dirige la creación de dicho producto. Nuestro principal reto es que si queremos triunfar nuestro producto debe resolver los problemas de nuestros clientes finales y para ello hay que conocer muy bien sus necesidades (como todas las empresas). Esto es moderadamente complicado cuando tu cliente es conocido y es otra empresa que te pasa un conjunto de requerimientos, es más complicado aún si tu cliente final no es alguien concreto sino un conjunto de potenciales clientes de tu mismo “plano social”… pero es rematadamente complicado cuando los potenciales clientes viven en países en desarrollo o el tercer mundo y tienen una realidad y unas necesidades que es imposible conocer desde Huesca o desde Nueva York (que era dónde estaba equipo y PO respectivamente cuando empezamos con el Scrum). Creo que debería haber empezado comentando qué es lo que hacemos en Frogtek, que son aplicaciones en teléfonos móviles para gestionar micro-negocios en países emergentes y del tercer mundo. A priori parece algo fácil de hacer, pero te puedo asegurar que un diseño hecho en España o en USA y llevado a Colombia no resiste el primer contacto con un tendero de barrio.

    Respecto al tema del feed-back, también es muy importante lo que dices. Hemos mejorado bastante desde los meses en los que “hacíamos” Scrum al principio, ahora tenemos gente allí, no vamos a salto de mata como cuando nuestro CEO hacía sus visitas relámpago a Colombia, hacemos de vez en cuando sesiones de pruebas de Usabilidad con tenderos y, por último, hemos integrado nuestra herramienta con ZenDesk, de forma que nos llegan notificaciones cada vez que algo casca y podemos recibir feed-back directamente desde los tenderos.

    Un saludo!

  3. Gracias por la parte que me toca… Es una gozada ver que las cosas que uno va pregonando le sirven a la gente para mejorar 🙂

    Seguid duro!

  4. Excelente articulo y buen ejemplo del principio de Deming y que Agile no significa en absoluto quedarse parado en un punto.

    Suerte en vuestra misión.

  5. Es estupendo ver vuestra evolucion. Tengo ganas de sentarme a trabajar con vosotros unos dias y aprender de toda esta parte de gestion del equipo. No siempre lo mejor es enemigo de lo bueno 🙂

    Seguid asi! 🙂

Deja un comentario

Tu dirección de correo electrónico no será publicada.

*