Agilidad más allá del software, una realidad

Por: Pablo Tortorella y Juliana Betancur

¿Qué es eso de la agilidad? ¿Aplica solo al mundo del desarrollo de software? Inicialmente sí, el término fue pensado para construir mejor software. Nosotros mismos la conocimos en ese ámbito.

Luego de varios años de aplicar ciertas técnicas ágiles, pudimos observar que las características de esos equipos que construyen soluciones tecnológicas, también están presentes en otros entornos complejos.

En nuestro rol de Agile Coaches, solemos acompañar evoluciones organizacionales que buscan mejorar la forma de abordar esa complejidad. Allí, en esos procesos de transformación profunda y de aprendizaje duradero, encontramos muy útiles muchos de los patrones ágiles que aplicamos anteriormente en entornos cercanos al software.

Por esta razón es que podemos afirmar que la agilidad no aplica sólo al desarrollo de software y para ilustrarlo queremos compartir en este artículo algunos ejemplos concretos.

Primero, repasemos qué es la Agilidad. Creemos que ese concepto está muy bien resumido en dos oraciones: “Colabora para Entregar valor” y “Reflexiona para Mejorar”. Esos cuatro verbos en imperativo -colabora, entrega, mejora y reflexiona- nos invitan a entender y vivir la agilidad y el mundo del trabajo de una manera concreta, aplicable a todo tipo de ámbitos. Con esas cuatro palabras, Alistair Cockburn, uno de los firmantes originales del Agile Manifesto (2001), redefinió la agilidad en su “Heart of Agile” (2015).

Copia de HoA.png

Rombo de Heart of Agile

También queremos aclarar qué no es la Agilidad: desde la creación del citado Manifiesto Ágil en 2001, el significado de agilidad se ha venido tergiversando y habitualmente se usa como sinónimo de conceptos que se alejan de su sentido original. En el ámbito corporativo, por ejemplo, suele asociarse únicamente con rapidez para hacer y miles de jefes alrededor del mundo la usan como excusa para exigirles un mayor rendimiento a “sus” equipos: que generen más en menos tiempo. Y no es que no hablemos de rapidez: entregar valor de forma temprana es una de las promesas ágiles: los primeros resultados se pueden observar más rápidamente que en otros escenarios, y eso no debe confundirse con entregar rápido a cualquier costo, sacrificando la calidad de los productos o la calidad de vida de las personas.

Entendiendo el Corazón de la agilidad

El Corazón de la agilidad usa cuatro palabras simples que llaman a la acción. Veámoslas un poco más en profundidad:

Colabora

Es una invitación a trabajar con otros, a ofrecer ayuda y pedir ayuda. Al acercarnos más, nos comunicamos mejor y podemos crear mejores cosas juntos cuando compartimos una visión común.

Entrega

Cuando entregamos, lo que estamos construyendo genera valor. Se promueven entregas tempranas y frecuentes, para aprender temprano y ajustar el curso que estemos siguiendo. Es clave estar cerca de nuestros usuarios y clientes para asegurarnos que estamos entregándoles algo que realmente valoren.

Reflexiona

Hacer pausas frecuentes para pensar en la forma como nosotros, nuestros equipos y nuestras organizaciones están haciendo las cosas. Acortar los ciclos de retroalimentación es una de las claves a tener en cuenta.

Mejora

«Ejecutar las acciones necesarias para mejorar la dirección de nuestras ideas, su implementación técnica, y nuestros procesos internos»¹.

Ser y hacer, dos dimensiones de la Agilidad

Al repasar las cuatro palabras que resumen el Corazón de la agilidad, vemos que no se trata de una receta, ni de una metodología que se pueda seguir paso a paso, ni tampoco de una técnica específica, sino que es más bien una filosofía o una forma de pensar, actuar y ver el mundo. En inglés, lo llaman Agile mindset.

Copia de Agilidad elementos

La agilidad implica el ser y el hacer

Es habitual ver también a la Agilidad como un conjunto de valores y principios, tal como fue definida en 2001. Ellos nos permiten entender aún mejor ese mindset. Si una persona o un equipo suele actuar acorde a esos valores y principios, podríamos afirmar que está siendo ágil. Es algo del ser.

Y para poder ser, se dice que también hay que hacer. En ese sentido, existen múltiples marcos de trabajo y técnicas que permiten aterrizar al día a día todos esos conceptos -algunos un tanto abstractos-. Allí es que aparecen palabras como Iteraciones, Scrum, Kanban, Value Stream Mapping, Retrospectiva, Daily Meeting y automatización, por citar algunos ejemplos.

