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.


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.

Ey, facilitadores y Scrum Masters: ¡¡pilas!!

“Y el Scrum Master del equipo nuevamente se levantó y nos dijo: Muchachos, es hora de la Daily Meeting. Como cada día a esa misma hora, todos lo miramos con cara de pocos amigos cuando nos interrumpe nuestro trabajo.”

Si sos facilitador de algún equipo o espacio, ¿Qué tan lejos te sentís de esta situación? Ojalá que muy lejos, que tu día a día tenga cosas más interesantes que invitar a tus compañeros a una reunión de sincronización.

Que tus días no pasen a escalas grises, y no cedas ante la inherente monotonía que trae consigo un propósito casi utópico de alcanzar. Crear un ambiente asombroso y consciente es un desafío inmenso, en la mayoría de los casos. Que este reto no te apabulle.

“Bienvenido, serás el facilitador de este equipo. Acá tenés impreso el proceso que siguen nuestros Scrum Masters acorde a lo estipulado en las normas de calidad. Mañana es tu primera Planning. En el link que te pasé por correo está el Release Plan con los Deadlines que esperamos para este proyecto. ¡Éxitos!”

Posiblemente esperen de vos las actividades típicas del manual, de la guía. No dejes que esto te consuma. Esto es un llamado a la acción: Espero de vos un rol más atento y activo. Sé consecuente con lo que predicas, no te quedes con la teoría que promueve un libro, descubre tu camino sin miedo a fallar y experimentar. Vas a necesitar coraje, disciplina, creatividad… y un montón de huevos. Y si fueras una señorita o señora: el equivalente, pues.

pd. La valentía no es ausencia de miedo, sino la capacidad de enfrentarlo
(frase inspirada en Nelson Mandela).

Escrito en pares por Camilo Velásquez y Pablo Tortorella, Agile Coaches de Kleer

No te lo tomes a mal, pero…

Tengo algo que decirte.
No lo tomes a mal, pero…

Decime: ¿Qué probabilidad existe de que esa oración termine con una afirmación que sea fácil de digerir?

Entonces, ¿por qué no procesamos un poquito eso antes de decirlo así, como pensábamos decirlo? No planteo que NO lo digamos, sólo que lo pensemos un poquito.

Sobre todo, pregunto esto (a modo de pedido o sugerencia) pues la persona a la cual habitualmente nos referimos en ese tipo de conversaciones, suele ser una persona a quien apreciamos y respetamos. Y tenemos ganas de que escuche y tome (y ojalá tome a bien) nuestra opinión o comentario.

Si tuvimos la intuición y percibimos que el otro podría llegar a tomar a mal nuestro comentario, al punto de hacer ese pre-aviso, hagámosle caso a nuestra intuición. ¡Para que no duela ni ofenda!

Y por las dudas: eso de “la verdad no ofende” me hace mucho ruido, porque el concepto de “LA verdad” me suena complejo y hasta casi irreal. Todos tenemos nuestro punto de vista subjetivo ante la realidad que nos rodea, acorde a nuestro modelo mental, que a su vez se desprende de nuestra historia y experiencia.

Creo que eso de “no te lo tomes a mal” es un anti-patrón de conversaciones que podemos detectar y evitar.

Entonces propongo: al hacer una observación, cuidemos las formas además del contenido😉