E014 – Conceptos Agile: ¿Qué es la entrega temprana y frecuente de valor?

Suscríbete en: Spotify | Apple Podcasts | Google Podcasts

Índice:

1. ¿Qué es el valor?
2. La paradoja del agua y los diamantes
3. El valor se reconoce claramente como subjetivo
4. Value Stream Mapping
5. ¿Cómo entregamos valor de forma iterativa incremental cada dos semanas?
6. ¿Cuál es la ventaja de hacer entregas frecuentes y tempranas de valor?

En el episodio ¿Qué es Agile y por qué clave en la Transformación Digital de una empresa?, sinteticé 4 conceptos que para mí son de gran importancia a la hora de entender su significado:

1. Entrega temprana y frecuente de valor,
2. Cross-funcionalidad,
3. Individuos motivados,
4. Mejora continua.

Hoy vamos a tratar en profundidad el primero de ellos, empezando por una pregunta clave:

¿Qué es el valor?

Al revisar las reflexiones y las discusiones que ha habido en el campo de la economía a lo largo de la historia, me he encontrado con un debate que me ha sorprendido y del que aún se habla. Un momento clave de esta historia viene de la mano de la escuela clásica de Economía de Adam Smith, David Ricardo y muchos otros, que, en mi opinión, son los máximos exponentes de la escuela clásica. Esa primera reflexión acerca del valor, diferencia entre valor de uso y valor de cambio.

Esta reflexión no cree que el valor de uso de un producto resulte económicamente significativo, ya que existen objetos que son muy útiles y que, sin embargo, no se intercambian. El valor de cambio, por otro lado, es aquel que establece cuánto de un producto se debe intercambiar para obtener otro. Permite establecer relaciones entre productos. Y es por ello que resulta económicamente tan significativo. La pregunta es ¿Cuál es ese elemento unificador que permite comparar los valores de cambio de diversos productos? Smith introdujo un concepto que sostuvo que el trabajo era la medida del valor, es decir, desde esta perspectiva, la cantidad de trabajo invertido en un producto determina su valor.

La paradoja del agua y los diamantes

Adam Smith la menciona en su obra “La riqueza de las naciones” y ha sido objeto de estudio por parte de los economistas de diferentes ideologías.

Imaginemos que llevamos varias horas vagando por el desierto, a punto de morir deshidratados y de repente encontramos una tienda que vende diamantes y botellas de agua. El precio de la botella de agua es 100 veces el del diamante. ¿Qué compraríamos?

Hay varias soluciones. Una de ellas, la que propone Marx, que desarrolla la teoría del valor-trabajo.

Marx decía que la magnitud del valor de una mercancía es el matiz, es el trabajo socialmente necesario para su producción, que no está determinado en absoluto por el valor de uso. Por lo tanto, el valor del agua es normalmente menor que el de un diamante, ya que el trabajo socialmente necesario para conseguir un diamante es mayor que el necesario para proveerse de agua y ello es independiente de que el agua sea usada para satisfacer una función vital y el diamante no.

Esto es un componente que se ha visto condicionado por este concepto, y que muestra una de las diferencias entre el capitalismo y el comunismo. Cómo los individuos colaboran y en base a esa colaboración, desempeñan un trabajo con muchas individualidades. Está claro que en situaciones de escasez el valor es mayor porque las condiciones de escasez implican un aumento del trabajo socialmente necesario para adquirir o producir una mercancía. Así lo entendía Marx. La escasez de los diamantes implica mucho más trabajo para conseguirlos y por eso son tan valiosos.

Desde el punto de vista de Marx, la paradoja del valor o la paradoja del agua y el diamante es solo un ejemplo del error teórico en que incurrían los economistas clásicos como Smith al confundir y mezclar el valor con el valor de uso.

Aparte de esta teoría del valor-trabajo de Marx, también aparece la teoría subjetiva del valor, que es la solución que acuña la escuela neoclásica. La teoría subjetiva del valor desarrolla la idea de que el valor de un bien no está determinado por ninguna propiedad inherente a este ni por la cantidad de trabajo requerido para producirlo, sino por la importancia que un individuo le da para lograr sus objetivos o deseos. La capacidad de un servicio o producto de satisfacer una necesidad.

