Junio de 2010, una sesión cualquiera de la CAS2010, el vehemente speaker azuza a las masas de developers ansiosos de ser más ágiles que nadie:

"Nosotros teníamos un bote para quien rompía la build. Si rompías la build, un euro al bote. ¿¿Vosotros no hacéis eso?? Lo malo no es el euro, lo malo es el escarnio público. Mira el ágil, ahí está poniendo otro euro. El escarnio público es un gran catalizador..."

Rodrigo Corral, CAS2010

... Y nosotros no hacíamos eso :S. ¿Necesitábamos nuestra pequeña dosis de escarnio público?, ¿se rompían demasiadas builds?, ¿se fallaban demasiados ATs fáciles?, ¿iba Rodrigo a aparecer por la oficina cualquier día a infligirnos nuestra dosis de escarnio personalmente por no tener bote?. No podíamos permitirlo.

Dicho y hecho. Visita al chino más cercano, compra de una genuina hucha con forma de cerdito y creación de dos tablas más para colgar en la pared. Una con las tarifas:

• Build rota - 0,5€ de multa para el programador
• User Story que no pasa los AT que le hace el tester - 0,5€ para el programador
• User Story que no pasa los AT que le hace el Product Owner - 0,5€ para el tester
• Stand-up meeting que no empieza antes de las 9:00 CET - 1€ para el KanbanMaster

La otra se hizo necesaria enseguida, ya que la gente se suele gastar el suelto en la máquina de café (edito, acabamos de comprar una Nespresso): la tabla del cobrador del bug, donde apuntamos lo que debemos, para pagarlo una vez recuperada la liquidez.

Misión cumplida, escarnio conseguido. Todo el mundo se preocupa de hacer un poquito mejor su trabajo con tal de ahorrarse medio cochino (por lo del cerdo) euro. ¡Genial!. Y encima acumulamos un pequeño (esperemos) bote... ¿qué hacemos con él?. La resolución de este problema, qué hacer con el cochino bote,  ha supuesto la primera contribución de Frogtek a la metodología Ágil, la primera técnica inventada por nosotros que hemos integrado en nuestro proceso sin demasiado esfuerzo, ni problemas (y si resulta que ya estaba inventada espero que no venga nadie a quitarnos la ilusión).

Volvamos al problema. Los residuos que nuestro proceso de desarrollo generaba eran, en ese momento, dos principalmente: un montón de post-its bicolores (rosa bug, amarillo US) y un bote. El bote crecía internamente dentro de la barriga de nuestro amigo el cerdito y los post-its se acumulaban en la última columna de nuestra omnipresente tabla de kanban y amenazaban con echar abajo nuestra moderna pared de cristal. Solución: crear otra tabla en la pared (por paredes será...) con una fila para cada programador, una vez que una User Story (US) o un Bug está definitivamente acabada se pega en la fila de programador responsable, de forma que la barra de cada uno de ellos va creciendo a un ritmo proporcional a su "efectividad" y el primero que llega a 50 (o a 100) decide qué se hace con el bote. Una imagen vale más que mil palabras:

Más gráfico no puede ser. Esta tabla tiene un montón de cosas interesantes que ofrecer:

• Si le pones separaciones temporales te da información sobre el avance parcial.
• Fomenta la competitividad sana dentro del equipo.
• Da en un vistazo una idea de la salud del proyecto (mucho rosa malo).
• Ayuda a detectar problemas, como US demasiado largas o gente trabajando sin US.

Si el Kanban Master, es decir un servidor, se molesta en contar semanalmente los post-its de la pared se pueden obtener fácilmente gráficas de este estilo entre otras muchas.

Que muestra el número absoluto de US y Bugs finalizados semanalmente.

Que muestra el tiempo que dedicamos cada semana a US y a Bugs, (sí aproximamos la duración de 4 bugs a la de 1 US, sabemos que no es muy exacto en el corto plazo pero esperamos que sí a medio y largo).

Pero no se queda aquí nuestra innovación. Tras ver que este sistema funcionaba bastante bien, ya que es fácil y llevadero y la información que proporciona muy relevante. Decidimos darle una vuelta de tuerca más, ya que aunque estábamos reuniendo un pingüe bote no teníamos información de cuales eran los problemas que hacían que ese bote creciera y creciera y se convirtiera en el oscuro objeto de deseo del primer programador que acumulara 50 post-its. Así que introducimos unas pequeñas modificaciones. Las multas no han cambiado, sin embargo cada vez que una US/Bug no pasa el proceso de Test apuntamos los nombres de los responsables en el post-it de forma que:

• Si la US se echa para atrás porque el Tester no la aprueba, se apunta en el post-it al programador en cuestión (que además tendrá que pagar).
• Si la US se echa para atrás porque el Product Owner no la a prueba, se apunta en el post-it al tester y al programador (y es el tester el que paga la multa).
• Si la US se echa para atrás porque el Product Owner no se había explicado bien o mete nuevos ATs, se apunta al Product Owner (desgraciadamente este no paga porque alimentar a nuestro cerdito vía Paypal nos parecía un tanto complicado, notar que nuestros POs está en sudamérica).

Con todo esto el Kanban Master puede hacer recuento todos los lunes y dibujar gráficas como ésta.

De donde se pueden extraer la siguientes conclusiones:

Si la mayoría de cerditos recaen del lado de los developers (proporcionalmente a su número claro) hay que buscar la manera de mejorar el código que creamos o de que estos aprendan a leer los ATs. Si la mayoría de cerditos recaen del lado de los testers, quizá sea que tienen mucho trabajo y no les da tiempo de probar como Dios manda, o que tienen que concienciarse para ser más minuciosos. Si la mayoría de cerditos son para los POs quizá hay que enseñarles a escribir, o necesitan ayuda para definir las US porque tienen mucho trabajo, o aún están en proceso de adaptación (relacionarse con programadores vía redacción de Acceptance Test no es tarea fácil). Lo bueno de saber que tienes un problema y dónde está es que puedes intentar arreglarlo.

En el próximo post desvelaremos quien ha sido el primer ganador de nuestra particular competición y cuales sus premios.

Saludos!.

PD: El ánimo de esta técnica es la de motivar al equipo, dar trasparencia y detectar problemas o cosas mejorables. El objetivo de la competición es siempre premiar y nunca censurar. Somos conscientes de que no todo el mundo compite en igualdad de condiciones ya que ningún proyecto es comparable al resto y porque el tamaño de las US y Bugs no siempre es homogéneo. No nos importa porque lo único que tratamos de hacer es pasarlo bien mientras trabajamos, nos conformamos con que podamos decir que hemos montado un sistema que se ajusta a nuestra realidad a medio y largo plazo.