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!

Anuncios

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.


Referencias acerca de Kanban

Los tableros visuales “kanban” son una de las técnicas que más fácilmente potencian a los equipos. Estos tableros dieron nacimiento al método Kanban, muy difundido y reconocido en el mundo de las ahora famosas “Metodologías Ágiles”.

Decimos que potencian fácilmente a los equipos porque su adopción inicial no requiere grandes cambios en la dinámica de trabajo… aunque las consecuencias de su utilización a consciencia, podrían (y deberían) traer aparejados, una buena cantidad de observaciones, reflexiones y mejoras (léase cambios e impactos) en el equipo y en cada persona involucrada.

Se trata de un método basado en la visualización del flujo de trabajo y la búsqueda de su mejora continua siguiendo ciertas prácticas y principios que están muy bien resumidos en este video de nuestros amigos de Fuerza Tres:

Quienes estén interesados en conocer más acerca de Kanban, encontrarán valiosos conocimientos en estos libros que recomendamos:

Dos libros disponibles gratuitamente online:

El libro original, pago, muy claro y también traducido al español:

  • Kanban por  David J. Anderson

Adicionalmente, Kanban se complementa muy bien con Value Stream Mapping, sobre el cual escribimos juntos* un breve capítulo en el libro Herramientas Ágiles; y está muy relacionado con Lean y sus 7 principios.

¡Los invitamos a que compartan en los comentarios de este artículo, otras referencias que encuentren de utilidad relacionadas con Kanban!

* Escrito en pares por Pablo Tortorella y Pablo Lischinsky, Agile Coaches de Kleer.

Guías Ágiles – primeros pasos!

En el marco del trabajo colaborativo que realizamos en Kleer, Hiroshi Hiromoto y quien escribe (Pablitux) hemos creado #GuiasAgiles, un lugar en el cual colocamos las dos guías que habíamos creado en forma conjunta durante 2015: #NecesitamosFeedback y #SesionesDeMejora.

Inmediatamente después surgió la idea de ofrecer a los visitantes la posibilidad de que pidan más guías y qué mejor forma que ofreciendo una guía para hacer los pedidos de nuevas guías, la cual se puede encontrar abajo de todo. Así, el 29 de diciembre de 2015 ya eran tres las guías en el lanzamiento 🙂

Ese día, con Hiroshi, aplicamos muchísimos de los conceptos ágiles que solemos difundir por el mundo: producto terminado por sobre documentación exhaustiva, pasamos del dicho al hecho en una reunión de una hora y media: elegimos un template para la landing page, elegimos qué información subir y cuál dejar afuera (por ahora), creamos textos, contratamos la URL (guiasagiles.org) y pusimos online un MVP (producto mínimo viable). Y hasta creamos esa tercera meta-guía.

Luego de unas horas y centenares de visitantes en el sitio web, conversando con Rodrigo MonelosNatalia Davidovich surgió la idea de digitalizar una guía que ellos habían hecho para usarla internamente en las oficinas de Kleer de Buenos Aires: #ReunionesConFoco.

Así terminó el año 2015, con cuatro guías y muchos lectores que expresaban su entusiasmo hacia las guías por varias redes sociales.

Ya en los primeros días de 2016 los que tomaron la iniciativa de crear y subir una nueva guía fueron Martín Salías y nuevamente Hiroshi. Se trataba de un paso a paso para realizar proyectos #IncepcionAgil.

Durante estos días de enero ya me han llegado novedades, ofrecimientos y pedidos de nuevas guías, que espero sigan enriqueciendo lo que bautizamos como #GuiasAgiles y que pretende cumplir con el lema “un lugar, todas las guías“.

Los invito a:
1- visitarnos: www.GuiasAgiles.org
2- descargar alguna guía
3- usarla
4- darnos feedback al respecto

Y… si les gustó alguna, difundan esta iniciativa con sus seres queridos y por las redes sociales usando el hashtag #GuiasAgiles 😉

Ideas para tu cabeza – Sombreros más ágiles

Se trata de una fábrica de sombreros.
No hacen otra cosa. Bueno… en realidad también hacen gorras.
Pero software no hacen, de eso estoy seguro. Nada que ver con desarrollo de software.

Ideas para tu cabeza es una fábrica de sombreros

