Acerca de Pablitux

@pablitux en Twitter - Agile Coach & Trainer en Kleer - Docente en UBA y UNTREF

Aterrizando la estrategia organizacional con Hoshin Kanri, OKRs y Experimentos

por Juliana Betancur y Pablo Tortorella

En estos últimos años, nos hemos encontrado con cada vez más personas y organizaciones que se basan en el propósito (el “para qué”) a la hora de tomar decisiones.

Hoshin Kanri y OKRs como metáfora de montaña cuya cima es el propósito y banderas que son objetivos cercanos

Dentro del proceso de acompañamiento que brindamos como Agile Coaches de Kleer, hemos venido utilizando una combinación de técnicas que nos resultaron muy valiosas y permitieron potenciar los resultados de nuestros clientes, y así avanzar hacia su propósito.

Específicamente, para un cliente del sector financiero estuvimos diseñando cómo llevar la agilidad a toda la compañía, como medio para mejorar la materialización de su estrategia.

Este trabajo, que llevamos adelante en conjunto Kleer e Improvement 21 [1], con la necesaria y valiosa participación activa de nuestro cliente, tuvo como punto de partida que, antes de hacer cualquier cosa, debíamos pensar qué queríamos lograr.

“Antes de hacer cualquier cosa deberíamos pensar qué queremos lograr.”

Si tenemos claridad sobre nuestro propósito o visión podremos diseñar un camino que nos permita avanzar en esa dirección. Para este diseño hemos encontrado en Hoshin Kanri + OKRs + Experimentos un complemento perfecto para conectar la estrategia con las acciones del día a día de los equipos de trabajo.

¡Veamos lo que hemos encontrado!

Hoshin Kanri

Es un conjunto de técnicas para la planeación estratégica, compiladas bajo ese nombre en un reporte publicado en 1965 por Bridgestone Tire Japan, a partir de casos de éxito en empresas japonesas [2].

Su nombre proviene [3], por supuesto, del japonés:

  • ho (dirección) + shin (aguja) = Hoshin (brújula)
  • kan (control) + ri (lógica) = Kanri (gestión)
Traducción detallada de Hoshin Kanri

“La visión compartida genera algo mágico: la alineación de las personas que la sienten propia.”

Hoshin Kanri es entonces la brújula para la gestión, pues ofrece visibilizar la estrategia para proveer dirección a nuestras acciones. Como una brújula, siempre que tengamos una duda acerca de qué camino o decisión tomar, podemos acudir a ella. Sin importar dónde estemos parados, siempre apuntará hacia la visión.

Cuando la co-creamos y la mantenemos presente, esa visión compartida genera algo mágico: la alineación de las personas que la sienten propia. Por ello, nos tomamos el tiempo de descubrir, co-crear y/o refinar la visión de cada equipo o área, teniendo en cuenta y siempre cuidando que sea coherente y apunte también a la visión organizacional.

Ejemplos de propósito:

– En nuestra organización es: “En Kleer disfrutamos co-creando ambientes humanos más conscientes y asombrosos”. Es un propósito que nos inspira y define claramente el “para qué”.

– En una empresa del sector financiero: “Somos el mejor aliado de los clientes en la satisfacción de sus necesidades financieras. Proveemos una amplia gama de productos y servicios con innovación, eficiencia y amabilidad, y generamos valor a nuestros clientes, colaboradores, accionistas y a la comunidad”.

Uno de los elementos dentro de la técnica Hoshin Kanri es la X-Matrix [4], que incluye metas a largo plazo (2 o 3 años). En nuestros proyectos, hemos preferido reemplazar esta matriz por una técnica más liviana, pensada para impactos más inmediatos, a corto y mediano plazo: los OKRs.

OKRs

Luego de tener la claridad de que la información estratégica debe fluir hacia todas las personas de la organización, pensamos en cuáles son esas cosas que queremos lograr para avanzar hacia nuestra visión. A las declaraciones de lo que queremos lograr las llamamos objetivos.

