Developing Frogtek

El blog del Departamento de Tecnología

Categoría: metodología (página 1 de 4)

De trellos a métricas (y tiro porque me toca): nuestro Balanced Scorecard

Ya sabemos gracias al post de Miky que  en Frogtek somos adictos a Trello y a sus múltiples columnas y tarjetas. Primero porque es una manera fácil de casi “documentar” procesos complejos y con muchas fases, pero  también porque es la manera más sencilla de que todo el mundo siga la metodología, o porque da visibilidad a todo el equipo o muchas otras razones… la última, pero no por ello la menos importante, la comenta el propio Miky en su post:

Pero lo bueno viene ahora. La historia de usuario terminada, la petición la mueves a terminada también. Empieza la diversión. La US se contabiliza, se archiva en otro Trello que lleva las US asociadas a las diferentes versiones de los productos. Se envía un email para pedir feedback sobre la resolución de la incidencia. Se trasmiten los comentarios, se agregan las valoraciones. La persona que ha hecho la petición percibe que alguien, y no algo, ha hecho el trabajo. Buenas ideas. Y la mejor idea de todo este párrafo: algunas cosas están automatizadas, pero todas son transparentes al desarrollador.

La contabilización de USs es una tarea en parte manual y mecánica pero da unos frutos muy interesantes cuando empiezas a mirar en los datos. El principal es nuestro Balanced Scorecard (también llamado Cuadro de Mando Integral) que integra, entre otros muchos datos, todos los indicadores de satisfacción de peticiones y de la implementación de historias de usuario. Tiene una pinta tal que así.

bsc1

Para el que no haya visto nunca un Mapa Estratégico o un Balanced Scorecard se puede resumir más o menos en lo siguiente:

  • Un Mapa Estratégico es una como una representación de la estrategia de la compañía en un conjunto de objetivos en diferentes perspectivas (la financiera, la de clientes, la de procesos y la de equipo). Básicamente se podría reducir como las respuestas que hay que dar consecutivamente a las siguientes preguntas.
    • ¿Cuales son las expectativas financieras de la empresa? Facturar X, conseguir una inversión Y…
    • ¿Qué ofrece el negocio a los clientes (que le llevará a satisfacer las expectativas financieras)? Un producto con un gran valor o con un valor diferencial, una atención al cliente excelente…
    • ¿Qué tiene que hacer el negocio para cumplir con los clientes? Tener un desarrollo de producto ágil y eficaz, gestionar las incidencias de manera magnífica…
    • ¿Qué garantiza la ejecución óptima de los procesos? Un equipo satisfecho (ésta es un clásico), conocimientos sobre desarrollo de producto, una plataforma de atención al cliente puntera… lo que sea.
  • Y un Balanced Scorecard, según mi personal punto de vista, viene a ser exactamente lo mismo pero sustituyendo esos objetivos en cada una de las perspectivas por indicadores (KPIs).

bsc2

Normalmente un Mapa Estratégico tiene la perspectiva financiera arriba del todo, ya que ganar pasta suele ser el fin último de todas las empresas… en el caso de Mapa Estratégico del Departamento de Tecnología de Frogtek nosotros lo hemos colado abajo ya que hacer pasta no es nuestro objetivo del área… pero bueno eso en el fondo es debatible y no es tan importante para este post en particular. En la siguiente imagen podéis ver un boceto del Mapa Estratégico del nuestro departamento.

Básicamente muestra que nosotros consideramos que habremos hecho un buen trabajo si:

  1. Ayudamos proactivamente con tecnología y datos al resto de departamentos a mejorar sus KPIs y alcanzar sus objetivos.
  2. Mantenemos los sistemas siempre up & running y evolucionamos la infraestructura para asegurar la escalabilidad.
  3. Creamos productos de valor para tenderos.
  4. Resolvemos cualquier problema técnico de manera puntual y eficaz.

El resto de objetivos en procesos, equipo y finanzas tienen que servir a estos cuatro.

Y luego viene cuando pasamos del Mapa Estratégico, una slide estática en una presentación, a la parte que mola… un Balanced Scorecard colgado en la web con KPIs que se actualizan en tiempo real (o casi). La razón por la que un servidor dedica unas 2 horas al mes a contabilizar USs, peticiones, incidencias u otras cosas. No hay mucha magia tecnológica detrás de esto: Clicdata, Spreadsheets, Google Forms, Trello… le das las vueltas con Zapier, lo aderezas con una pizquita de amor… et voilà: una de indicadores para el proceso de gestión de peticiones y colaboraciones (lo que nosotros llamamos Roadmap).

bsc3