Aclaro esto porque soy Ingeniero en Informática y docente en carreras universitarias de ese rubro. Además, en sus orígenes, Kleer -mi empresa- estaba enfocada principalmente en dar apoyo (mediante capacitación, coaching y consultoría) exclusivamente a equipos que desarrollaban productos de software, intangibles. Hoy en día el abanico de conocimientos adquiridos, técnicas disponibles y experiencias vividas se ha ampliado y hemos llegado a muy diversas industrias, tales como la manufactura y las agencias digitales, sin dejar de lado a los queridos developers.

– ¿Sombreros? ¿Y cómo podríamos colaborar con ustedes? – pregunté

– Trabajamos hace unos años con tableros Kanban para organizarnos. Ahora cambió el contexto y cambió parte del equipo… necesitamos algo nuevo. Me recomendaron que contacte a Kleer para potenciar al equipo y al negocio. – dijo Gaby (Gabriela Genovese) en la primera conversación telefónica.

Luego de esa charla, le compartí dos videos introductorios acerca de los doce principios ágiles y los cuatro valores del manifiesto ágil, y coordinamos una reunión, para que me cuente más acerca de su contexto.

Me acerqué al CMD (Centro Metropolitano de Diseño, en el sur de la Ciudad de Buenos Aires), donde actualmente se encuentra incubada la fábrica de sombreros “Ideas para tu cabeza”. Fueron 15 km en bicicleta, desde mi casa en el barrio de Palermo, que me dieron tiempo para reflexionar sobre las posibilidades que teníamos adelante con este tipo de proyectos. Una linda mañana de sol.

Me recibieron con unos mates y con las puertas abiertas y luego de dos horas de charla, llegamos a la conclusión que había mucha tela para cortar (literal y metafóricamente). Planificamos que empezaríamos escuchando al equipo. Primero mediante charlas uno-a-uno, entre Gaby y todas las personas que allí trabajan. Eso demoró unos días, pero lo llevaron adelante.

Los visité nuevamente unos días más tarde, para facilitar la primera Retrospectiva, como solemos llamar a las “sesiones de mejora”. Fue una reunión sumamente participativa. Surgieron todo tipo de cosas: agradecimientos para todos, actitudes que son valoradas dentro del equipo, problemas de organización, de orden, y presiones que sufren en las fechas cercanas a las entregas. También surgieron unas cuantas ideas para mejorar. Si bien el objetivo principal de esa reunión era compartir puntos de vista y exponerlos para que todos estén en la misma página, fueron más allá y se comprometieron a realizar varias acciones concretas para mejorar.

El equipo de Ideas para tu cabeza

Algunos compromisos tuvieron que ver con el orden de la materia prima, las máquinas y los sombreros terminados. Otros, con la forma de trabajar, de organizarse. También mostraron interés en tomar métricas para conocer el avance con respecto a las fechas de entrega de cara a los clientes.

A lo largo de la mañana, conversamos sobre el modelo Lean de manufactura, sobre las 5s y las 9s que usan muchas fábricas japonesas, sobre la importancia de la comunicación en el día a día del equipo… y ese día surgió un lema: “Seamos como los japoneses”.

¡Seamos como los japoneses!

Unas semanas después, el equipo se volvió a reunir para analizar cómo venían con sus compromisos. En la vorágine por hacer sombreros, habían dejado de lado esas ideas. Aprovecharon ese momento de “parar la pelota” para acordar ciertas cuestiones básicas relacionadas con la limpieza y el orden de su espacio de trabajo. También coordinaron horarios para sincronizar tareas diariamente en mini-reuniones. Adicionalmente, dijeron que tendrán visibles en una línea del tiempo, las unidades terminadas cada día. Ese día, hablaron acerca de formar hábitos y del desafío que eso representa.

Las cosas no cambian de un día para el otro, … o sí. En esta fábrica, se les dio la palabra a todos los integrantes del equipo y se respetaron las ideas que surgieron de sus cabezas. Ellos son los que saben hacer sombreros y de ahí provendrán una buena parte de las mejoras que puede haber allí.

Este es el inicio de una historia de mejora continua real. De un equipo auto-organizado. De personas comprometidas con su trabajo y con su forma de trabajar, con sus compañeros y compañeras, con el negocio.

Es el inicio, porque la mejora continua no es un destino sino un camino. Un camino que “Ideas para tu cabeza” decidió recorrer.

La mejora continua es un camino


Mirá el video institucional de “Ideas para tu cabeza”: