[Leer Waterfall vs SCRUM vs Kanban (II)]

Un día de Enero de 2010 recibí un correo de David titulado "Hacia Scrum-ban" con un archivo adjunto muy interesante. Se trataba del libro "Kanban and SCRUM: how to make the most of both" un libro muy ameno y fácil de leer que explica las principales características del sistema Kanban. Se trata de un sistema muy poco restrictivo que apenas impone obligaciones y que se puede usar en combinación con algunas de las cosas más interesantes de SCRUM. No me voy a parar a explicar Kanban, el libro lo hace mucho mejor por si solo y no cuesta leerlo más de hora o así. Pero sí me gustaría contar en qué cambió nuestra forma de trabajar.

Para empezar eliminamos las reuniones de planificación, dichas reuniones (que nosotros hacíamos por skype) se habían convertido en eternas conversaciones en las que explicábamos una a una las US incluidas en el Sprint y tratábamos de estimarlas. Estimar se nos daba realmente mal, apenas conseguíamos sacar adelante la mitad de lo previsto cada dos semanas (el optimismo del developer es un tema que tarde o temprano habrá que tocar en este blog), aunque seguramente poco a poco podríamos haber ido mejorando. La idea con Kanban es que no hay Sprints y el flujo de users stories entre Product Owner y programador es continuo. ¡Mucho mejor!, así nos podemos centrar en intentar aumentar nuestra velocidad, es decir reducir el tiempo que nos cuesta desarrollar una user story (el lead time). La idea del flujo continuo hace Kanban muy apropiado para sistemas de mantenimiento en los que los bugs llegan de manera inopinada, sin seguir un patrón fijo y el primer programador que se libera de trabajo se hace cargo de ellos. Nuestro caso no era exactamente ése (aunque los bugs iban llegando) pero el hecho de tener, para nuestra aplicación de contabilidad en el móvil, un cliente tan informal como "los comerciantes más humildes de países emergentes" hacía que el goteo de requerimientos y cambios fuera constante y difícilmente encorsetable en forma de Sprints.

Lo siguiente fue crear nuestras propias tablas de Kanban (la real, en la oficina y la virtual en la web ya los POs están en las Américas), una experiencia entretenida (post-its, gomets, cinta aislante, tijeras, una pared grande...) que además al final nos permitió en la parte virtual abandonar AgileBuddy (demasiado complejo y cuyas métricas no acabábamos de entender) y usar en cambio una herramienta mucho más visual, sencilla e intuitiva, como AgileZen. Lo malo es que hay que asegurarse de mantener sincronizadas las dos tablas, pero nos encargamos de ello todos los días justo antes del stand-up meeting. Este tipo de tablas también se pueden usar para SCRUM, nada lo impide, pero en Kanban son imprescindibles porque permiten que todo el mundo sepa lo que está haciendo el resto a la vez que es fácil chequear/limitar el Work In Progress (WIP) que es la clave de todo sistema Kanban.

A todo esto, nada de este cambio hubiera sido posible si a la vez no hubiéramos implementado un sistema de integración continua con el que obtener una nueva versión suficientemente fiable de nuestro producto con cada commit de una nueva user story. Pasamos de un sistema en el que cada dos semanas había que hacer un complicado paso a producción (pero que aún se podía hacer manualmente) a un flujo continuo de nuevas versiones creadas automáticamente en pre-producción y que al final tenían la misma calidad que las de producción del sistema anterior. Julio puede dar más detalles de cómo funciona todo eso y cómo usamos HUDSON & company para este tipo de cosas, pero podemos decir que tenemos la parte de pre-producción totalmente automatizada y ahora hacemos los pasos a producción tanto en teléfono o en la web bajo demanda y con mucha más seguridad de que las cosas van a ir bien.

El resultado de este cambio fue altamente satisfactorio ya que esta nueva manera de trabajar se adaptaba mucho mejor a nuestras necesidades. Esto no quiere decir que SCRUM no valiera, ya que incluso tenemos que reconocer que aún estábamos al principio de la curva de aprendizaje de SCRUM y hacíamos cosas mal. Ahora también... nos pasamos del WIP de vez en cuando, no hacemos todas las retrospectivas que deberíamos, definimos user stories un poco desiguales (de vez en cuando se nos escapa alguna interminable "looser story") pero bueno... nadie dijo que esto fuera a ser fácil y, de hecho, si echamos la vista atrás, creo que podemos estar satisfechos de nuestro recorrido. Además no descartamos recuperar los Sprints de SCRUM para según que proyectos y clientes más apropiados, ni evolucionar a cualquier otra cosa que nos parezca mejor o más apropiada en cualquier momento.