No se queda ahí la cosa. Haciendo click en cada indicador puedes entrar en un segundo nivel con la evolución mensual de la duración del ciclo de vida, el cumplimiento de expectativas (esas cosas que se piden para ayer), el número de peticiones, la satisfacción o el desglose de peticiones por cliente y/o épica. Todo ello filtrado por fecha, cliente, producto, épica…

bsc4

Y lo mismo para el segundo Trello (proceso) que mencionaba Miky en su post, el proceso de desarrollo de USs.

bsc5

Con sus pertinentes desgloses.

bsc6

Adicionalmente para cada dashboard de segundo nivel tenemos una tabla con las iniciativas de mejora relacionadas que hemos llevado a cabo en el periodo. Una buena manera de ver si las mejoras que propones tienen algún impacto en la mejora de los indicadores. Mejoras que, por cierto, también tienen su propio Trello, sus propios KPIs y sus propios indicadores. En Frogtek España todo tiene un Trello.   😉  😛 😕  … No es broma.

Y como todo en Frogtek España tiene un Trello nuestro Balanced Scorecard no sólo tiene KPIs para Roadmap y Desarrollo, también para el rendimiento de nuestro proceso de entrega de datos punta a punta, el uso de nuestro producto por parte de los tenderos, la gestión de incidencias, la gestión de despliegues de nuevas versiones, la valoración del trabajo del responsable del equipo, la gestión de las iniciativas de mejora, la satisfacción del propio equipo e incluso el cómo y dónde nos gastamos el dinero. Para no alargarnos no vamos a entrar en todos y cada uno de ellos (al menos no en este post) pero que sepáis que tenemos Trellos para aburrir (alrededor de una veintena para gestionar Tech) y que podría estar escribiendo sobre ellos hasta 2020.   😛

Trello y nuestro workflow de trabajo

Ya contamos en un post anterior parte del proceso de selección en el área de tecnología de Frogtek. Pero todavía podemos desvelar algún secreto más, y es que una de las primeras cosas que recibes al entrar el grupo de tecnología es una cuenta de Trello. Hasta ese momento podías conocer Trello o no; podías haberlo usado un poco para algunos proyectos, o tal vez para gestionar tus propias tareas. Pero ahora, con el acceso a los tableros de Frogtek… ya no hay vuelta atrás.

Fue una de las cosas que más me impactó: todo tiene una tarjeta de Trello. Y sí, lo admito, al principio es un poco overwhelming, tantos tableros, tantas notificaciones. Pero ahora ya está en el ADN, ya forma parte de uno mismo. Y si no está en Trello, seguramente, no ha pasado. De todas los procesos que tenemos trellificados me gustaría centrarme hoy en uno: las peticiones que se realizan a tecnología.
Seguir leyendo

Somos ágiles, hacemos stand-ups

Como crítica constructiva o destructiva, la frase se utiliza muchas veces. Uno lee artículos, escucha podcasts, ve charlas, … Stand-up para arriba, stand-up para abajo. Uno ya no sabe que pensar, casi mejor me quedo en la cama un rato más, que ahora en invierno se está muy “agustico”. ¡No! analicemos nuestros stand-up.

PRIMERO UN POCO DE REALIDAD

La realidad es que desde el teletrabajo los stand-ups solemos hacerlos sentados. Pero conservan el nombre. Y sí, a veces se alargan. En lugar de ver un círculo de gente rodeada de post-its y tareas en los cristales, veo los caretos de todos mis compañeros en primer plano (un porcentaje muy alto no nos hemos peinado, pero los auriculares lo disimulan). Eso sí, en lugar de post-its tengo mi libreta y un tablero de Trello con lo que he hecho, las siguientes tareas y lo que quiero comentar.

Empieza el stand-up, suele empezar el que ha compartido el enlace, tradición (todavía no es automático, ¡por el amor del MEV!).
Lo normal:
– Sujeto 1: Ayer hice esto y aquello, me queda pendiente esto que lo hago ahora por la mañana. Luego me pongo con aquello. Hoy trabajaré a partir de las 11:00 que me voy al médico.

Normalmente la cosa acaba aquí. Pero hay diferentes casuísticas interesantes.
Seguir leyendo

Conferencia Agile Spain 2016

La Conferencia Agile Spain es uno de los dos eventos organizados a nivel nacional por la asociación Agile Spain. Desde Frogtek acudimos todos los años a aprender y compartir sobre metodologías ágiles. Este año nos ha tocado a Jorge y a ser los privilegiados que íbamos en representación de Frogtek.

