Developing Frogtek

El blog del Departamento de Tecnología

Etiqueta: cas2010

¿Para qué sirve ser ágil en una start-up?

Mucho agile, mucho agile… pero si te descuidas puedes acabar en una empresa en la que lo único agile es el motor y para de contar, más cuando el equipo de producción, como en nuestro caso, está aislado del resto o directamente, como pasa en las consultoras, no hay resto. Ésta es un poco la conclusión que he obtenido tras leer los libros “Lean Start-up Method” de Eric Ries, “The four steps to the epiphany” de Steve Blank y después de conocer un poco el mundillo éste del agilismo en España… y por experiencia propia, por qué no decirlo.

Supongo que en parte es porque el mundo del software ibérico está principalmente orientado a programar para terceros y en ese caso ser ágil es “tan fácil” (y tan difícil) como pegarte unos años hasta que haces scrum, tdd y demás como Dios manda y conseguir que el cliente acuda a las reuniones y se involucre en el proceso de cada sprint. Pero la realidad es que detrás de los métodos ágiles hay mucho más y es algo de lo que no se oye hablar demasiado. Hace mucho que no acudo a ninguna AOS, ni CAS (siempre me coinciden con algo que no puedo dejar para otro momento), pero la primera CAS a la que acudí (2010) me encantó, sabíamos tan poco de métodos ágiles que cada charla era un nuevo mundo de conocimientos y posibilidades. Desde entonces si no yo, siempre alguien de Frogtek ha acudido a estos eventos y trasladado lo que allí ha aprendido. Últimamente, sin embargo, me empezó a sorprender que si bien toda la comunidad está muy interesada en ser técnicamente ágiles, no parece haber tanta ebullición, o al menos yo no la he detectado, una capa por encima de eso. Está bien tener un método de producción iterativo-incremental, está bien ofrecer al cliente (que muchas veces no es el usuario final, desgraciadamente) un proceso súper adaptable a sus cambios de humor y requisitos… pero estaría mejor dotarnos de los procesos, que tiene que haberlos, para utilizar este gran método para crear el producto que el usuario final necesita. Para ello no basta con que el equipo de desarrollo sea ágil, hay que aprovechar esa agilidad para que los equipos de marketing y ventas (o el product owner, o los encargados de desarrollo de cliente, o quien sea) puedan, a su vez, realizar sus propios experimentos, implementar sus propias métricas y tener sus propios objetivos iterativos e incrementales que nada tengan que ver con el desarrollo y sí con el negocio. Por eso, echo de menos, conceptos que Ries maneja en su libro como “indicadores vanidosos”, “indicadores accionables”, “análisis de cohortes”, “contabilidad de la innovación“… conceptos sin los que scrum, tdd, los sprints y todo lo demás no sirven más que para tener un proceso de desarrollo flexible y adaptable… lo cual no tiene porqué evitar que se acabe construyendo de forma eficiente y completamente flexiblemente un producto totalmente inútil. Supongo que, en España, el principal problema es precisamente que no existen muchas start-ups y hay, sin embargo, demasiadas factorías de software… y en una factoría de software es difícil vislumbrar nada más allá de lo técnico (por no hablar ya de meter baza) y suficiente se tiene con lidiar con el cliente.

Frogtek no es una software factory pero también hemos sufrido en parte ese problema. Tras varios años de trabajo teníamos un equipo de tecnología muy “agile” y muy “kaizen” que implementaba las “ocurrencias” de la empresa de manera eficiente y puntual. Ocurrencias, dicho en el mejor de los sentidos y con todo el cariño, que trataban de ser lo más meditadas posible y que suponíamos beneficiosas para los tenderos y que, lo fueran o no permanecían en el producto sine die. El problema de esta aproximación es que no es todo lo científica que debería ya se basa en asunciones que habría que comprobar, pero que rara vez se comprueban, por falta de tiempo y de proceso principalmente. No basta con implementar User Stories por muy bien definidas que estén, el cementerio está lleno de productos técnicamente impecables. Para solucionar esto en Frogtek vamos a utilizar una capa más de abstracción, basada en Épicas, que iría sobre los sprints de User Stories. Una Épica no es más que un objetivo del product owner para un sprint determinado. Algo así como el objetivo estratégico de alto nivel de mejorar el indicador X de la empresa en un x% (p.e. “hay que conseguir que el 80% de los tenderos levanten su inventario en menos de 2 horas”). Muchas veces, este tipo de mejoras no es cuestión de una sola User Story es, más bien y por limitarlo al producto, un conjunto de historias (“el producto debe adivinar los precios”, “el producto debe adivinar los costes”, “el producto debe proponer los productos más comunes”, “el interfaz debe cambiar así o asá”…) que se pueden desarrollar durante un sprint (de forma ágil, claro), la diferencia con nuestra aproximación pasada es que terminado el sprint el trabajo del product owner no ha hecho más que empezar y a la vez que se empieza a pensar en el sprint siguiente, tiene que echarle un ojo al indicador asociado a la Épica del sprint pasado con el objeto de aprender si los cambios en el producto están teniendo el efecto deseado en el comportamiento real de los usuarios o, por el contrario, no han servido para nada y se necesitan más cambios (volver a iterar).

 

