Developing Frogtek

El blog del Departamento de Tecnología

Etiqueta: daily scrum

Scrum, Kanban y la matriz de Eisenhower

Érase una vez un Scrum Master que controlaba el proceso Scrumban que un equipo seguía. ¿Le pitan a alguien los oídos?. Dicho de otro modo, para que no se diga que aquí sólo escribimos para los “talibanes agilistas” ;P.

Erase una vez un gestor de un equipo encargado de llevar a cabo tareas planificadas y no planificadas en un periodo de tiempo determinado y cíclico. No sé cual de las dos introducciones es peor.

Érase, también, una vez un Product Owner malvado que no hacía más que meter Kanban en el sprint, haciendo sufrir al Scrum Master y poniendo a prueba la velocidad del equipo. El Scrum Master le insistía al equipo para que no dejara abandonadas las tareas de Scrum, mantuviera una velocidad de Scrum aceptable y consiguiera los objetivos del sprint. Y en estas llegó la retrospectiva y el equipo le afeó al Scrum Master que priorizara el Scrum frente al Kanban, ya que todos son hijos de Dios (del Product Owner en este caso). Así que el Scrum Master se puso a pensar y sacó las siguientes moralejas además de escribir este post.

  • El equipo tiene razón, en teoría, el Kanban es tan válido como el Scrum. La suma de todo nos da la velocidad total del equipo y si los puntos totales al final del sprint son iguales o mayores que los planificados el equipo habrá cumplido con su papel.
  • El Scrum Master también tiene razón, en la práctica, el Product Owner siempre, salvo cambios grandes de requerimientos, espera que todo el Scrum esté acabado en la fecha final de sprint. Si el Scrum se termina, el Scrum Master habrá cumplido con su papel.
  • El hecho de no tener definidos claramente las prioridades del Kanban (FIRE, PRIO, ASAP) puede fomentar estos problemas. El Kanban en Frogtek entra directamente en la pila de producto del sprint y se empieza antes o después en función de lo arriba que entre en la columna. Es decir, es priorizado junto con lo demás (hasta ahí bien), pero luego cuando entra y navega por las diferentes fases no tiene ni más, ni menos prioridad que el resto de lo que está en desarrollo. De ahí que el Scrum Master en algún caso acabe defendiendo lo planificado y el programador quiera que todo se valore por igual, ambos defendiendo su trabajo. Pero ¿debe hacerse?.

Aquí es cuando entra en juego la relación entre las tareas de Scrum, Kanban y la matriz de Eisenhower. Eisenhower se ve que era un tío muy organizado y las malas lenguas dicen que inventó el típico plano cartesiano con cuatro cuadrantes, con un eje señalando la importancia y otro la urgencia. Así tras analizar una tarea en un momento dado podía decidir qué hacer con ella:

  • Urgente e importante. Consejo de Eisenhower: ¡Hazla ya!. Consejo ágil: Normalmente esto es Scrum (en el peor de los casos esto entrará como Kanban de alta prioridad a mitad de sprint pero en ese caso es bastante fácil poner al Scrum Master y al equipo de acuerdo en lo importante que es sacarla la tarea cuanto antes adelante).
  • No urgente pero importante. Consejo de Eisenhower: Planifícala. Consejo ágil: Vuelve a analizarla en la siguiente ronda de planificación y métela como Scrum en el siguiente sprint cuando ya sea urgente e importante.
  • Urgente pero no importante. Consejo de Eisenhower: Delega. Consejo ágil: Normalmente esto es Kanban, ya que su urgencia suele salir a relucir a mitad de sprint y nunca tendrá la importancia suficiente para entrar como Scrum. Este tipo de tareas son las que crean conflicto a veces y las que acaban retrasando los sprints.
  • Ni urgente, ni importante. Consejo de Eisenhower: ¡A la basura!. Consejo ágil: si ves muchas de estas en tu tabla, cambia de Product Owner.

Simplificando un poco se podría asimilar Importante con Scrum y Urgente con Kanban. Es por eso que como Scrum Master creo que Scrum casi siempre debe ir por delante que Kanban. Siendo flexibles, claro. 🙂

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

Curso de SCRUM en Walqa

Los próximos días 3 y 4 de noviembre se va a realizar un taller de introducción al SCRUM y algo de Kanban en Walqa. Será impartido por Teresa Oliver de Pragmatic, serán dos sesiones de 7 horas cada una y tiene un precio muy competitivo: 150€  más IVA por persona.

Animo a todos los que nos siguen a apuntarse, nosotros mandaremos a dos ingenieros que seguro que aprenderán cosas interesantes y también podrán enriquecer el debate con nuestra experiencia.