La metodología OKRs fue desarrollada en 1970 por Andy Grove, entonces presidente de Intel, y tomó aún más relevancia cuando John Doerr lo presentó a los ejecutivos de Google en 1999 [5], desde donde empezó a extenderse a otras empresas de Sillicon Valley. Consiste en definir objetivos que nos desafíen (a nivel personal, de equipo u organizacional), y en tener claridad sobre cuáles son los resultados clave (KR, del inglés Key Result) que nos van a indicar que estamos logrando esos objetivos.

Los objetivos se plantean de manera cualitativa y retadora, que nos hagan sentir esa tensión creativa que nos motivará a avanzar hacia ellos.

El cumplimiento de cada Objetivo lo medimos con uno, dos o más KRs. La combinación entre los Objetivos y sus correspondientes KRs genera más claridad de qué se quiere lograr específicamente y en qué plazo. Los datos que pensamos y mantenemos visibles para cada KR son variados: su nombre, la meta numérica, su fecha límite, cómo lo mediremos, el estado actual de la medición y otros que vemos necesarios en cada escenario.

Un punto muy importante de los KRs y que los diferencia de los KPIs es que no son métricas centradas en el esfuerzo, si no en los resultados que son valiosos de cara al objetivo.

Documentación gráfica generada en un encuentro que tuvimos con la Comunidad Ágiles Colombia en julio de 2018.

Estas actividades no suelen quedar listas en la primera sesión de definiciones. Recomendamos que los equipos se permitan refinar los objetivos y los KRs varias veces en los primeros momentos, sin olvidar que lo perfecto es enemigo de lo posible.

Algo a tener en cuenta, es que los objetivos de las diversas áreas de una organización deben ser coherentes entre sí. No deberíamos definir objetivos que vayan en contra unos de otros.

La vigencia de los objetivos y los resultados clave la deberíamos estar revisando mínimo cada 3 meses, con el fin de validar si eso que planteamos sigue siendo lo más estratégico.

Ejemplo de un OKR:

Objetivo:
Incrementar la recompra por parte de los clientes actuales.

Key Results:
KR1: Incrementar en 15% el número de clientes que recompran
KR2: Lograr xxx millones de ingresos por recompras.

Experimentos

Para materializar los objetivos que nos proponemos debemos pasar a la acción. Cuando no sabemos qué resultados tendrán nuestras acciones o qué cosas hacer, se hace necesario experimentar para validar nuestras hipótesis. Para eso, el método científico nos da una mano: diseñamos cada accionable rodeado de esa información que nos permitirá manejar la incertidumbre que tenemos en cada caso.

Una idea de cómo diseñar experimentos se puede encontrar en el Canvas de experimentos [6] (que incluye un ejemplo en la explicación de cada punto). Esos accionables entran a ser parte del trabajo de los equipos, que al final podrán validar o refutar la hipótesis, en ambos casos capitalizando el aprendizaje obtenido.

Ejemplo de experimento:

Diseñar un programa de fidelización de clientes para incrementar la recompra, apuntándole a mover la aguja del KR1: Incrementar en 15% el número de clientes que recompran.

Desarrollando esta hipótesis encontramos que primero era necesario validar si los clientes estaban interesados en hacer parte de un programa de fidelización, hipótesis que detallamos en el Canvas a continuación.

Conclusiones y otros detalles

Hemos tomado de cada técnica y de cada teoría, la porción que encontramos más valiosa. Combinamos varios métodos y los fuimos refinando. Finalmente, luego de varias iteraciones, encontramos este combo que nos está dando grandes resultados.

Enmarcar teóricamente nuestro método nos dio un valor agregado: cada vez que comunicamos los siguientes pasos a los equipos de trabajo se volvió clara y fácil, al tener nombres concretos, autores y referencias que respaldaran nuestra propuesta y le permitieran a las personas profundizar en su conocimiento y proponer mejoras.

