Developing Frogtek

El blog del Departamento de Tecnología

Etiqueta: frogtek (página 1 de 4)

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

Frogtek se alía con Kiva para financiar TiendaTeks

Hoy no vamos a hablar de tecnología, ni de organización de equipos. Vamos a hablar de algo bastante distinto.

Como todos sabéis Frogtek trata de llevar la última tecnología a las pequeñas tiendas de países emergentes y del tercer mundo. Pues bien, una de las preguntas que más nos hacen es la siguiente ¿cómo paga un tendero de México o de Ghana una tableta Android de última generación?. La respuesta no es fácil.

Para empezar, tratando de que la última tecnología sea lo más asequible posible.  Para ello en el departamento de tecnología nos hemos esforzado y nos seguimos esforzando en buscar tecnología de bajo coste que pueda funcionar con nuestro software. A menudo eso supone rastrear el mercado asiático en busca de la última tableta que tiene todo lo que necesitamos (que no es poco) a un precio razonable, lo mismo con impresoras, lector de códigos de barras y lectores de tarjeta magnética. Afortunadamente esto, que al principio era infernal (teléfonos que se ponen en chino al quedarse sin batería y otras lindezas por el estilo) es ahora algo más sencillo. Otras veces se trata de exprimir al máximo las posibilidades técnicas del hardware que nos llega, descendiendo al nivel del sistema operativo para poder crear nuestros propios drivers USB y deshacernos de los periféricos basados en bluetooth que eran mucho más caros.

Pero sólo con hardware barato y bien utilizado no es suficiente. Hemos tenido que explorar otras opciones más del mundo financiero. ¿Cómo podemos hacer para que el tendero pueda permitirse adquirir TiendaTek?. Resulta obvio pensar en ofrecer al cliente una vía de financiación, la posibilidad de pagarlo a plazos pero ¿quien financia todo eso?. Frogtek no tiene dinero suficiente para adelantar el coste de cientos o miles de tabletas, impresoras, lectores para luego esperar pacientemente a que los tenderos plazo a plazo vaya pagando. Existen otras opciones, muchas de ellas las hemos explorado o las estamos explorando: conseguir que una gran empresa interesada financie a nuestros tenderos, conseguir que un fondo de impacto compre las tabletas por nosotros y nos las preste para venderlas que ya le devolveremos el dinero conforme lo vayamos recuperando, colaborar con una microfinanciera que ofrezca sus créditos en la base de la pirámide para que los tenderos puedan invertir en una herramienta de productividad como la nuestra.

Todo esto y mucho más son los quebraderos de cabeza que parte de nuestro equipo tiene para conseguir que esta aventura de Frogtek sea, no sólo sostenible y viable, sino también escalable. Hoy estamos muy contentos de anunciar que una de las opciones en las que hemos trabajado ha visto la luz, de una forma muy bonita, porque hemos llegado a un acuerdo con una “micro-financiera” pero no cualquier micro-financiera, hemos llegado a un acuerdo con Kiva. A partir de ahora tenderos que quieran adquirir TiendaTek para su negocio en México se empezarán a anunciar en Kiva para obtener el dinero necesario y lo precioso del caso es que serán otras personas a miles de kilómetros las que  prestarán ese dinero directamente. Porque Kiva es una de las principales plataformas de crowd-funding, o lo que es lo mismo, sirve para que cualquier persona preste unos pocos euros a gente que lo necesita para financiar sus humildes proyectos, para que muchos pocos hagan un gran mucho. La tecnología consigue lo que hasta hace bien poco era totalmente inviable, que tú y que yo con 25€ podamos ayudar directamente a una persona a miles de km a conseguir un préstamo para invertir en algo que mejore su vida.

Lo curioso del caso, además, es que el equipo de Huesca lleva ya muchos meses invirtiendo el dinero del bote del cerdito en emprendedores anónimos de Kiva. Ahora tendremos la oportunidad de cerrar el círculo, invirtiendo lo que obtenemos de nuestras pifias en los tenderos para los que trabajamos.

Así que tenemos el placer de anunciar que nuestra primera cliente en Kiva es Ana Karen y ójala sea la primera de muchas.

Avances en burn-down charts: la “burn-up-down” chart

