Lean Enterprise: el modelo que buscan las grandes empresas

Imagen: Constanza Molinari, @coti_mol

Por: Martín Salías y Pablo Lischinsky

Este paradigma de innovación en productos y servicios para grandes empresas (las llamadas enterprises) tiene su origen en Lean Thinking (originario del Toyota Production System) y en el boom de las Startups disruptivas que comenzaron a causar inquietud en los grandes jugadores de la industria, no solamente porque les quitan mercado, a veces tímida y a veces drásticamente, sino porque no logran reaccionar a tiempo, a pesar de sus enormes recursos económicos y red de colaboradores.

¿Qué es Lean Startup?

Este movimiento emprendedor surgió tras el dramático ascenso y caída de la llamada “Burbuja punto com”, alrededor de principios de los 2000, cuando la web se masificó con altas y bajas en los albores del comercio electrónico. Antes de que explotara esa “burbuja” especulativa entre 2001 y 2002, muchos de los nuevos emprendedores trataban de conseguir capital en base a una idea innovadora y algunas proyecciones de mercado.

Muchos capitalistas de riesgo, alimentados por las historias de algunos de los primeros éxitos de la era de Internet, no dudaron en invertir grandes fortunas en esas ideas. Y los emprendedores se apuraron a cerrar trato, quedándose usualmente con un mínimo porcentaje por su idea original, con algo más a recibir en función del éxito de su ejecución.

Como sabemos, la mayoría de esos emprendimientos fracasaron, y el modelo de invertir en ideas y planes de negocio sin desarrollo prácticamente se esfumó.

De esos aprendizajes y de toda la corriente de enfoques ágiles y Lean, surgió un nuevo estilo de emprendedores, de los que Eric Ries aprendió y recopiló las mejores ideas en su libro “The Lean Startup“ (2011). Allí propone convertir esas ideas innovadoras en hipótesis de negocio y validarlas de la manera más rápida y económica posible, cambiando el foco por cada factor que no logramos comprobar, hasta encontrar una ajuste entre un mercado existente y una necesidad que deseamos cubrir con nuestro producto. Esa manera de emprender a muy bajo costo tiene el objetivo de no requerir inversión externa hasta que el negocio funciona, y diferir (si realmente hace falta) el ingreso de inversores hasta el momento en que ellos se acercan al emprendedor, y no al revés. El objetivo es claro: descubrir y poner en operación nuevos modelos (quizás disruptivos) de negocio y rápidamente descartar aquellos que no funcionan.

¿Por qué no funciona ese modelo en una corporación?

Tras ver de cerca muchos intentos fallidos de replicar esa manera de innovar en grandes empresas, Jez Humble, Joanne Molesky y Barry O’Reilly escribieron “The Lean Enterprise” (2015) donde describen como uno de los principales problemas de las grandes empresas su abundancia de recursos.

En el mundo emprendedor el presupuesto es escaso o nulo, y el grupo inicial es mínimo: usualmente entre una y tres personas. En esas condiciones, la creatividad está impulsada por el hambre. No hay chance de hacer apuestas muy fuertes y el tiempo es escaso.

Nosotros mismos hemos visto en muchísimas ocasiones a grandes empresas caer en la trampa de crear “Laboratorios de Innovación”, con amplios equipos de especialistas, oficinas especiales, presupuestos y hasta planes detallados de sus proyectos.

¿Por qué les cuesta tanto?

Las compañías que crecieron y desarrollaron su modelo de negocio sobre una serie de productos o servicios exitosos que siguen generando grandes ingresos (incluso si están sometidas a gran competencia), usualmente han generado una cultura interna que refuerza el mantenimiento de una situación estable necesaria para explotar su modelo de negocio, es decir, operar y maximizar el rendimiento a largo plazo.

Esa mentalidad es usualmente contraria a la de un emprendedor con un enfoque de exploración, quien puede tolerar un alto nivel de riesgo, porque todavía no tiene nada (o muy poco) por perder. Cuando un negocio está en estado embrionario la única manera de desarrollarlo es mutando permanentemente el entorno, mientras que un negocio sólido y estable requiere una dirección que minimice el efecto de los cambios externos.