Estas técnicas nos fueron de gran utilidad para impulsar una Evolución Organizacional integral. El modelo completo, incluyó también el diseño de un equipo base de soporte, un equipo de facilitadores, dinámicas de trabajo y otros componentes complementarios.

Este artículo también se encuentra disponible en el blog de Juliana Betancur: Con un dibujito se entiende mejor.

Referencias

[1] Improvement 21: https://www.improvement21.com/

[2] Historia de Hoshin: http://mcts.com/hoshin-history.htm

[3] Traducción de Hoshin Kanri: http://thekaizone.com/lean-books/hoshin-kanri-books/

[4] Acerca de la X-Matrix:  https://kanbanize.com/lean-management/hoshin-kanri/what-is-hoshin-kanri-x-matrix/

[5] Historia de OKRs: https://www.atiim.com/blog/perform-like-google-use-an-okr-tool-to-achieve-aggressive-goals/

[6] Canvas de Experimentos: http://kl.la/canvas-experimentos

Anuncios

HBR – 30 elementos de valor para el cliente

Comparto aquí el artículo más interesante y valioso que he leído en estos últimos meses. Se trata de una publicación de la Harvard Business Review que desarrolla el tema del Valor de negocio: “The 30 elements of customer value: A Hierarchy

En una de mis últimas publicaciones compartí un análisis que hicimos junto con colegas de la comunidad ágil latinoamericana acerca del “Valor” de negocio. Este artículo de la HBR va más allá y ofrece un desglose del concepto en 30 diferentes formas de entender qué es valioso para diferentes personas, equipos y compañías.

Ganar dinero, ahorrar tiempo y ahorrar dinero  son sólo tres posibles elementos de valor. Los más habituales, por cierto. Para conocer los otros 27, los invito a leer el artículo y ver la pirámide gráfica que permite conocerlos de un vistazo.

El link al artículo: https://hbr.org/2016/09/the-elements-of-value

La pirámide:

¿Qué opinión te merece? ¿Cómo utilizarás esta información?
Dejá tus comentarios en este post 🙂

Radiadores Visuales

El sábado 10 de diciembre de 2016 festejaron en Brasil el “Día de la agilidad” (Dia da Agilidade) y varios colegas de la comunidad postularon sesiones. Dado que sería un evento online, las sesiones iban a ser videos.

João Reis es un agilista que vive en las afueras de San Pablo. Le apasionan la facilitación gráfica y la mejora continua de equipos, al igual que a mí.

Luego de un intercambio de mensajes que tuvimos por Twitter, decidimos que postularíamos juntos una sesión relacionada con Radiadores Visuales de información, basado en un concepto descripto hace algún tiempo atrás por Alistair Cockburn.

Para ello, él viajó a la Argentina todo un fin de semana. Aprovechamos entonces para grabar el video para dicho evento online y también para otras dos actividades: ir a tomar unas cervecitas artesanales por Palermo como bienvenida el viernes y protagonizar el primer evento #SketchAndBeer el sábado, seguido de una deliciosa pizza acompañada con Fernet Branca con Coca-Cola 🙂

Aquí comparto los detalles de nuestra postulación y de nuestro video, es decir, nuestra sesión en el Día de la Agilidad: http://agilidade.org/blog/2016/11/21/visual-radiators-como-elementos-visuais-podem-ajudar-a-auto-organizacao-de-times-ageis/

Y aquí les acerco el video que creamos la tarde del domingo de ese fin de semana ágil y visual que compartimos a inicios de diciembre con João en las oficinas de Kleer, en Buenos Aires.

Está hablado en mi mejor portugués/portuñol, espero que se entienda 🙂

Luego de filmarlo, nos fuimos a tomar unos mates a la plaza, con mi amigo (y héroe) Alistair. Aprovechamos y seguimos conversando ahí acerca del tema de los radiadores de información, el fútbol brasileño y otras ricas yerbas.

Gracias por todo, amigo João… ¡A seguir co-creando ambientes humanos más visuales, conscientes y asombrosos!

Y a usted, Sr. lector, Sra. lectora… ¿qué le pareció el tema? ¿Qué opinión le merece? Comparta en los comentarios, pues 🙂

De qué hablamos cuando hablamos de Valor

Uno de los factores que nos motivan a los seres humanos, luego de tener satisfechas nuestras necesidades básicas, es el valor que podemos aportar al mundo que nos rodea. Necesitamos que el resultado de nuestro trabajo tenga una retribución o reconocimiento. Además de eso, a muchos nos gustaría que ese trabajo genere valor. Es más: en muchas ocasiones, el trabajo que hacemos no tendría sentido si no aporta valor.

Antes de entrar de lleno a darle un enfoque más cercano a la agilidad o la entrega de valor desde un producto/servicio no sobra abordar el término desde las ciencias del comportamiento humano, que habla de cuatro ejes sobre los que los seres humanos contemplamos el valor: desde el dinero, el tiempo, el impacto y la perspectiva. Aparentemente, después de estudiar la valía que le damos a las cosas, esos cuatro caminos definen en buena medida lo que consideramos como valioso o que tiene valor.

El valor se pone en marcha dentro de un contexto y nuevamente, desde esa mirada comportamental, se habla de dos sistemas sociales donde el valor se puede medir: Sistemas de Retorno (de Valor) Inmediato y Sistemas de Retorno (de Valor) Diferido. En la medida que podamos comprender el marco de ese sistema podemos abordar el valor como un punto de partida para comprender el porqué de muchas de las acciones que ponemos en marcha. Desde la creación de soluciones y en un contexto laboral, la lectura de valor puede ser distinta.

El ciclo de de vida productos se divide en diversas etapas: prototipado, introducción, crecimiento, maduración, declive. La definición de valor y el (los) KPI medido(s) depende en qué etapa se encuentra dentro del ciclo de vida y del tipo de producto (por ejemplo, e-commerce, B2B, B2C, SaaS, etc).

A veces se puede medir o calcular y otras veces sólo se puede estimar.

  • ¿Qué significa valor?
  • ¿Cuánto valor entregó el proyecto?
  • ¿Para qué lo queremos medir el valor generado?
  • ¿Cómo se puede medir o calcular ese valor?
  • ¿Cuánto valor entregará este equipo durante el próximo es?
  • ¿Podemos estimar el valor que obtendremos?
  • ¿Cómo se puede estimar ese valor?

Si alguna vez te hiciste alguna de estas preguntas, este artículo es para vos.

El concepto de valor es lo que intentaremos comprender más profundamente en este artículo. Intentaremos visualizarlo y analizarlo desde diferentes perspectivas: Qué, Para Quién, Para Qué, Cuándo y Cómo.

Pretendemos que el análisis aplique tanto a desarrollo de productos de software como también a otro tipo de proyectos.

Qué

“El concepto de Valor de Negocio (Business Value) representa el beneficio al cual accede una empresa, institución o grupo de usuarios cuando se disponibiliza una nueva funcionalidad del software para su uso productivo” de Thomas Wallet.

Los usuarios del producto construido o del servicio diseñado valoran el trabajo de un equipo cuando les permite realizar mejor su trabajo, por ejemplo: más eficientemente.

Las personas de negocio que decidieron invertir (tiempo, dinero, capacidad productiva) también valoran el trabajo de un equipo cuando les permite recibir un retorno de la inversión realizada. Este retorno es el valor que pretendemos conocer, cuantificar, medir, entender. A veces tiene forma de ahorro de tiempo o dinero, otras veces tiene forma de ganancias de dinero o de cantidad de usuarios, por poner algunos ejemplos concretos.

El valor entregado será consecuencia del impacto (o los impactos) que se genere(n).

Para quién

Negocio

Sponsors / Inversores / Stakeholders