Hacemos Scrumban y eso nos ha obligado a hacer alguna que otra cosa curiosa. Una de ellas consistía en tener dos gráficas el burn-down para nuestras historias de Scrum (las planificadas) y el burn-up para nuestras historias de Kanban (las no planificadas). Básicamente se trataba de poner un objetivo de historias planificadas y una especie de tope a las historias no planificadas… planificar el trabajo que te va a llegar de forma no planificada tiene algo de absurdo, pero se puede hacer. No hay que medir el pasado y esperar que el futuro se comporte. Tener dos gráficas resulta un poco incómodo, aunque no es un gran problema. Reservar ya desde el principio una parte de tu ancho de banda a Kanban denota que tenemos unos POs un poco “volubles”. Tampoco pasa nada.

En cualquier caso en la última vuelta de tuerca a nuestro sistema hemos decidido superponer ambas gráficas para así poder saber de un vistazo cómo va el Sprint independientemente de haya habido mucho o poco Kanban. Aquí os pongo un ejemplo de nuestra “burn-up-down chart”:

En este caso la línea azul señala el ritmo ideal de completado de US de Scrum del Sprint. En rojo vemos la realidad, como la parte de Scrum lleva un pequeño retraso; en amarillo el Kanban real, las historias no planificadas que se han ido terminando. De esta gráfica podemos obtener la siguiente conclusión, la primera semana a pesar de que se acumuló retraso entre las historias planificadas el equipo de desarrollo cumplió con su objetivo (ya que lo que faltó de Scrum se hizo de Kanban), la segunda semana la cosa fue peor.

Al final la manera de leer esta gráfica es sencilla.

  • Si las gráficas amarilla y roja se cortan antes de terminar el Sprint el equipo de desarrollo ha cumplido su objetivo.
  • Cuanto más suba la línea amarilla peor planificación se hizo.

Resumen del Global Day of Code Retreat en Aragón

El resumen es sencillo: lo pasamos muy bien.

Es toda una satisfacción ver como la gente responde ante eventos de estas características, y se puede juntar a 3o personas con ganas de aprender un sábado entero. Sebastián fue el maestro de ceremonias perfecto, proponiendo distintos retos cada vez más complejos e imaginativos. Creo que el que más gustó fue lo de hacer ping-pong programming en silencio.

También fue divertido contar con las dos programadoras más jóvenes de todas las localizaciones de este Global Day of Code Retreat y ver cómo alternan los pomodoros con el juego de la goma.

Os dejo un par de fotos del evento.

Hasta la próxima!

Art-attack en Frogtek

Un rato, unos cuantos cientos de post-its, mucha ilusión y algo de frikismo.

El resultado:

Global Day of Code Retreat en Aragón

Tenemos el placer de anunciar que, junto con Teresa Oliver (más conocida en twitter como @tolivern) y el Parque Tecnológico Walqa, Frogtek va a organizar el Global Day of Code Retreat en Aragón.

¿Qué es el Global Day of Code Retreat?. Corey Haines lo explica mucho mejor que yo, pero en pocas palabras se podría decir que es un día para celebrar la pasión por el software y por el craftmanship, palabro que se refiere a la calidad personal que un artesano pone en su trabajo y que muchos programadores se esfuerzan por poner en el suyo.

¿Cómo lo vamos a celebrar?. Con una especie de gran Coding Dojo de un día entero de duración que llevaremos a cabo simultáneamente con decenas de ciudades en otras partes del mundo. En Aragón, los programadores que estén por la zona y quieran pasar un día de práctica intensiva de diseño y programación están invitados a unirse a nosotros en el edificio de servicios generales (el de la cafetería) del Parque Tecnológico Walqa en Huesca. Será el próximo 3 de Diciembre y contaremos con un facilitador de lujo, Sebastián Hermida. Sebastian posee el acento raro de los vídeos de http://holatdd.com. Le gusta el fresco aroma del verde de los tests y la programacion por pares. Intenta hacer que escribir tests sea divertido con http://happyprog.com. Quiere que te lo pases en grande hablando y programando en ingles con http://elkataingles.comDespués de 10 años fuera del pais, vuelve a disfrutar de España empezando una nueva aventura con http://path11.com, de la que es co-fundador junto con, entre otras personas, otro de los grandes, Enrique Comba. No te lo pierdas y ven a conocer gente interesante a Walqa.