El trabajo del product owner se complica, ya que como se ve en el dibujo el contenido del sprint N empieza a analizar incluso antes de que empiece el sprint N-1.  La secuencia es la siguiente:

  1. Recoger indicadores.
  2. Analizar indicadores y Épicas en evaluación para decidir los objetivos (creando nuevas o modificando Épicas).
  3. Desglosar las Épicas en historias de usuario.
  4. Preparar la historias de usuario (mock-ups, pruebas de usabilidad con clientes, más mock-ups…).
  5. Estimar historias de usuario.
  6. Ejecutar el sprint (incluyendo pruebas, instalación en friendly users, etc).
  7. Instalar nueva versión en usuarios.
  8. Vuelta a 1.

Normalmente los indicadores a recoger y analizar necesitan un tiempo hasta que se generan, al menos en nuestro caso, así que no será extraño que las Épicas que se evalúen en un momento dado se hayan implementado hace dos, tres o más sprints. Por lo tanto el PO, no sólo tiene que estar pendiente del sprint actual sino que tiene que pensar en las Épicas (objetivos estratégicos del producto) que querrá definir para el sprint siguiente, mientras que monitoriza meticulosamente los indicadores asociados a las Épicas que están ahora mismo en evaluación y que pueden seguir así por uno o varios sprints. Porque una Épica, como una User Story, tiene un ciclo de vida ¡e incluso su propia tabla! (se proponen, se discuten, se diseñan, se implementan, se evalúan y si están bien se archivan, muy propio para una tabla de kanban) pero a diferencia de una User Story la evaluación no depende de factores meramente técnicos, si no que es función del valor que aporte al usuario final (si está bien definida y si se monitoriza usando datos reales). El paralelismo con las User Stories también tiene otras ventajas, se puede medir el throughput en Épicas de un equipo, es decir, la velocidad de la empresa para poner hipótesis a prueba y aprender de la realidad, concepto directamente relacionado con las posibilidades de la empresa de sobrevivir.

Al final como en muchos aspectos de la vida, se pueden extraer unas cuantas enseñanzas muy interesantes: No llega más lejos la empresa que hace más User Stories, sino la que hace User Stories como consecuencia del aprendizaje validado de otras User Stories. Es importante tener un framework de gestión del trabajo ágil, pero más importante es integrar en el proceso de producción herramientas de medida como Google Analytics o Flurry que permitan obtener información sobre la utilización de las distintas funciones y que permitan discriminar entre distintos grupos de usuarios con distintas versiones para poder relacionar causas y efectos usando el análisis de cohortes (¿a los usuarios de la versión x+1 les ha ido mejor que los de la version x?). Así que ahí estamos en Frogtek, peleándonos, como buenos novatos, con Analytics y con nuestras propias métricas, discutiendo las métricas que debemos aplicar a las Épicas y tratando de encajar su ciclo de vida con el de definición e implementación de los sprints. Este post, más que una realidad, es una declaración de intenciones acerca de lo que queremos hacer para conseguir ser una “agile data-driven company” para lo cual es necesario ser ágil pero, visto lo visto, no suficiente.

Aforismos ágiles

“Los product manager sois una especie en extinción. Reciclaos. La naturaleza no da avisos a las especies que se van a extinguir, así que dadme las gracias”

Ángel Medinilla – CAS2010

¡Hola Mundo!