Product Owners “Estratégicos”, más orientado a ayudar a definir la visión, el roadmap del producto basado en el valor de negocio, apoyándose en enfoques más  experimentales y trabajando más del lado del negocio.

El Product Owners “Operacionales” que trabaja más cerca del equipo refinando el Backlog, aclarando y detallando las Historias de Usuario.

Usuarios – Consumen producto o servicio.

Lo que construye el equipo debería ser algo que le sirva al usuario final, que le sea de utilidad, que termine adorando. No solamente es lo que se quiere o desea, sino lo que se necesita. Posiblemente no sea lo que exprese en los requerimientos. En estos contextos son útiles las técnicas de descubrimiento (discovery) de User eXperience (UX).

Equipo

Los equipos de trabajo valoran que su entregable sea valorado. Además les ayuda a entender los criterios de priorización del Backlog.

Para qué

  • Para priorizar (iniciativas; proyectos de una cartera o portfolio; o requerimientos de un Product Backlog).
  • Para decidir si considerar o descartar el proyecto o funcionalidad.
  • Motivacional (un equipo que conoce sus impactos trabaja mejor).
  • Un punto de referencia (para saber cómo venimos con respecto a nuestros desafíos y nuestro pasado inmediato).

Cuándo

Determinar cuándo medir el valor entregado depende de las características del proyecto.

Un proyecto aporta valor al ser liberado el producto, el servicio o el aprendizaje que busca obtener. El momento en el que se genera la liberación de ese resultado es una buena instancia de medición. Hay proyectos en los cuales hay entregas intermedias y otros en los cuales se ven resultados solamente al final. Cuanto antes ocurra la liberación, antes se podrá medir o calcular el valor entregado, a partir del impacto generado.

Sin embargo, muchas veces no se puede esperar hasta el final para medir o calcular el valor entregado. Es para eso que se recurre a técnicas que permiten estimar dicho valor.

Cómo

Un punto inicial para medir o estimar el valor de negocio es hacerlo lo más simple posible, esto se puede realizar cuantificando los beneficios en dinero. Para esto se podría considerar: optimización de un proceso, ahorro de tiempo, impacto generado (cantidad de nuevos usuarios a partir de la liberación, cantidad de transacciones) y otros indicadores que puedan aplicar en cada caso.

El siguiente paso es experimentar con otras formas de medir el valor e incluso crear una técnica propia de medición.

  • Algunas técnicas que permiten medir el valor de negocio
    • Asignar rangos de valores (oro, plata, cobre, madera)
    • Priorizar con naipes o billetes
    • Ponderando criterios
    • Matriz de comparación
    • Estimar el valor relativo en $ comparándolo con otro producto que conocemos su valor
    • Modelo Kano: para entender qué es lo que el cliente quiere.
    • WSJF: costo del retraso.

Dos técnicas (más amplias y abarcativas que las anteriores), que nos permiten aprender qué aporta valor a nuestros clientes y usuarios, son Design Thinking y Lean Startup, pues proponen tener interacción temprana con ambos públicos y realizar experimentos con prototipos simples, en ciclos cortos, con feedback frecuente y de calidad.

Más allá de las técnicas existentes, cada organización deberá encontrar su mejor forma para estimar y medir el valor: “Necesitamos mapas (modelos) y necesitamos recorrer el territorio. Una de cal y una de arena“. Organizaciones que aprenden en base a crear ambientes de trabajo seguros donde se dan equipos empoderados que se permiten experimentar.

Este artículo fue escrito en equipo por Roberto Mejías, Pablo Lischinsky, Pablo Tortorella, Leo Barrientos y Juan Daza Arévalo.

Es un resultado tangible y una suerte de resumen de una valiosa conversación que ocurrió en el grupo de Telegram de participantes del evento Agile Open Camp 2016 (AOC) realizado en Bariloche.