A continuación compartimos algunas experiencias de aplicación del Agile Mindset fuera del ámbito del software, a partir de varias técnicas y frameworks específicos, en empresas con las cuales hemos venido trabajando últimamente.

Cómo aplicamos la Agilidad en las organizaciones, más allá del desarrollo de software

Equipos multidisciplinarios y autoorganizados

Es muy común encontrar que las organizaciones están divididas en departamentos o áreas, según el tipo de trabajo que se lleve a cabo. Esto es muy beneficioso para el funcionamiento interno de cada área, pero no tanto cuando hablamos de construir algo que requiere diferentes habilidades y conocimientos.

Por ejemplo, si hablamos de crear una nueva unidad de negocio en una organización, lo normal sería involucrar al área de comunicaciones sólo cuando creemos que se necesita. Esto teóricamente nos permitiría optimizar mejor los “recursos” (decirle recursos a las personas es otro tema de conversación), pero tal vez esa persona de comunicaciones no va a estar presente cuando ocurra una conversación clave del equipo, o puede que esté ocupada justo en el momento en el que más se la necesite, porque tiene otras prioridades.

Es ahí cuando brillan los equipos multidisciplinarios: en este caso, si el rol de comunicaciones se encuentra dentro del equipo, no se tendrán dependencias externas pues se tienen todas las habilidades necesarias para desarrollar el producto o servicio en el que se está trabajando. Y su aporte al equipo podría ser más amplio que «simplemente» comunicar, dado que conoce de cerca los objetivos del equipo y seguramente tenga ideas y ganas de colaborar en otras actividades que no sean sólo las de su área funcional dentro de la empresa. Lo mismo podría pasar con legales, riesgos o tecnología, por mencionar tres áreas adicionales. Y si son autoorganizados, esto les permitirá tener autonomía para decidir la manera en que harán las cosas, permitiéndoles así estar más motivados y ser más efectivos.

Tableros que nos guían

Los tableros visuales permiten visibilizar el flujo de trabajo de un equipo: saber qué tareas están pendientes, en progreso y terminadas. Se trata de una herramienta que habilita la colaboración, pues permite conocer en todo momento que están haciendo las otras personas del equipo y así apoyarse mutuamente. Uno utilizado frecuentemente es el Tablero Kanban. Los vemos en todo tipo de paredes, algunas con notas adhesivas, otras con monitores que proyectan tableros digitales. Y otras veces están presentes en aplicaciones web o del celular. Incluso se pueden ver tableros de tareas personales y familiares en neveras o en el escritorio del hogar.

Visión, estrategia y objetivos claros

La visión y la estrategia son una brújula que guía nuestras acciones. O deberían serlo. Si esa visión y estrategia son conocidas y retroalimentadas por los diversos niveles, equipos y/o áreas de la organización, podremos conocer qué agujas mueven nuestras acciones, y así podremos adaptarnos mejor al entorno en el que nos estamos desenvolviendo. Técnicas como Hoshin Kanri y OKRs (ésta última, frecuentemente utilizada en empresas de Silicon Valley) serán nuestras aliadas en este camino. Una de las ventajas de practicar este tipo de definición y seguimiento de objetivos es que cada día tendremos la posibilidad de saber qué impacto generamos en nuestro día a día.

Procesos más livianos y optimizados

Caminando de la mano de la agilidad, va casi siempre el Lean mindset. Esta filosofía nació en Japón, específicamente en Toyota. Luego fue llevada a muchas otras compañías automotrices y más adelante se extendió en la industria manufacturera en general. Al llegar a los Estados Unidos, el concepto se tradujo como «Lean», que significa magro, sin grasas. Esta forma de trabajar es muy compatible con la agilidad, al punto tal que muchos los vemos como algo indivisible: somos ágiles sólo si aplicamos los principios Lean. Solemos aplicar una técnica llamada Value Stream Mapping (mapeo del flujo de valor) cuando identificamos que un proceso de negocio puede ser optimizado. Ese mapeo lo realizamos con las personas que participan activamente en el día a día de ese proceso, y el resultado del ejercicio suele ser una acción concreta que podría mejorar algo esencial del proceso. Generalmente se trata de una combinación entre la experiencia de los clientes y la disminución del tiempo total. Tanto los empleados como los usuarios suelen estar felices luego de una mejora de procesos fruto de este tipo de experimentos.