Algunos temas logísticos:

  • Horario: de 10:00 a 18:00
  • Lugar: Edificio de Servicios Generales del Parque Tecnológico Walqa
  • Precio: Gratuito
  • Inscripciones: mandando un correo con título “Inscripción Code Retreat” y con tu nombre a walqa@ptwalqa.com
  • Número de plazas: mínimo 12, máximo 30
  • Comida: Walqa nos pone café y galletas a discrección, para la comida hemos negociado un menú de 9€ en la cafetería
  • Trae tu propio ordenador!

Un saludo y os esperamos a todos en Walqa. ¡Con todo esto y otras sorpresas!.

Actualización: además de la inscripción oficial vía mail puedes unirte al evento en la web de Code Retreat donde puedes ver parte de la gente que va a acudir y mandar comentarios y propuestas.

Tabla de kanban para las retrospectivas

Al principio nuestras reuniones de retrospectiva eran de lo más… cómo decirlo sin ofender a nadie… anárquico. Tanto en contenido como en periodicidad, es decir, las hacíamos cuando queríamos y como queríamos. Podían pasar meses entre una y otra, y cuando por fin hacíamos una nos dábamos cuenta de lo útiles que eran y la cantidad de cosas interesantes que surgían. Las ha habido incluso que han supuesto un punto de inflexión en nuestra manera de trabajar, como aquella que hicimos con la excusa de que algunos habían acudido a un evento llamado AOS en una ciudad llamada Barcelona.

Con el tiempo, y conforme te haces con todos los procesos y ellos dejan de dominarte a ti, hemos sido siendo más constantes y periódicos con estas reuniones. Incluso nos compramos un libro, Agile Retrospectives (del cual he de reconocer que sólo he leído los primeros capítulos) e investigamos por internet sobre la mejor manera de hacerlas. Hay infinidad de técnicas que se pueden aplicar. Nosotros optamos por una de lo más sencillo. Básicamente cada miembro del equipo escribe en uno o varios post-its las cosas que han ido bien y las cosas que han ido mal en el último mes. Se ponen en común y se agrupan por temas, de forma que podemos identificar cuales son las principales virtudes que debemos fortalecer y cuales los principales problemas que hay que paliar. Sigue una discusión sobre estos temas de la cual obtenemos una lista de puntos de acción que se revisan de retrospectiva en retrospectiva. Además de puntos de acción también salen sugerencias y recomendaciones (o lo que podríamos llamar puntos de acción “vagos“… del estilo de “sed todos buenos“). Estas recomendaciones son un problema porque no es fácil hacer un seguimiento de su cumplimiento ya que no son objetivos SMART. En la última parte de la reunión debatimos también sobre las ideas que cualquiera haya incluido en la excel que tenemos para “ideas a discutir durante la retrospectiva”.

Llevamos ya varios meses siendo muy regulares con este tema y ahora hemos decidido dar un paso más y crear una tabla de kanban para ilustrar el proceso. Nos gustan los post-its y ayudan a decorar la oficina… qué se le va a hacer!!.

En la foto podéis ver cómo en verde y rojo apuntamos las cosas buenas y las malas, para que a nadie se le olviden. Más importante aún son los puntos de acción cuyo seguimiento realizamos con una tabla que no puede ser más simple. Adicionalmente tenemos nuestro apartado de sugerencias del mes… a ver si teniéndolas en la sala de reuniones a la vista, las tenemos más presentes. Si esto no funciona optaremos por recitarlas todas la mañanas en plan mantra antes del stand-up. Algo del estilo de:

  • Ser QA no me da derecho a hacer cowboy committing
  • Me flagelaré de forma inmisericorde si el stand-up dura más de 25 minutos

Muchas veces hemos oído que la reunión de retrospectiva es la más importante de todas las reuniones que conforman el espíritu ágil. Encarna la esencia del Kaizen y da la oportunidad de debatir, aportar y enriquecerse (espiritualmente, claro). He de reconocer que, personalmente, veo como muchas de estas reuniones suponen un soplo de aire fresco en Frogtek. Y veo, no sin orgullo, como nuestro equipo se autogestiona y mejora de forma imparable, día tras día y mes tras mes. Supongo que son los pequeños placeres del Scrum Master que no programa, dado que no puedo hacer el baile de la victoria tras compilar por última vez la loser story de turno.

 