Esas dos mentalidades de explotación y exploración son antagónicas y requeridas para cada uno de esos dos modelos, desde el liderazgo hasta los equipos que ejecutan. Sumado a eso, el tamaño de la organización es inversamente proporcional a la velocidad para reconvertirse de manera orgánica.

Otra razón que hace difícil la puesta en marcha de este enfoque en grandes corporaciones es el amplio uso de trabajos basado en grandes proyectos y sus enfoques pesados y tradicionales de gestión. Cuando se desarrolla un proyecto basado en planes (que se desarrollan todos al comienzo, cuando el riesgo es máximo) se tiende a sobreestimar los beneficios, subestimar los costos y medir el éxito sujeto a la ejecución a tiempo y dentro del presupuesto más que en resultados de negocio.

Los enfoques de exploración e innovación que impulsa Lean Enterprise, desarrollan el trabajo con equipos multifuncionales, autónomos y de pocas personas, en ciclos cortos y rápidos, iterativos e incrementales, buscando feedback frecuente y directo de los usuarios: lo importante es aprender del mercado lo más rápido posible, desechar rápidamente ideas que no funcionan. Esto sólo es posible en una cultura que apoya este modo de trabajar, donde la experimentación (y por lo tanto fallar), el aprendizaje y la colaboración son esenciales. Ver algunos casos de éxitos en el reporte 2016 del SD Learning Consortium.

Enlaces

Anuncios

Product Owners que potencian las Transformaciones Digitales

Por Pablo Lischinsky @pablolis y Ricardo Colusso @rcolusso

El Framework Scrum promueve el rol de “Product Owner” (PO) y si bien su concepción y descripción original no ha evolucionado mucho, el contexto actual de las empresas y de las transformaciones digitales sí ha cambiado las exigencias sobre este importante rol. En este trabajo cuestionamos el rol del PO y proponemos algunas opciones para potenciar sus destrezas. Gestionar el product backlog ya no es suficiente para maximizar el ROI.

Transformarse o quedar atrás

Las grandes empresas que tienen en su núcleo de negocio servicios digitales se enfrentan a nuevas startups con propuestas disruptivas que amenazan sus modelos de negocio. Además, los consumidores tienen nuevas demandas y es un desafío adaptarse y mantenerse vigente, con el riesgo de quedarse atrás de la competencia y perder clientes.

Tradicionalmente el Product Owner (PO) dentro de un equipo Scrum se ocupa de la gestión del backlog de cara a los stakeholders y el equipo de desarrollo, buscando siempre maximizar el retorno de inversión (ROI).

El trabajo del PO “tradicional” se centra entonces en hacer bien el producto relevado o demandado ayudando al equipo a entregar el mayor valor posible en cada iteración. Sin embargo, por diversas razones las transformaciones digitales presentan desafíos que no pueden superarse trabajando de esa manera, entre ellas:

  1. Los productos a desarrollar tienen un alto contenido de discovery: pretenden dar respuesta a problemas inéditos para los cuales no hay soluciones efectivas conocidas.
  2. Requieren descubrir y diseñar en forma colaborativa, emergente, iterativa e incremental un producto que sea de valor para el negocio, de alta usabilidad (UX) y técnicamente factible.
  3. Existen dependencias entre diferentes áreas de la organización que se convierten en impedimentos duros o provocan retrasos.
  4. Los stakeholders impactados por el producto suelen tener amplios desacuerdos en sus intereses y presentar contradicciones al momento de plantear sus necesidades.
  5. Existen otros roles dentro de las empresas que se solapan con el rol de PO: Product Manager, CEO, Director, Marketing y Ventas, con visiones del negocio no siempre holísticas o sistémicas.
  6. En los niveles directivos se presentan sesgos cognitivos sobre la dirección del producto a desarrollar, con imposición de visiones no validadas y micro-management.
  7. El contexto organizacional puede dificultar la colaboración y la co-creación entre stakeholders claves y el equipo de desarrollo.

Es por esto que las Transformaciones Digitales requieren que los POs adquieran nuevas habilidades para que desde su rol colaboren en el logro de los objetivos de negocio esperados.

No se trata ya de crear un producto correctamente sino también de hacer el producto correcto. Construir eficientemente el producto equivocado es un enorme desperdicio.

Habilidades de los Product Owners para las Transformaciones Digitales