Aunque el agua es una necesidad, las personas no querrán un suministro particular de agua si en su alrededor existen fuentes alternativas suficientes. Cuando existen pocas fuentes como en el desierto el valor de una cantidad particular de agua aumenta. Ésto, va evolucionando a finales del siglo XIX, donde aparece un concepto muy interesante que es el de la utilidad marginal, dentro de la teoría subjetiva del valor-verdad. La teoría de la utilidad marginal dice que el valor de un bien no está determinado por cuánto trabajo se ejercite en su producción - como la teoría del valor-trabajo - ni en la utilidad total, su precio es determinado por su utilidad marginal. Es decir, el primer vaso de agua cuando estamos sedientos nos resulta extremadamente útil, nos produce una enorme satisfacción o bienestar. Pero los sucesivos vasos nos aportarán un bienestar mucho menor y llegará a un nivel de consumo en el que nuestra utilidad total no seguirá aumentando aunque bebamos litros y litros. Se entiende por utilidad marginal de un determinado bien, el aumento o la disminución en la utilidad total que nos supone el hecho de consumir una unidad adicional del mismo. Entonces una mayor disponibilidad pues hará decrecer la utilidad marginal y viceversa. La escasez incrementará la utilidad marginal de un bien. En definitiva, la defensa del valor como algo objetivamente medible y asignable, prácticamente ha desaparecido.

Hoy el valor se reconoce claramente como subjetivo

En clase suelo preguntar “¿qué es el valor?” y hay muchas respuestas distintas. Pero al final, lo que define el valor, es ese valor subjetivo que nuestro cliente le da a lo que nosotros entregamos.

Otra reflexión que me interesa es la diferencia entre output y outcome.

Los outputs son los resultados de un proceso derivado de la aplicación de unos inputs a un sistema. Estos inputs procesados de una forma concreta, determinan ciertos outputs. Los outcomes son la consecución de unos resultados buscados y ligados a un objetivo de negocio. Ésto, es un matiz muy importante relacionándola con el tema del valor.

Un buen ejemplo, es la diferencia entre el número de líneas de código que teclea un programador y el valor real de un software. Me parece una reflexión muy interesante además de cultural. Hay organizaciones donde la cultura está enfocada a outputs y no los outcomes. 

A veces me encuentro con muchas compañías que están enfocadas a los outputs. No puedes ser ágil si tus procesos no están creados con una clara visión de orientación al cliente final porque eso es precisamente lo que es el valor.

No es ninguna sutileza ni es casual es que esté todo relacionado, es que la Customer Experience es la forma en la que tenemos que trabajar. Por lo tanto, necesitamos identificar qué es valor y sobre todo cuál es el flujo de creación de ese valor. En Lean tenemos (VSM el Value Stream Mapping), que es una técnica que se aplica a organizaciones industriales, a fábricas, a la creación de producto físico, no estamos hablando únicamente de software.

Value Stream Mapping

El VSM, el Value Stream Mapping, es un mapeo de todos los pasos tanto de valor agregado como sin valor agregado requeridos para llevar un producto desde su fase de materia prima hasta las manos del cliente.

El VSM se enfoca tanto en el material como en la información que es supercrítica, en cómo fluye la información y en cómo son esos procesos. Cuando mapeamos procesos nos damos cuenta de que son transversales al organigrama de la empresa, no siguen las relaciones clásicas departamentales, sino que afectan a varios departamentos o funciones a la vez. Es necesario dotar a la organización de una estructura de carácter horizontal siguiendo los procesos Inter funcionales y con una clara visión de orientación al cliente final. Ésto no significa necesariamente que se anulen las funciones tradicionales de los distintos departamentos, simplemente se trata de poner foco a las interrelaciones entre ellos.

Y ahí estamos de nuevo con la idea de la Cross funcionalidad, ¿verdad? Pero al fin y al cabo, son conceptos que se interrelacionan, es una discusión compleja y probablemente por eso cuesta que cale este discurso en algunos medios.