En ella también aportaron sus preguntas, referencias, opiniones y ánimos unos cuantos colegas latinoamericanos de la comunidad ágil, a saber: Tommy Christie, Florencia Rossi, Hiroshi Hiromoto, Lina Jervés, Diego Sánchez, Mauro Strione, Andrés Herrera, Juan Manuel Relloso, Deiby Od, Fernando Claverino, Alejandro Faguaga, Thomas Wallet, Felipe Talavera, Elias Molini y Sebastián Ghelerman.


Un tiempo después de escribir este artículo, leí una publicación de HBR en la cual se describen una jerarquía de 30 elementos que representan valor. ¡Lectura recomendada!

Scrum es un framework, no una metodología

photo_2016-11-01_14-18-28

Se dice que Scrum es un Framework [1].
Framework
es una palabra anglosajona que significa armazón, estructura o cimientos.

Lógica mediante: A entonces B. B entonces C. A entonces C…

Si queremos definir una metodología de trabajo para nuestro equipo, Scrum funciona como armazón de la misma. Si bien Scrum nos brinda ciertos elementos que ayudan a navegar la complejidad accidental de nuestros proyectos [2], nos deja en el umbral de la incertidumbre sobre el cómo llenar ese armazón. Es necesario complementarlo, está incompleto por diseño.

photo_2016-11-01_14-18-26 [1] “Scrum is a framework for developing and sustaining complex products.” http://scrumguides.org/

[2] https://es.wikipedia.org/wiki/Accidental_complexity


Artículo escrito en pares por Pablo Tortorella y Camilo Velásquez

Silencio

En el Open Space del Ágiles 2016 en Quito, Thomas WalletMartín Salías y yo propusimos una sesión llamada Silencio.

La Zona del Silencio

Marcamos una zona bien clara para hacer silencio, con algunas instrucciones bien visibles al entrar:

  • Te invitamos a entrar, en silencio.
  • Hay 6 estaciones, probá las que quieras, el tiempo que quieras.
  • Sólo o de a varios.
  • Siempre en silencio.

6 Estaciones para Experimentar el Silencio

Propusimos 6 estaciones dentro de la “Zona del Silencio”, para experimentar en cada estación una forma distinta de hacer silencio:

  1. Dibujando (Colocamos papeles y marcadores de colores).
  2. Mirándose a los ojos (Colocamos varias sillas enfrentadas).
  3. Con movimientos lentos (Simplemente había espacio libre).
  4. Quedándose quieto (Había sillones en este espacio).
  5. Creando tu propia forma de experimentar el silencio (Había notas adhesivas y un marcador, para que los participantes compartieran en silencio de qué forma estaban experimentando el silencio en este espacio).
  6. Escuchando tu respiración (Había una alfombra cómoda en este espacio).

Compartimos fotos de los distintos espacios:

Ver todas las fotos.

Feedback

Al final del recorrido, le pedimos a los participantes darnos su feedback sobre el espacio propuesto:

Reflexiones

Pasaron alrededor 60 personas en la Zona del Silencio, algunas se quedaron todo el tiempo (1 hora), otras un tiempo corto. Cada una probó algunas o todas las estaciones. Todos respetaron el silencio. Creemos que este experimento salió muy bien. Estamos muy contentos de haber creado y facilitado este experimento como una actividad más ligada al movimiento Slow.

Personalmente (Thomas), estuve muy atento al inicio a la facilitación del espacio, pero luego cuando vi que estaba funcionando solo, me pude relajar y entré en un silencio profundo quedándome sentado, conectándome con varias emociones fuertes de los últimos 3 días.

A mi (Martín) me llamó la atención la cantidad de gente que se acercó a participar, y no sólo como curiosos o a dibujar, que parecía la actividad más “usual”, sino los que se quedaron a meditar o más aún, los varios que se sentaron en las sillas enfrentadas a mirarse a los ojos. Yo personalmente me senté y pasaron tres o cuatro personas por delante mío que se sentaron y superaron ese temor cultural que tenemos de mirar fijamente a los ojos. Varios incluso eran desconocidos, y después de uno o dos minutos de miradas, generamos una confianza y una conexión extraña y reconfortante.