Retrospectivas

La actividad de reflexionar y buscar acciones concretas para la mejora, la hemos venido encapsulando los agilistas en un estilo de reunión que llamamos Retrospectiva. Es el primer paso para casi todas las intervenciones en equipos y ámbitos complejos. Se trata de conversaciones enfocadas, con un propósito múltiple: conocernos mejor, conocer nuestros puntos de vista y, a partir de esa nueva realidad común, buscar juntos cómo podemos mejorar. Esa nueva realidad ya no es la realidad como sólo yo la veía, ni como sólo tú la veías, sino que ahora vemos las diversas perspectivas y vemos nuevas problemáticas y también nuevas oportunidades. Las retrospectivas las pueden realizar todos los equipos, todas las familias, todas las organizaciones. Pueden durar quince minutos o dos o tres horas. Hay cientos de técnicas que nos permiten sacar lo mejor de ese espacio. Es una de las mejores inversiones de los equipos, pues de ahí salen experimentos que pretenden mejorar -concretamente- el mundo, nuestro mundo.

Experimentación desde el método científico

Y ya que mencionamos a los experimentos dos veces, cerraremos este artículo con una protagonista estelar de todo este mundo ágil: la experimentación.

Cucharita helado

Cuando probamos un helado antes de comprar el litro completo, estamos experimentando.

En entornos complejos, muchas veces no conocemos qué resultados tendrán nuestras acciones. A veces podemos intuir que cierta causa generará cierta consecuencia… pero no nos sorprendemos tanto si la intuición no nos lleva a buen puerto. Para mitigar ese riesgo, es que diseñamos experimentos, como lo hacen los científicos y como lo hacen las personas que quieren probar una cucharadita de ese sabor nuevo que ofrecen en la heladería del barrio. Postulamos una hipótesis (si hacemos A, obtendremos B) y tratamos de llevar adelante la acción más pequeña posible (como la cucharada de helado) que nos permita aprender si estamos en lo cierto o si debemos ajustar el rumbo. Esta forma es archiconocida en el mundo como «método científico» y venimos usándola formalmente desde hace años. Con ella logramos que los equipos sean más conscientes de que viven llenos de hipótesis en ambientes de incertidumbre y que los pasos pequeños y el diseño deliberado de experimentos los pueden hacer avanzar con paso firme hacia la solución de sus problemas y hacia el logro de sus desafíos.

Algunas conclusiones

Entendemos a aquellos developers que sienten que la agilidad original y verdadera corresponde al mundo del software. Así fue concebida en los inicios de este milenio y allí seguirá siendo una de las claves para el éxito de los proyectos y productos tecnológicos.

Y además, hemos notado durante los últimos 10 años, que muchos de los aprendizajes que tuvimos los agilistas en ese mundo de TI se pueden aprovechar en otros ámbitos. No lo vemos como algo excluyente, sino como una gran oportunidad de mejorar el mundo.

La agilidad se ha vuelto para nosotros una forma de vivir mejor, de ser personas, equipos y organizaciones más conscientes. Nos ha abierto la puerta de la reflexión y de la mejora concreta. Les ha permitido a nuestros clientes  ganar y ahorrar dinero, resolver problemas muy desafiantes, crear sinergias donde parecía no haber siquiera confianza y crear ecosistemas en los cuales las personas florecen y los resultados se multiplican.

Para cerrar, te dejamos una última pregunta: ¿cuál va a ser el sabor de agilidad que probarás en tu próximo experimento?

Referencias

¹Heart of Agile. (2018). Empecemos | Heart of Agile. [online] Disponible en: https://heartofagile.com/empecemos/?lang=es [Accesado 6 May 2019].

Historias de usuario: en búsqueda del entendimiento compartido

¿Cómo alinearnos mejor con nuestros usuarios? ¿Cómo entender sus necesidades cuando no comprendemos la forma en que escriben los requerimientos? Pues bien, ahí está precisamente el quid del asunto. El problema principal no es cómo escribimos o cómo redactamos un texto: es de qué manera interactuamos.

PNG image-90B34C7FA176-1

La importancia de la comunicación cara a cara

Cuando hablamos de historias de usuario, nos centramos en la conversación. Partimos de una necesidad que tiene nuestro usuario y a partir de ahí hablamos en torno a entender muy bien esa necesidad y el para qué (los beneficios que esperamos obtener).  La conversación es lo que permite que haya un entendimiento compartido, que pasemos de decir «supongo que esto es a lo que se refería» a decir «entiendo para qué lo necesitas«.