Volvamos de nuevo a esa idea inicial de entrega temprana y frecuente de valor porque ahí es donde yo creo que Agile es realmente rompedor.

Todas las metodologías ágiles están enfocadas a la entrega de valor. En el contexto de Agile, el valor se entiende como software funcionando, es decir, en el contexto de Agile un funcional no es valor. Valor es lo que es valor para el cliente final y el cliente final sólo puede valorar el software funcionando. Recordemos el séptimo principio del Manifesto: el software funcionando es la principal medida de progreso. Ni Gantt, ni una herramienta de pronóstico. Si decimos que estamos al 40 por ciento de lo que dijimos que íbamos a hacer, este 40 por ciento no tiene ningún valor, lo único que tiene valor es aquello que podemos poner en producción, aquello que podemos entregar, aquello que el usuario puede utilizar.

Scrum, habla de sprints, esos períodos frecuentes donde hay una entrega de valor de software funcionando. Típicamente sprints de dos semanas. En Kanban por ejemplo lo que se trabaja es un flujo constante de la entrega de valor. Ese valor se entiende de la misma manera. Si en scrum se trabaja con historias de usuario y en kanban no, no prescriben las historias de usuario, se puede trabajar con tareas directamente. El foco es esa entrega de valor, y entendiendo valor como algo testeable, como algo potencialmente publicable que el usuario puede usar y que, por lo tanto, podemos aprender de ese uso.

Imaginemos que tenemos que hacer un e-commerce. Podríamos tener por una parte, la ficha básica de producto donde encontraríamos su foto con una breve descripción. Esto sería la ficha básica de producto o incluso podría tener el precio. Podríamos tener una funcionalidad que fuese la valoración de ese producto, el review de ese producto, cuántas estrellitas tiene ese producto. Esa funcionalidad podría incorporar otra funcionalidad que sea la de votar y así sucesivamente podemos iterar esas funcionalidades, añadir complejidad en las mismas o incrementar la funcionalidad de esa ficha de producto.

De igual manera podríamos tener un listado de productos básico, el típico listado de productos. A lo mejor en la primera iteración sólo tenemos 15 productos, pero es posible que en otro nivel de madurez del proyecto tengamos 150 productos. Igual tendríamos que empezar a pensar en paginar o en filtrar o facetar y a partir de ahí vamos añadiendo funcionalidad de forma iterativa incremental.

A mí me gusta mucho ese slide de Henrik Kniberg que yo siempre pongo en todas mis presentaciones. De esta manera explico qué es iterativo incremental y qué no es iterativo incremental. Siempre ponía el seguiente ejemplo:

Si tú y tú tienes que satisfacer la necesidad de tu cliente de transporte, tu cliente tiene la necesidad de transportarse, por ejemplo, 10 kilómetros cada día para ir a trabajar.

Tienes la oportunidad en la primera iteración de entregarle una rueda a tu cliente y en la segunda de entregarle las cuatro ruedas unidas por sendos ejes y un cigüeñal. En la tercera iteración igual podrías entregarle esas cuatro ruedas con los dos ejes con el cigüeñal y con el chasis. En la cuarta le podrías añadir los asientos y en la quinta el motor y el volante y los pedales.

No es hasta la quinta iteración cuando estamos recibiendo valor, porque a mí no me sirve para nada. No me sirve tener cuatro ruedas con un chasis por muy protegido del frío que esté. Por muy bonito que sea el diseño del coche, no me sirve para nada cuando mi necesidad es poder transportarme e ir a trabajar a 10 kilómetros de mi casa en un vehículo.

En cada una de esas iteraciones yo te voy a entregar valor funcional.

La gracia de esto, es cómo hacemos para que un equipo multidisciplinar trabaje conjuntamente los UX, los UI designers, los backends, los frontends, la gente de contenidos, los copies, la gente de marketing...

¿Cómo hacemos para entregar valor de forma iterativa incremental cada dos semanas?