Hacía ya un par de años que no podía acercarme y he vuelto con la cabeza llena de ideas y cosas para hacer. La verdad es que no recordaba lo que me cargan las pilas este tipo de eventos. Las charlas pueden gustarme más o menos según elija. Pero siempre me hacen pensar, de una forma otra. De hecho a mitad de muchas de ellas me sorprendo a mi mismo evadido de la charla y pensando en como aplicar el concepto que acaba de explicar el ponente en nuestra empresa. O cómo nos afecta o por qué deberíamos mejorar en ese area.

Vamos que nunca me deja indiferente un sitio tan lleno de gente con ideas tan buenas y con tantas ganas de compartirlas. Además este año la organización ha estado de diez. Así que muchas gracias desde aquí a todos los que han participado, ponentes, voluntarios, etc. Por ayudar a que podamos seguir mejorando.

La comunicación y las nuevas herramientas: Slack

Siguiendo con el tema de la comunicación que ha iniciado Miky, me gustaría ahondar un poquito más en el tema.

El día 1 de abril, en Zaragoza, acudí al siguiente meetup donde Francho nos explicó cómo en su empresa, Spines, usan Slack y sus distintas integraciones. Siendo el centro de estas integraciones Hubot, un bot que permite realizar una serie de automatismos e integrar servicios y acciones fácilmente con Slack.

Como buen friki que soy tengo muchas ganas de montarme mi propio Hubot y ponerlo en nuestro Slack, pero eso no fue lo que más me llamó la atención de la charla. Lo que más me tocó fue el que ellos llevarán casi toda la comunicación a través de Slack. El email lo usaban lo mínimo. Según nos contó Francho en su cuenta de correo de la empresa sólo tenía 5 mails en los dos años y pico de empresa que llevan. Para poder llegar a esto, nos comentó que la clave residía en la separación correcta de las conversaciones en distintos canales, permitiendo así la selección de las conversaciones y facilitando la búsqueda y lectura de las mismas.

Como ya comentó Miky nosotros llevamos menos tiempo con Slack y nos ha reportado ya una serie de beneficios increíbles. No tengo claro que el objetivo deba ser abandonar el email del todo, pero sí que veo que para ciertos tipos de comunicación deberíamos tender más a Slack, sobre todo en torno a emails automáticos y alertas. Además creo que el tema de los canales por conversación tiene mucho sentido. Ahora mismo sufrimos, entiendo, uno de los primeros anti-patrones de uso de Slack, que es mezclar y tener muchas conversaciones en un mismo canal. No es que tengamos un único canal, ni mucho menos, pero igual deberíamos plantearnos dividir alguno más y acostumbrarnos a hacer un buen uso de los canales.

Al fin y al cabo es lo mismo que ocurre con el email. Con un buen uso de la herramienta se puede conseguir mejorar mucho la comunicación, sobre todo su calidad y facilidad de lectura. Aplicar una herramienta nueva lleva su tiempo y se necesitan distintas iteraciones hasta que se consigue dar en el clavo. Tenemos que trabajar en ello, así que ya tengo tema para la siguiente retrospectiva.

Comunicación: ajustando una máquina compleja (Work In Progress)

El Día del Bedel

El último viernes día 6 estaba marcado en el calendario de nuestra oficina como Janitor’s Day. ¿En qué consiste este día? El día del Janitor, bedel en español, es un día de trabajo que se dedica a limpiar, pulir y dar esplendor a todo la suciedad, desorden o incidencia en nuestro software (aunque claro, también podría haberse llamado el Día del Apaleamiento).

De esta forma, durante un día el equipo se dedica en exclusiva a realizar mejoras y modificaciones en el código que de otra manera se hubieran postergado y abandonado en el olvido.

El janitor de Scrubs, hombre 10

Para organizar el evento, creamos una hoja de cálculo con una amalgama de tareas que realizar. La idea era que voluntariamente, cada uno tomáramos una de esas tareas y nos encargáramos de solucionarla. Las tareas podían ser tan variopintas como arreglar una tanda de tests, refactorizar una clase o traducir al inglés las cadenas que quedan en español en la aplicación.

En definitiva: todos los que trabajamos en software nos damos cuenta de que en ocasiones, algunas tareas se postponen o se descartan porque se descubren a mitad de otra tarea, y el miedo al cambio de contexto impide su realización. Es por ello que realizar un Janitor’s Day cada cierto tiempo es una tarea que recomendamos encarecidamente, ya que las ventajas son incontables:

  • Permite coordinar al equipo en un mismo objetivo
  • Aumenta el control del código por parte del equipo.
  • Permite e incluso potencia el pair programming
  • Da cabida a tareas que de otra forma jamás se realizarían (desidia, desconocimiento del problema por parte del C-level, …)