Origen

Las historias de usuario, o user stories, tienen su origen en el trabajo de Kent Beck, a finales de los 90’s. Él notó (supongo que no fue el único…), que diferentes personas leyendo el mismo documento, pueden interpretarlo de maneras completamente diferentes. Entonces incluyó dentro de «Extreme Programming» el término «historia de usuario» para definir algo que un usuario quiere hacer dentro de un sistema, y de lo que se hablará con más detalle antes de construirlo.

Las tres C

PNG image-00F72E0BD373-1

Partiendo de que buscamos el entendimiento compartido entre los que tienen una necesidad y los que saben cómo resolverla, entonces ¿cómo seguimos? Ron Jeffries encontró cómo resumir el proceso en tres simples C:

Card (Tarjeta)

Una oración que resume la necesidad y se escribe en una tarjeta. Es frecuentemente utilizado el formato rol-necesidad-beneficio (o formato Connextra). No es obligatorio usarlo, pero es una buena guía para empezar. Cada necesidad del usuario se escribe en una tarjeta (de modo que se convierta en una promesa de conversación). IMPORTANTE: son escritas desde el punto de vista del usuario.

Formato rol-necesidad-beneficio

Como [tipo de usuario] -> quién
quiero [necesidad] -> qué
para [beneficio esperado] -> para qué

¿Cómo se vería esta información con una historia real? Veamos:

Ejemplo:  Retirar dinero
«Como cliente del banco,
quiero retirar dinero de mi cuenta
para hacer pagos en efectivo»

Con estas tres simples líneas conoceremos: el quién (lo que nos permitirá ubicarnos dentro de un contexto de uso), el qué (cuál es el problema a resolver) y el para qué (el valor que esperamos obtener una vez construida la historia, y que será fundamental a la hora de priorizar).

Conversation (Conversación)

La conversación es la comunicación cara a cara (¡no es un título en un documento!). Es el momento en que se juntan las personas que conocen la necesidad con quienes conocen cómo solucionarla, para hablar en torno a ello. A partir de preguntas y respuestas, se busca el entendimiento compartido del problema que se quiere resolver. Aquí es recomendable usar todos los recursos que estén a nuestro alcance para validar nuestro entendimiento (hacer prototipos, usar facilitación gráfica, etc.).

Ejemplo: Retirar dinero
«-¿Existe algún máximo de dinero a retirar por transacción?
– Sí, $200 por transacción, y $1.000 por día.
– Si el usuario tiene menos dinero del que quiere retirar, ¿qué mensaje se le muestra?
– Podría ser «Señor usuario, los fondos son insuficientes. Por favor intente con un valor menor o igual a xxx».
– ¿La interfaz de usuario podría mostrar la información de esta manera?
<<mostrar prototipo>>
– Sí, y agregaría…
– ¿Qué pasa si el cajero no tiene dinero suficiente?
– En ese caso…».

Confirmation (Confirmación)

La Confirmación es el acuerdo en torno a lo que vamos a construir. Es lo que nos permitirá saber si terminamos de construirlo o no, y si cumplimos con lo que se esperaba. En este punto podemos plantear escenarios y la manera como el sistema se comportará en cada uno de ellos. Lo anterior es lo que llamamos «criterios de aceptación«. Una historia de usuario puede tener uno o muchos criterios de aceptación.

Ejemplo: «Retirar dinero»
«- Dado que tengo $400 en mi cuenta
cuando voy a retirar $100
entonces mis saldo queda en $300 y el sistema me entrega $100.»

¿Y después?

Las Historias de Usuario serán el insumo para construir de manera incremental nuestro producto. Deben ser pequeñas, de modo que puedan terminarse, de punta a punta, dentro de una iteración de trabajo. Un buen resumen de cómo dividir las historias de usuario, se encuentra en este genial mapa de Agile for All.

Referencias

  • Cohn, M. (2018). User Stories and User Story Examples by Mike Cohn. [online] Mountain Goat Software. Disponible en: https://www.mountaingoatsoftware.com/agile/user-stories
  • Patton, J. (2014). User story mapping. Beijing: O’Reilly. (disponible en Amazon)
  • Cohn, M. (2013). User stories applied: for agile software development. Boston: Addison-Wesley. (disponible en Amazon)