En Runroom, los equipos entregan valor a cliente en aquellos proyectos donde entregamos por Sprints al cliente. Entregan valor cada dos semanas pero nosotros , por ejemplo, tenemos sprints internos de revisión de review o de planificación de una semana. Al final, no se trata de seguir un libro, no se trata de coger el manual de Scrum y seguirlo a pies juntillas porque es que son 16 páginas. Los Scrum guides los podéis leer en media hora.

No se trata de eso, se trata de entender qué significa valor, cómo podemos organizar nuestra estructura formal e informal para poder optimizar precisamente ese flujo de creación de valor.

No sólo esos outputs sino también ese outocome final. 

¿Cuál es la ventaja de hacer entregas frecuentes y tempranas de valor?

Sin ser muy imaginativos, lo más obvio es que si hacemos así las cosas vamos a poder testear y recibir feedback constantemente.

Al empezar a testear una propuesta de valor, vemos si se entiende lo que estoy ofreciendo, si la gente está interesada en mi producto y lo compra o no lo compra desde la primera iteración. Además, podemos ser muy inteligentes y decir, oye, vamos a ordenar la entrega de valor en en la primera iteración, por lo que vamos a hacer primero lo que más valor aporta a nuestro cliente y vamos a dejar para iteraciones futuras aquello que menos valor le entrega. Entonces, de esta forma, podemos testear lo que es más importante, lo que más valor y más retorno de valor tiene para nosotros. Lo podemos testear muy pronto porque al final de cada iteración vamos a tener algo funcionando. Pero, por ejemplo, nosotros hemos hecho el lanzamiento de un producto industrial de venta de un producto de moda en cuatro sprints en dos meses. Hemos entregado un comercio donde el cliente ya podía comprar de punta a punta, podía entender cuál era el catálogo de producto, entrar dentro de una ficha de producto, comprar, pagar, hacer el check out y recibir ese producto en su casa.

1. Feedback constante
   Esto nos ha permitido ir integrando ese comercio haciendo test de usuario, incorporando el feedback del Call Center, de las llamadas, de atención al cliente, ir incorporándolo e ir diseñando ese producto maximizando el valor que entregábamos al cliente. Por lo tanto, la primera ventaja y la número 1 en la que yo pongo por encima de todo es el testeo y la recepción de feedback sobre lo que estamos haciendo. No esperamos al final a tener todo el ecommerce hecho para lanzarlo y ver si lo que hemos hecho tenía sentido o no tenía sentido.
    
2. Adaptación al cambio
   En definitiva, si le aportaba valor. La segunda ventaja que quiero destacar es que trabajando de esta forma iterativa incremental, enfocándonos en la entrega de valor iterativa incremental con entregas frecuentes y tempranas de valor, el cambio es bienvenido. ¿Por qué? Porque el cambio va a venir, va a estar mucho más controlado, va a ser mucho menos arriesgado, vamos a minimizar los costes del cambio precisamente porque vamos a poder testear cada uno de esos sprints, cada una de esas entregas de valor. Es muy raro que de repente tengamos que pivotar absolutamente todo y tengamos que tirar todo lo que hayamos hecho a la basura o que nos demos cuenta de que una decisión que tomamos seis meses atrás, no sirva para nada. Eso es lo más probable que te pase en un proyecto en cascada, que desde que empiezas a conceptualizarlo hasta que lo llevas al mercado no puedes validar, no puedes testear, no puedes recibir recibir ese feedback que comentábamos y por lo tanto hacer un cambio en un proyecto en cascada tan largo y tan tedioso, es una apuesta a un solo disparo, es carísimo porque tienes que volver a arrancar todo el proceso.
   Aquí el cambio es bienvenido porque realmente estamos dando pasitos poco a poco y vamos añadiendo valor a nuestra aplicación. De esta manera, los cambios que vayan a venir, van a ser sobre una parte pequeña de ese valor que hemos ido acumulando entregando de forma iterativa incremental.
    