Charla de Ángel Medinilla en Walqa: el biopic

El pasado lunes día 12 de noviembre tuvimos el honor de recibir a Ángel Medinilla (@angel_m) en el parque tecnológico Walqa (aprovechando su décimo aniversario) para que diera una charla sobre Agile en la empresa. Para el que no lo conozca, Ángel es un coach y consultor agile que lleva ya un tiempo recorriéndose el mundo asesorando a empresas sobre agilismo y contando su experiencia al respecto.

Como no me gustan mucho las notas de prensa en las que se fusila todo lo que dice el conferenciante, voy a escribir acerca de qué reflexiones he inferido tras asistir a su charla. Lo cual nos lleva al siguiente disclaimer…

DISCLAIMER: los siguientes puntos no están firmados por el propio Medinilla, son solo reflexiones obtenidas por mi parte. Al igual que con los biopics (películas basadas en la vida de alguien famoso), cualquier parecido con la realidad puede no ser cierto 😀

  • Las empresas de hoy en día son hijas de las cadenas de montaje y nietas del ejército de Roma. Estamos trabajando en compañías herederas de las ideas de Taylor y Ford (muchas de ellas incluso tienen residuos de las primeras grandes empresas: los ejércitos) y con ello, arrastrando conceptos empresariales basados en paradigmas del pasado, que pueden funcionar para una cadena de montaje, pero no para compañías basadas en el conocimiento. Suele circular por internet una anécdota graciosa: “¿Por qué los reactores de los cohetes de la NASA tienen la anchura de dos culos de caballo?… Pues bien, todo se debe a que los reactores han de ser trasladados hasta Cabo Cañaveral por tren, el ancho de las vías del tren se tomó en función del tamaño de los coches, y el coche en función del tamaño de la carretera, que es un legado del imperio romano, el cual quiso que la carretera tuviese el tamaño de dos caballos, para así permitir la circulación de carros.” Basándonos en esta anécdota, se me ocurre un paralelismo igual de gracioso: ¿Por qué algunos desarrolladores de software van a trabajar con traje y fichan nada más entrar?
  • No hay que ser esclavos de los estándares. Principalmente porque los estándares deberían revisarse continuamente. Siguiendo la filosofía lean, deberíamos usar estándares para asegurarnos de que todos estamos haciendo lo mismo. Intentar algo más complejo que eso solo va a conseguir que tengamos un sistema anquilosado difícil de renovar.
  • Muchos managers son sargentos chusqueros y deberían ser entrenadores. Donde las empresas basadas en los paradigmas de Taylor y Ford necesitaban de un supervisor que controlara la productividad de sus trabajadores, las empresas del conocimiento de hoy en día necesitan de líderes que sepan motivar y potenciar las capacidades de un equipo. Lo que llamaríamos en inglés un enabler, alguien que pueda conseguir que su equipo dé lo mejor de sí mismo.
  • Mejor que intentar ser agile es entender por qué queremos ser agile. Al igual que en el ejemplo del cargo cult, el hecho de poner post-its en la oficina para indicar las tareas (al estilo de las oficinas con sala de relax con el guitar hero porque Google la tiene) no va a hacer que nuestra empresa mejore. Tenemos que entender qué motivaciones tiene agile para poder comprender por qué queremos usar agile (¡o incluso si realmente queremos usarlo!)
  • Agile no es un paracaídas ni la pluma de Dumbo. No nos engañemos: la mera implantación de Agile no va a conseguir que hagamos software de calidad, ni que ingresemos más dinero, o que nuestros competidores vayan a la ruina. Es simplemente una metodología de desarrollo de proyectos mucho más orientada al cambio y a la mejora continua. Podemos migrar una empresa a agile, pero esto no va a  otorgarnos capacidad de mejora, entrega o adaptación. Estas capacidades son los requisitos para el camino Agile, no las recompensas.
  • Tenemos que ser escépticos respecto a Agile. Las metodologías ágiles representan un camino, una serie de filosofías que pueden ser de utilidad para las empresas. Pero no tiene por qué ser buenas para TU empresa. Como decía Henrik Kniberg, Scrum es una herramienta, puedes usarla como te plazca. Cada empresa es un mundo y como tal, es muy difícil que Agile te dé una solución personalizada. Eso sí, si modificas Scrum a tu antojo, luego no vayas diciendo por ahí que Scrum no te ha funcionado 😀

Slides de la charla en http://www.slideshare.net/proyectalis/agilidad-empresarial

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

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.

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

Antiguas entradas