Para inscribirse, poneos en contacto con Beatriz Lorente de Walqa en blorente (at) ptwalqa (.) com antes del miércoles día 20 a las 14:00.

Waterfall vs SCRUM vs Kanban (III)

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

Waterfall vs SCRUM vs Kanban (II)

[Leer Waterfall vs SCRUM vs Kanban (I)]

Fue así como descubrimos SCRUM, una metodología ágil que implementa de una u otra manera los 4 principios fundamentales del Agile Manifesto, a saber:

  1. Que aunque los procesos y las herramientas son importantes, lo son más los individuos y sus interacciones.
  2. Que aunque la documentación exhaustiva está muy bien, es mucho mejor tener prototipos que funcionan.
  3. Que aunque negociar un contrato con el cliente es vital, es mejor aún que el cliente se involucre contigo en el proyecto.
  4. Y que aunque saber seguir un plan es una estupenda habilidad, más importante es saber cambiar dicho plan a tiempo.

SCRUM define distintos roles para las distintas personas que participan en un proyecto, no voy a entrar en detalles ya que existe multitud de literatura al respecto. Simplemente saber que existe el rol de Product Owner (en adelante PO) que es la persona que, en estrecho contacto con el cliente, define las pequeñas piezas de funcionalidad que se le van añadiendo poco a poco al producto. También se define el rol del Team (equipo de desarrolladores) que son los programadores de la cosa y el del SCRUM Master, que viene a ser el encargado de que todo el proceso que define SCRUM, el ritual periódico por el que hay que pasar inexorablemente, se lleve a la práctica como Dios manda. ¿Ritual?, ¿qué ritual?. Pues principalmente uno muy sencillo, el que sigue:

  • Como nos resulta imposible saber con antelación qué es lo que quiere el cliente dividimos el tiempo en pequeños periodos (Sprints, típicamente de entre 2 y 4 semanas) sobre los que creemos tener suficiente visibilidad. Es decir, “no tengo ni idea de cómo va a evolucionar mi producto dentro de 6 meses pero sí creo saber que mi cliente quiere ver tales características funcionando dentro de 2 semanas”… Esto tiene que ver con los puntos 3 y 4 del Manifiesto Ágil (involucrar al cliente y gestionar el cambio).
  • El PO, por lo tanto, estudia con el cliente la funcionalidad que les gustaría tener disponible en la próxima versión de la aplicación. Y luego participa en la reunión de planificación de principio de Sprint en la que, junto con el Equipo de Desarrollo, se clarifica qué hay que hacer y se decide quién hará qué y cuánto tiempo costará. Punto 1, sobre las personas y las interacciones.
  • Durante todo el Sprint el Equipo de Desarrollo lleva a cabo reuniones diarias para intercambiar información. De nuevo reforzando el punto 1 del Manifiesto.
  • Cuando se acaba el Sprint se hace una reunión de Revisión y Demo en la que el PO muestra al cliente, o los desarrolladores al PO (depende) la nueva versión del producto con las mejoras de las últimas dos semanas ya listas. Punto 2, mejor un prototipo que un infumable tocho de documentación obsoleta.
  • El ritual termina con la reunión de Retrospectiva, donde el Equipo de Desarrollo junto con SCRUM Master y POs revisan el proceso y proponen mejoras para el siguiente Sprint.

Y vuelta a empezar. Hay normas extras, peculiaridades, cosas divertidas y complicaciones sobre las que se podría profundizar mucho, pero básicamente esto es SCRUM.

En nuestro caso la cosa empezó bastante “de andar por casa”. El PO era PO y SCRUM Master a la vez, los programadores no hacían Stand-ups… Cowboy-SCRUM como bien dice Pablo. Pero bueno, la intención es lo que cuenta, durante un tiempo al menos.

Con la nueva oficina la cosa mejoró, al menos el equipo técnico ya se veía las caras. Stand-ups, Sprint Plannings, Sprint Reviews, Sprint Retrospectives… toda una plétora de reuniones salpicaba nuestro calendario. Mucha diversión mientras a la vez tratábamos de montar un entorno de desarrollo decente con pre-producción, producción, repositorios de código, branches… la juerga padre vamos. El típico momento en el que a los novatos emprendedores les empiezan a crecer los enanos y se dan cuenta de que ser profesional es difícil, muy difícil y complejo, muy complejo.