3. Time to market
   Al final de cada iteración te voy a entregar software potencialmente publicable. Por lo tanto tiene que estar perfecto de cara al usuario, si se lo voy a publicar al usuario no tiene que tener bugs, no tiene que ser feo, tiene que ser sencillo, lo suficientemente sencillo para que aporte el máximo para maximizar esa entrega de valor, pero no quiere decir que vaya a ser feo o chungo o un boceto mal hecho.
   Imaginaros que queremos validar y lanzar un comercial pero no tenemos claro si el producto que estamos lanzando va a tener aceptación en el mercado. La estrategia más inteligente, desde mi punto de vista sería: “Oye vamos a empezar haciendo una landing page”,  una página de aterrizaje o que esa página de aterrizaje sea una plantilla en la que yo manualmente luego pueda subir distintos productos pero cada uno de ellos con una página. También voy a hacer campañas hipersegmentadas que me aterrizan en esa landing. Y en esa Landing lo único que voy a tener es la foto del producto, el texto que acompañe los key benefits del producto, el precio y poco más. Además de un Commenting System si quiere saber la importancia del feedback del usuario para poder definir mejor ese producto, el pricing, etc. Acceder a los features necesarios que te quepan en un sprint.
   Me refiero desde el punto de vista de tu de tu capacidad de producción, de tu capacidad de desarrollo, que eso dependerá de muchas cosas, dependerá del contexto tecnológico, dependerá del expertise de los miembros del equipo, de la cantidad de personas que haya, etcétera, de muchos parámetros.
   Si yo tengo una forma de validar que  el valor final que quiero entregar (mi producto), se va a entender, el usuario lo va a comprar. Yo voy sobre seguro. Yo voy con el rigor de saber que estoy disminuyendo los riesgos de la inversión y no sólo eso, sino que voy a tener la oportunidad de empezar a competir antes.
   Si es verdad, no tendré ni comer con todo lo que necesito, pero a lo mejor puedo suplirlo con mucha gestión manual, telefónica o con una plataforma externa de ayuda, lo que sea. Ahí entra la parte de la estrategia. Hay que entender bien el medio y saber por dónde empezar y hacia dónde ir. Por lo tanto las ventajas son: testear y recibir feedback constante. El cambio es bienvenido.
    
4. Reducir riesgos
   Para mí es la capacidad de disminuir riesgos sobre desarrollo. Muchas veces, si tú te planteas un proyecto en cascada un pleito ágil donde haces toda la definición funcional al principio, te equivocas.
   ¿Sabéis que el 60 por ciento de las funcionalidades de un software no se utilizan nunca? No se utilizan jamás. Nuestros usuarios no las van a utilizar. Muchas veces estamos haciendo sobredesarrollo, no estamos manteniendo la simplicidad al máximo y por tanto minimizando esos riesgos. Entonces, si yo desarrollo de una forma ágil, si yo entrego valor de una forma ágil iterativo incremental, puedo parar de invertir en cualquier momento si considero que he alcanzado suficiente retorno de valor. Puedo parar al cuarto sprint cuando ya tengo un e-commerce básico si me doy cuenta de que me puedo ahorrar añadir dos Sprints más para enriquecer la funcionalidad. Me ahorro lo que sea lo que cuesten tres o dos sprints.
   El problema de esto es engañoso, es falsamente falsamente explícito. Muchos clientes llegan a Runroom creyendo que saben exactamente lo que necesitan y muchas veces pensamos que nosotros sabemos lo que el cliente necesita. En la mayoría de esas ocasiones lo que me encuentro es que ni siquiera le hemos preguntado al cliente qué es lo que necesita. Ni siquiera hemos invertido tiempo en hacer entrevistas para descubrir insights de usuario, painpoints,  momentos de la verdad y entender bien su Journey para ver cómo podemos maximizar esa entrega de valor. 

En fin, queda mucho trabajo por hacer todavía. Decía al principio del episodio que me parece mentira que estamos a punto de llegar al 2020 y todavía me encuentro verdaderas aberraciones, verdaderos cadáveres en algunos proyectos hechos en cascada y no pensando en la entrega de valor.