Desk-Surfing

La semana pasada tuvimos a @francho_lab en la oficina, no voy a entrar en detalles de lo interesante que fue su visita porque soy el menos indicado para hacerlo y porque cualquiera de los programadores lo hará mucho mejor que yo. Pero sí que me gustaría ensalzar las virtudes de este tipo de intercambios informales y de la web que se montó con ese objetivo, Desk-Surfing.Org, después de la última Agile Open Spain 2011 de Pamplona.

Para nosotros éste ha sido el cuarto intercambio/visita. Anteriormente hemos tenido el honor de tener a @carlosble, @hell03610 (Emma) y a @rubenbpv. Además Pedro estuvo tres días en Biko2 y Julio ha estado 2 en PocketWidget. Todas y cada una de las visitas han sido fuente de innumerables mejoras. El mero hecho de salir y ver un entorno diferente o recibir a una persona de otra empresa hace que te replantees la forma de trabajar, aprendas nuevas técnicas o procesos.

Son estas cosas, junto con la asistencias a eventos como las AOS o la CAS, las que nos dan los empujones necesarios para seguir mejorando continuamente. Por eso Frogtek se registro en la web Desk-Surfing.Org y por eso continuaremos acogiendo y enviando ingenieros en el futuro. ¡Os animamos a todos a probar la experiencia!.

Tres días con Biko2

Hace tres semanas  volví muy contento y con muchas cosas que contar de mis tres días por tierras pamplonicas en compañía de mis colegas de biko2. Tras unas semanas caóticas me voy a relatar lo bien que me lo pasé.

Os dejo una preciosa foto del Moncayo que hice al ir por la autovía


Llegue a sus oficinas, después de que Jon me recogiera en la estación y lo primero que hicimos fue ver al gran equipo anteriormente conocido como “Equipo de Movilidad” ;). Iván, Miguel, Susana y Patricia, peazo equipo con el que he tenido la oportunidad de trabajar estos días. Yo iba con bastante miedo y pensando en si realmente podría atender las necesidades del equipo. Tras unos correos con Jon intentando organizar un poco, pensamos que sería mejor no organizar nada y hacerlo lo más ágil posible, así fue.

Los temas que tratar fueron saliendo fácilmente sobre la marcha. Por una lado el equipo tenia sus propias inquietudes y por otro fuimos estudiando las aplicaciones que ya habían desarrollado y viendo qué posibles temas mejorar. De este modo pudimos crear una agenda que hicimos open al resto de la empresa. Así cualquier empleado podría venir a las sesiones que le resultasen más interesantes. Salieron temas como testing, eficiencia, persistencia de datos… todo ello en torno a Android.

Por otro lado, con el equipo trabajamos las notificaciones push en Android, que para mí también era novedad. No fue fácil, al final y tras algunas horas conseguimos hacerlo funcionar. 😉

Mientras tanto, yo me intentaba empapar lo máximo posible de su metodología, acudí a algún stand-up meeting y me apunte muchas ideas/mejoras que luego conté al equipo de Frogtek en nuestra retrospectiva. Grandes conversaciones con Jon, Rubén, Mario… en las que aprendí mucho y también comí muy bien.

Y por supuesto, también nuestra pizarra con las tareas.

Al final de los tres días en biko también hicimos retrospectiva con Rubén e hicimos balance de los tres días. Como resultado negativo salieron todos los cabezazos que nos dimos con las notificaciones push… lo más importante es que al final lo conseguimos.

En resumen: confío mucho en este tipo de colaboraciones y me encantó no tener una agenda definida ni tener temas a tratar de antemano. Teníamos dos misiones : Aprender lo máximo y ayudar lo máximo. Creo que cumplimos con la misión.

Desde aquí mi agradecimiento al equipo de biko2 que me recibió extraordinariamente y me trato mejor aún. Esta semana tenemos a Rubén por frogtek, vamos a trabajar para que se lleve un buen recuerdo.

Detalles para el Coding Dojo

Rubén ha publicado en su blog los detalles de la kata que haremos el próximo día 8 de abril. Se trata de la conocida String Calculator: conéctate a su página para conocer los detalles del enunciado y los consejos de Rubén para iniciarte en el TDD.

Aún tenemos huecos para el Dojo, ¡nos vemos en menos de dos semanas!.

Antiguas entradas