Buscamos que los Product Owners que trabajan en el contexto de Transformaciones Digitales adquieran nuevas habilidades estratégicas, de facilitación y trabajo en equipo y nuevas técnicas y herramientas.

Habilidades Estratégicas

  • Un PO con un enfoque más centrado en la estrategia de negocio/producto y el valor entregado a los stakeholders que en la táctica de desarrollo del mismo.
  • Un PO más consciente de que puede estar enfrentándose a contextos complejos o de problemas desconocidos y soluciones desconocidas, para los cuales lo más sensato es trabajar en ciclos de aprendizaje y validación de hipótesis haciendo experimentos basados en prototipos.
  • Conocimiento del ciclo de vida de productos, tipos de modelos de negocio, sus riesgos y su impacto en desarrollo de productos.
  • No sólo usar métricas de proceso sino además métricas cuantitativas y cualitativas de negocio para medir el impacto real y poder validar la estrategia usada.

Habilidades para la facilitación y trabajo en equipo

  • Los productos que son el resultado de la co-creación entre personas técnicas y del negocio, en ambientes facilitados por Product Owners que estimulan el entendimiento sistémico de la empresa, la negociación, la innovación, la experimentación y el aprendizaje (Discovery).
  • Facilitar conversaciones y talleres efectivos para lograr una visión y estrategia compartida de producto con los stakeholders clave y el equipo de desarrollo.
  • Un PO con un enfoque más cercano a un líder al servicio de la comunidad del producto que de un “dueño” de la verdad.
  • Confianza en el equipo de desarrollo al apoyar sus iniciativas técnicas de refactoring, automatización de pruebas, spikes, pair programming y todo lo que decidan para mantener gestionada la deuda técnica del producto y ayudarlo a hacer visible a la gerencia/directorio sobre estas prácticas y su necesidad para mantener el código de alta calidad y adaptable.
  • Ayudar activamente a construir un excelente ambiente de trabajo donde el equipo pueda crecer en todos los aspectos.

Conocimiento y uso de nuevas técnicas y herramientas

  • Nuevos enfoques para apoyar y lograr mecanismos de desarrollo evolutivo e incremental incluyendo los procesos de discovery y desarrollo experimental (Design Thinking, Prototyping, Lean Startup, Lean UX, Analytics y desarrollo ágil de software).
  • Herramientas de priorización del backlog utilizando conceptos de valor de negocio, costos de oportunidad y otros.

Conclusión

En el complejo y cambiante contexto global empresarial de hoy los Product Owners no pueden limitarse a gestionar el backlog, deben desarrollar habilidades estratégicas, habilidades de facilitación y conocimiento en nuevas técnicas para maximizar el ROI de sus productos. Los POs avanzados que cuenten con esas habilidades tendrán un rol muy importante en el liderazgo y desarrollo de productos digitales de valor.

Valor de Negocio

De qué hablamos cuando hablamos de Valor.

Valor por Henrick Kniberg
Maximize Value, no Output, Henrik Kniberg, http://blog.crisp.se/wp-content/uploads/2014/03/unproject.pdf

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) y 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 (Weighted Shortest Job First): 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.

 

img_4880

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, 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.

Lean Startup en Meetup AgileUy

El Meetup de AgileUy del pasado martes 28 de Abril en Montevideo fue dedicado al tema “Lean Startup”, como preparativo al próximo Taller Lean Startup Machine en Montevideo.

Tuve a mi cargo la charla inicial que titulé Emprendiendo ágilmente con Lean Startup. Luego se presentó nuestro amigo Ariel Erlijman dando detalles del evento. sigue leyendo

Desayuno de trabajo sobre Metodologías Ágiles en la CUTI

Ayer 29/4/2014 estuvimos Gabriel Ledesma, Matín Mari, Sebastián Martínez y mi persona en un “Desayuno de Trabajo” organizado por la CUTI, dedicado especialmente a Metodologías Ágiles.

La agenda fue:

  • ¿Metodologías Ágiles como Agente de Cambio? por Gabriel Ledesma
  • Emprendimientos con Lean Startup por Pablo Lischinsky
  • UruIT: ¿Cómo formulamos contratos compatibles con Agile? por Martín Mari
  • WyeWorks: ¿Es posible entregar valor al cliente cada 15 días? ¿Qué técnicas y prácticas debo usar? por Sebastián Martínez

sigue leyendo