Lo que veis más arriba era nuestro día a día por aquellos tiempos. Habíamos conseguido ya tener un proceso automático que compilaba todos los días a las 15:00 CET (a primera hora de la mañana de nuestros POs en USA y Colombia) una versión de preproducción. Al final del Sprint sacábamos dos versiones de producción, una el viernes después del Review del jueves y otra el domingo con las US (User Stories, pequeños fragmentos de funcionalidad) que nuestro programador exiliado en Santiago de Compostela hacía los fines de semana. Resultado: habíamos dado nuestro primer paso hacia un concepto que desconocíamos, la Integración Continua… y nos salían bugs por todos lados. Fue por eso que empezamos también a interesarnos por cosas como el TDD y las pruebas unitarias automáticas y nos empezáramos a preocupar de que la frase “pues en mi emulador funciona” se oyera cada vez menos.

En lo que respecta a SCRUM dimos un paso de adelante contratando el servicio AgileBuddy una página web que te permite gestionar distintos proyectos con sus respectivos Backlogs (el conjunto de funcionalidades a programar), los Sprint Backlogs (cosas a programar durante el Sprint), etc, etc. Se trata de una útil herramienta para gestionar tus proyectos usando esta metodología. Lo mejor, que te dota de un marco de trabajo donde tienes todo mucho más controlado y que te calcula automáticamente las métricas de tus proyectos (Burndown chart y demás). Lo peor, que a veces no es fácil entender la forma que tienen estas herramientas de calcular sus métricas y también que quizá entraba en demasiado detalle y era necesario desglosar tareas, imputar horas de forma no siempre tan fácil o intuitiva como nos gustaría.

No fue AgileBuddy, no obstante, la razón por la apenas 4 meses después decidimos cambiar al Kanban. ¿Cambiamos por las razones adecuadas?, ¿fue un cambio precipitado?, ¿estábamos haciendo suficientemente bien SCRUM?… Todo eso y mucho más, en el próximo capítulo.

Iterando el Daily Scrum

Dentro de los cánones de Scrum, una de las reuniones ineludibles que intentamos mantener en Frogtek es el Daily Scrum (también llamado Standup meeting o Daily Standup). Aquí van algunas de las características de esta reunión:

  • Standup: debe realizarse de pie. El motivo de esto es no alargar la reunión demasiado (no debería durar más de 15 minutos).
  • Daily: debe realizarse cada día, preferiblemente a la misma hora y en el mismo lugar.
  • En él, cada miembro del equipo debe responder a tres preguntas:
    • ¿Qué hice ayer?
    • ¿Qué voy a hacer hoy?
    • ¿Qué problemas he encontrado?
  • Asisten todos los cerdos. Las gallinas son bienvenidas, pero sólo para escuchar. Si no entiendes de qué va esto, lee el siguiente artículo.

El objetivo de esta reunión es que todos los integrantes del equipo tengan una idea de en qué esta trabajando cada uno del resto de integrantes, al mismo tiempo que permite ir conociendo lo que se ha ido conseguiendo cada día. En nuestro caso, esta reunión la realizamos a primera hora de la mañana, para que cada uno pueda planificar en consecuencia lo que va a realizar durante el día.

Pero no quisimos quedarnos ahí. Con el objetivo de seguir mejorando el proceso, en la empresa hemos ido iterando sobre el concepto de Daily Scrum, de forma que hemos añadido varios cambios al respecto:

  • Compartir las estimaciones: durante la reunión, debemos compartir con el resto del equipo las estimaciones que hemos dado a nuestras User Stories. Kanban no prescribe la estimación de las tareas, pero dentro de Frogtek creímos conveniente el hacernos unos maestros de la estimación, con el fin de organizar nuestras tareas de manera más eficiente. El compartirlas nos permite que puedan ser puestas en común (muy al estilo de Scrum con las conocidas cartas).
  • Daily Scrum en inglés: llevábamos un tiempo pensando cómo podíamos fomentar el uso del inglés en la empresa, cuando dimos con la solución: durante el daily scrum sólo se puede hablar en inglés. Con esta medida, conseguimos también que el daily scrum no se alargara ni entrara en divagaciones eternas. Curiosamente, también se redujeron los improperios y palabras malsonantes (true story).
  • Añadir una cuarta pregunta. Además de las clásicas “qué hice ayer” , “qué haré hoy” y “qué problemas he encontrado”, creímos conveniente añadir “cómo voy a intentar arreglar el problema”. Esto nos da una perspectiva de cúal va a ser el mejor acercamiento para solucionar un escollo. Y no nos olvidemos tampoco de compartir con el resto del equipo el “cómo conseguí arreglar el problema”. Los errores se repiten y lo que funcionó en el pasado a alguien es bastante probable que me funcione a mí o me ponga en la pista de la solución.

Seguro que seguimos pensando cómo poder mejorar nuestro daily scrum. Pero eso lo veremos en la siguiente iteración…