Yo (Pablitux) llegué de otra sesión en la cual también era facilitador. Todo estaba perfectamente organizado y listo para disfrutar de la zona y de cada espacio, gracias a la preparación de Thomas y Martín. Me gustó que durante la invitación/presentación de la sesión, al inicio del día, logramos que se hiciera un silencio muy profundo (más de 300 personas en total silencio consciente, por 10 o 15 segundos) y que así la gente se conectara con el propósito de la sesión.

Invitación

Los invitamos a que repitan este experimento:

  • Probando algunas de estas estaciones en el lugar y momento que quieran.
  • Creando nuevas estaciones.
  • Compartiendo sus experiencias haciendo silencio.
  • Replicando esta sesión en otros entornos.


Artículo escrito en conjunto por
Thomas Wallet, Martín Salías y Pablo Tortorella,
Agile Coaches de Kleer.

Experimentos en el Backlog

No innovamos. Los agilistas no innovamos… tanto. A fin de cuentas, también somos seres humanos y nos cuesta salir de nuestra zona de confort.
Cuando un equipo decide adoptar Scrum, es habitual que coloque Historias de Usuario en su Product Backlog. En todo el mundo se hace así.

Algo ahí hace ruido: las Historias de Usuario sirven para construir cosas que ya están definidas. Cuando llegan a los equipos de desarrollo, alguien (el Dueño del Producto con los usuarios, por ejemplo) ya descubrió, entendió y detalló lo que se requiere construir. También se lo involucró al equipo de desarrollo, seguramente. Han utilizado buenas prácticas: una tarjeta, varias conversaciones y criterios de aceptación. Todo muy “INVEST”… para luego ir a construir algo. Algo que aportará valor.

Detengámonos ahí. En la certidumbre. Pretendida certidumbre. Pretendida.

Los productos y servicios que se construyen usando Scrum, no suelen tener alcance predefinido. No se sabe qué características agregarán más valor al usuario y al cliente. Por eso, cada vez más equipos utilizan Design Thinking para descubrir de forma temprana y Lean Startup para descubrir de forma evolutiva, aquello que les conviene construir.

En ese contexto de incertidumbre, proponemos colocar Experimentos en los Backlogs.

Así como las Historias de Usuario sirven para aclarar qué se debe construir, un equipo podría (¿debería?) tener en su Backlog, unos cuantos Experimentos. Tantos como dudas e inquietudes tengan. Los mismos le permitirán aprender más y de forma continua, temas relacionados con sus usuarios, las necesidades, el potencial de sus ideas y características. Y ese aprendizaje crecerá a lo largo de todo el proyecto.

Cada experimento tiene su hipótesis. Cada hipótesis supone un camino y un resultado. Pero no sabemos si eso ocurrirá o no. Entonces diseñamos y ejecutamos el experimento más simple posible.

Validamos o refutamos. Y aprendemos.

Las Hipótesis dejan de ser tal cosa. Ese abordaje minimalista y prudente nos provee aprendizaje. Ese aprendizaje nos permite avanzar… o cambiar el rumbo.

Si refutamos una hipótesis, habremos ahorrado tiempo y esfuerzo que hubiéramos dedicado a construir algo que no lo valía.

Por otro lado, una vez validada la Hipótesis de cierto experimento, se hará más visible la conveniencia de avanzar con el desarrollo más profundo de las características en cuestión.

Presentamos, además de la idea, un Canvas de Experimentos, para que los equipos lo utilicen para diseñar sus propios experimentos de forma simple.

Para que cada día haya más Experimentos en los Backlogs de los equipos.


Este artículo fue escrito a partir de la aplicación y refinamiento de estos conceptos en diversos proyectos e iniciativas, por parte de Rodrigo Monelos y Pablo Tortorella, Agile Coaches de Kleer.