Compartiendo experiencias: Una retrospectiva (1)

Me gusta mucho encontrar formas diferentes de trabajar las retrospectivas con los equipos, de modo que la búsqueda de la mejora continua capture el interés de las personas que participan en ella. Hoy quiero compartir una de las retros que hice hace unos días, y que posiblemente servirá de inspiración para alguien que también esté buscando ideas…

Icebreaker: Los súper héroes (15 minutos)

Para que una retro sea verdaderamente productiva debemos tratar, como facilitadores, que los asistentes se sientan cómodos de brindar sus opiniones, creando una atmósfera de comunicación fluida. Esto lo podemos lograr con los «icebreakers», actividades que, como su nombre lo indica, buscan romper el hielo. En la retro de la cual hablo hoy rompimos el hielo con una actividad conocida como Los súper héroes, que también permite que el equipo se conozca mejor.

La dinámica consiste en que a cada miembro del equipo se le da una hoja de papel y un marcador para que haga lo siguiente:

  • Dibujo de cómo se visualiza como súper héroe
  • Nombre de súper héroe: Ideal que sea un nombre creativo/divertido.
  • Súperpoderes: ¿Cuáles son mis súper poderes, de cara al equipo?
  • Debilidades: ¿Cuáles son mis debilidades, de cara al equipo?
  • Archienemigo: Esa cosa o esas cosas que no puedo soportar (tratar de pensarlo desde el contexto laboral).

Yo lo que hago es que al momento de explicar la actividad tengo una guía visual de lo que deben hacer, que luego les pongo en un lugar visible.

Facilitación gráfica_14

Al terminar, cada persona presentó su Súper Héroe a los demás miembros del equipo, y pegamos los dibujos en una ventana. Han pasado varios días y los dibujos aún están adornando su lugar de trabajo 🙂

20160126_115732 (1)

* Ésta dinámica la complementé a partir de una que encontré en Retromat 

Objetivo de la retro

Es importante variar las retrospectivas que se hacen con los equipos para que las reuniones sean más dinámicas, pero no es algo que deba hacerse deportivamente. Tenemos que contar con un criterio claro, basado en las necesidades del equipo y en si, como coaches, queremos apoyarlos en un tema en particular que el equipo esté necesitando.

Por sugerencias previas de algunos miembros del equipo, decidimos que el objetivo de esta retro fuera el cambio, lo que coincidía además con lo que varios habían señalado como debilidades en la actividad de súper héroes.
Empecé planteándoles tres preguntas, que había preparado previamente usando la herramienta Pollev, en la que pueden votar y los resultados se ven en tiempo real, cambiando los porcentajes a medida que la gente vota (cosa que logró conectarlos bastante con la reunión, hasta querían que fueran más preguntas…).

 Pregunta 1: Entre las siguientes dos opciones, dirías que el equipo esPregunta 1: Entre las siguientes dos opciones, dirías que el equipo es:

Pregunta 2: Con respecto a la forma como enfrentamos los nuevos retos COMO EQUIPO, dirías:
20160126_105733
Pregunta 3: Al momento de buscar alternativas de solución a un problema:
20160126_105937
A partir de ahí empezamos a hacer el análisis de por qué creían, como equipo, que eran temerosos ante el cambio. Luego del análisis obtuvimos varios post-its por los cuales votaron, siendo dos los más votados:  «Nos vamos por lo fácil y conocido» y «Presión de tiempo para mantener la operación». Luego les hablé un poco de las zonas de control, influencia y preocupación para ver donde ubicarían estos dos ítems, concluyendo que el hecho de irse por lo conocido era algo sobre lo que se podía trabajar como equipo.

CIERRE

Hablamos un rato sobre posibles soluciones a los problemas encontrados y luego les pedí que escribieran en un postit cuál iba a ser su próximo pequeño paso en dirección a ser más abiertos al cambio. Construyeron con esto un plan de mejora (con responsables y fechas), pensando en que fueran accionables concretos y no simple «politiquería» o palabras bonitas.
Y al final, la encuesta de la retro!! 💃
Esta última pregunta la podemos hacer votando con las manos (dedo pulgar hacia arriba, al medio o hacia abajo), o puede ser una pregunta en Pollev. Sea como sea que la hagamos, es una buena práctica preguntar la opinión de los asistentes al final de nuestras reuniones, para identificar oportunidades de mejora que nos permitan aprovechar mejor estos espacios con la gente.
20160126_115722