¿Quién nos iba a decir cuando hace menos de un año nos apuntamos a esta aventura que es Frogtek la cantidad de cosas interesantes que íbamos a aprender en tan poco tiempo?. Nadie fue capaz de prevenirnos sobre cuánto iba a cambiar nuestra forma de trabajar y lo enriquecedor que iba a ser el principio del camino a recorrer (porque esto no ha hecho más que empezar). Era toda una apuesta. Salir, en alguno de los casos, de debajo del ala de grandes empresas tan rígidas, como cómodas para montar una empresa pequeña entre todos, desde cero, sin corsés, sin ideas predefinidas… y sin red. Y en ello estamos.

En menos de un año y liderados por un CEO, David, de energía inagotable, e inversamente proporcional a su aversión al cambio (que es nula), hemos construido un grandísimo equipo técnico, flexible, motivado, con ganas de aprender y de enseñar. Se comenzó trabajando los fines de semana, dando forma a un prototipo cuya especificación estaba siempre obsoleta (waterfall,  :$  sí, todo el mundo tiene un pasado oscuro que esconder). Seguimos con un rudimentario SCRUM mucho más apropiado para lidiar con un producto final que desconocíamos a priori (las start-ups ya se sabe… siempre buscando) y unos clientes, los pequeños comerciantes en países emergentes (¡ahí es nada!) tan remotos, como desconocidos. Por aquel entonces, verano del 2009, llegó el momento de la decisión, de tirarse a la piscina, mudarse a una oficina y dedicarse al 100% a Frogtek. La oficina y una empresa de verdad trajo también un SCRUM más “de verdad”, herramientas como el AgileBuddy y nuevos compañeros de viaje. Más adelante nuestra escasa fortuna estimando, reuniones de planificación interminables y la naturaleza demasiado informal de nuestros clientes finales (no es posible tener al tendero medio latinoamericano una vez cada dos semanas en el sprint review) hizo que nos pasáramos al ScrumBan y decoráramos nuestra ya de por sí bonita oficina con una más preciosa aún tabla de Kanban y post-its de todos los colores que hacen las delicias de nuestro programador daltónico, responsable a su vez de nuestros primeros pinitos con el TDD (¡gracias a Carlos Blé!). Buscamos entonces un Tester y encontramos un Responsable de QA y él (junto con el resto) nos ha dado Integración Continua, Test Automáticos, métricas…

En marzo de 2010 empezábamos a tener un departamento de Tecnología en condiciones con un proceso cogido con alfileres pero que apuntaba maneras. Y llegó el momento de conocernos con el resto de la empresa. Aparte de nosotros, había una persona en Nueva York, dos en Bogotá y otra en México DF… y daba la casualidad de que aunque hablábamos diariamente vía skype, ninguno los doce había visto en persona al resto de los “Frogtekeros”. Nos juntamos todos en Huesca la última semana de marzo y durante esos días pasó algo curioso. Les pedimos a los desarrolladores que hicieran una presentación para mostrar cómo era su día a día y en lugar de Power Point van y nos salen con esto…

… supongo que es el tipo de cosas que hace un equipo cuando tiene libertad y está motivado. El vídeo fue un éxito de crítica y público y un poco la semilla para crear este blog. Semilla que germinó en idea tras la sobredosis de entusiasmo y agilismo (menudo palabro) que tres de nosotros tuvimos la suerte de recibir en la CAS 2010. Escuchar a los gurús de las metodologías ágiles y conocer las historias de éxito y de fracaso de distintas empresas nos hizo pensar que también nosotros teníamos algo que contar: nuestra humilde historia, las pequeñas grandes cosas que hemos aprendido y las incontables que nos quedan por aprender.

Este blog surge como nuestro primer “FrogtekLabs”, en él vamos a hablar de nuestro trabajo, de nuestra evolución, de nuestros cambios en definitiva, porque no hacemos más que cambiar. De métodos ágiles, de palabros en japonés, de Android, de Google App Engine, de cualquier cosa que nos interese… Somos ocho, así que no esperes consistencia, espera estilos muy distintos, distintas frecuencias, posts de gestión, de programación pura y dura, de TDD, sobre cómo usar SONAR o configurar Eclipse. Ni siquiera esperes que no nos llevemos la contraria alguna vez. Espera también errores y ayúdanos a corregirlos.

Nos declaramos fans de Ángel Medinilla (¡tenemos su autógrafo!) y de Rodrigo Corral. Somos maqueros y linuxeros y alguno hay que aún echa de menos Windows. No estamos en Silicon Valley, sino entre Huesca y Zaragoza, pero no renunciamos a trabajar como Google. Y por encima de todas las cosas… queremos pasarlo bien. ¡Que empiece la fiesta!.