¿Esta es la realidad en tu empresa? Sin dudas hay mucho para mejorar.

 db1b0b87-d8a5-4249-a5d7-c4721438b729-original
Coincido con @Mariela Machado sobre el cambio cultural.

Nuestra mirada desde la Agilidad y de Lean

Es que la cultura la afectamos indirectamente a través de cambios en el sistema organizacional, viendo la organización no solo como un sistema sino además como un flujo de valor hacia nuestros clientes y usuarios.
En concreto:
  • Conocemos y admitimos que las empresas del conocimiento estamos en contextos complejos y tratando con problemas complejos (ver marco Cynefin de Dave Snowden)
  • Por lo tanto entendemos que los enfoques de trabajo tradicionales basados en planes detallados, la división entre expertos y hacedores, mejores prácticas, manuales y “balas de plata” no aplican en estos contextos, aunque quizás sí apliquen para contextos simples o complicados (ver Cynefin)
  • Que en estos contextos complejos sólo funcionan las prácticas emergentes basadas en el trabajo colaborativo de equipos multidisciplinarios (perfiles “T” y no “I”) involucrados en el trabajo diario y muy importante involucrando a nuestros stakeholders, clientes y usuarios (ver T-shaped professionals, T-shaped skills)
  • Confiamos en nuestros equipos multidisciplinarios y autónomos y ellos a su vez trabajan con responsabilidad y transparencia (ver teoría X Y de McGregor, video de Drive por Daniel Pink, Las 5 disfunciones de los equipos de Patrick Lencioni, AgileHR)
  • A los equipos por lo tanto se les encarga resolver problemas de negocio de punta a punta y no implementar algo que unos expertos diseñaron sin su participación
  • El trabajo de esos equipos es realizado en ciclos cortos donde planteamos hipótesis y las probamos en base a prototipos, en forma iterativa e incremental, basados en que debemos aprender haciendo en ciclos experimentales rápidos (ver ciclo de Deming y el de aprendizaje validado de Eric Ries)
  • La mejor comunicación es la que se hace conversando cara-a-cara y los tableros físicos visuales (radiadores de información), por lo tanto los equipos deben estar trabajando juntos en un ambiente físico común
  • La mejor manera de colaborar y lograr visiones compartidas es interactuando juntos como equipo en un artefacto físico muy “low-tech” como un tablero en la pared o rotafolio con notas auto-adhesivas, cinta del pintor de colores, papel, fichas, marcadores
  • Cuando tenemos un gran desafío por delante lo hacemos en talleres interactivos facilitados (talleres de Incepción Ágil, Design Sprints, Mob-programming, Releases)
  • Buscamos la mejora continua de todo, del equipo (haciendo retrospectivas periódicas) y del producto (pidiendo feedback periódico a usuarios y clientes)
  • Todo esto está basado en valores y principios, por ejemplo: confianza, respeto, transparencia, apertura, planes “justo a tiempo” aprendiendo del contexto hasta el “último momento responsable”, buscar la simplicidad y la calidad, la búsqueda de la mejora continua, individuos e interacciones sobre procesos y herramientas (ver Agile Manifesto y Lean Thinking)
  • Basado en el contexto
Por lo tanto, en mi opinión, la pila de papeles de la foto sobre el escritorio es un síntoma de otros problemas que tocan seguramente más de uno de los puntos señalados, por ejemplo: organización de procesos en silos y fases y personas haciéndose sólo responsable de su parte sin ver el todo, el avance del trabajo se basa en ver en qué paso del proceso está el documento y no en el valor entregado al cliente, poca e ineficiente comunicación, procesos basados en políticas viejas que nadie revisa y actualiza, etcétera.

¿Primeros paso para mejorar?

Que la organización como un todo sea consciente de la necesidad de un cambio y que además deseen y se involucren en ese cambio (ver modelo de cambio ADKAR).
Entendemos además que todo lo anterior forma parte de la innovación de la gestión (Management Innovation) y que involucra la innovación de productos.

 

Perdón por lo largo de mi respuesta.
¡Gracias @Daniel por plantearlo e invitar abiertamente a participar!
Anuncios

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

Poster “Agile Product Ownership”

Hace pocos días encontré el Poster “Agile Product Ownership” de Mia Kolmodin y me pareció muy bueno y digno de compartir, así que decidí escribirle para ofrecerle hacer la traducción  al español.

No pretende ser una traducción ortodoxa sino más bien útil y enmarcada dentro del contexto de la comunidad ágil de Latinoamérica, en la que me muevo desde hace algún tiempo. Así que me tomé ciertas libertades al dejar en inglés algunas frases o palabras como el título.

Aquí les dejo el enlace al post de Mia en el blog de Dandy People donde pueden descargarlo libremente: https://dandypeople.com/blog/translated-to-spanish-agile-product-ownership-in-a-nutshell-poster/

Hay mucha información en el poster, no solo para los Product Owners y/o Product Managers sino para todo el equipo de desarrollo de productos.

¡Espero que les sea de utilidad y que lo difundan!

Descarga el Poster en español aquí.

Pablo Lischinsky
@pablolis

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.

Un Checklist latino para Product Owners

¿Qué tiene que saber, ser y tener un Product Owner para ser “ideal”?

 

User Story Mapping
User Story Mapping

Introducción

Existen varias interpretaciones para el rol “Product Owner” de Scrum, definido de forma oficial en la Guía de Scrum.

Este “Checklist latino” pretende ser una herramienta útil para que tanto Product Owner’s como Scrum Masters y personas del negocio puedan analizar en qué aspectos están suficientemente bien y en qué aspectos podrían mejorar, de forma tal de ser cada vez mejores en su oficio o rol. ¿Cuál es mi norte como Product Owner (PO)?

Existen variaciones del rol de PO en función de diversas circunstancias:

  • Madurez del equipo en cuanto a su recorrido en agilidad (ver Shu-Ha-Ri).
  • Tipo de producto (para clientes internos (IT), producto digital masivo (Ej. Trello))
  • Segmento vertical: games, banking, empresa centrada en producto(s).
  • Momento dentro del Ciclo de Vida del Producto (no es lo mismo antes de validar Product/Market fit que durante crecimiento, madurez o declive).
  • La complejidad del producto (productos muy complejos pueden requerir de un equipo que cumpla el rol de PO en lugar de una persona).

Responsabilidades

  • Comprensión: de la necesidad y el valor del negocio. Business skills.
  • Tener el norte claro: descubrir, clarificar y comunicar la Visión.
  • Construir, validar (con los interesados), comunicar y actualizar periódicamente el Roadmap (hoja de ruta, plan de entregas).
  • Análisis de Información: saber identificar diferentes niveles o jerarquías de información, categorizar, dividir (hacer slicing), reunir, generalizar, especializar.
  • Priorización – Decir que no.
  • Tener foco en el Retorno de Inversión centrado en los objetivos de negocio.
  • Dar ejemplos concretos que ilustren y permitan entender mejor.
  • Irradiar información: saber llevar de una manera asertiva la información del negocio hacia el equipo. Todo el equipo debe tener claro el problema o visión del producto.
  • Validación: es responsable de la validación del producto recibido.
  • Indagar, preguntar acertadamente (preguntas abiertas o cerradas según corresponda en cada momento).
  • Organizar y facilitar las reuniones de Refinamiento del Product Backlog, Planificación del Sprint y Revisión del Sprint.
  • Asistir a la Retrospectiva del Sprint. Dependiendo de la madurez del equipo de desarrollo y del equipo de Scrum, a veces se recomienda realizar una Retrospectiva interna para el Equipo de Desarrollo para tratar temas más técnicos y de gestión propia del equipo y otra reunión de Retrospectiva en la cual participen todos: Scrum Master, Equipo de Desarrollo y Product Owner.
  • Muy recomendado: Asistir a la Reunión Diaria.
  • Obtener feedback y dar visibilidad del impacto al cliente en cada iteración.
  • Mantener el Backlog actualizado (refinamiento adecuado, priorizado).
  • Fomentar la sinergia entre el Scrum Master y el Equipo de Desarrollo, en pro del crecimiento en conjunto del Equipo de Scrum.
  • Si corresponde, coordinarse con los demás Product Owners de un producto o negocio.
  • Prestar atención y foco a que las decisiones de diseño (UX – user experience) se hagan en acuerdo con diseño de la arquitectura.
  • Constante presencia y colaboración con el equipo de desarrollo. Si es posible, que trabajen físicamente juntos.
  • Colaborar en la evolución de la madurez del equipo (ver Tuckman-Lencioni).

Habilidades

  • Pasión por el problema que estamos queriendo resolver y el descubrimiento del producto ajustado para resolverlo.
  • Capacidad de escucha.
  • Negociación.
  • Ser un líder y referencia dentro de la organización sobre la visión y el rumbo del producto.
  • Comunicación efectiva y eficiente.
  • Conocer el contexto de negocio (competencia, tendencias).
  • Empatía con los clientes, el equipo, el scrum master, los interesados, el negocio.
  • Motivar a que todos los involucrados estén emocionados por construir el producto.
  • Interactuar con toda la comunidad que debe estar presente a la hora de definir detalles y cuestiones macro del producto en construcción. Ejemplos: Product Management, Estrategia, Marketing/ventas.
  • Manejo excelente de su tiempo.
  • Facilitación. Para situaciones en las cuales se requiere que un grupo de personas se pongan de acuerdo o lleguen a una definición de prioridades o un detalle de características.
  • Buen relacionamiento. Mucho más importante que tener todas las respuestas, es tener la habilidad de saber “dónde” encontrarlas.

Técnicas, prácticas, metodologías  que debería conocer y manejar

  • Agile Manifesto: Valores y Principios.
  • Scrum
  • Lean Startup.
  • Design Thinking.
  • Agile inception.
  • User Story Mapping.
  • Impact Mapping.
  • Facilitación de espacios participativos.
  • Definición y división de Historias de Usuario.
  • Diversas técnicas de Priorización.
  • Definición de MVP (Producto Mínimo Viable).
  • Conceptos de Desarrollo ágil, iterativo e incremental de software con el objetivo de ir descubriendo el valor de negocio.
  • Elevator Pitch.
  • HDD (Hypothesis Driven Design / Development).
  • Realizar experimentos – Canvas de Experimentos.
  • Métricas/Analytics.
  • UX (experiencia de usuario).
  • Prototyping.
  • Time boxing – Pomodoro.

Artefactos / Herramientas

  • Story Map.
  • Product Backlog.
  • Product Vision Board.
  • Impact Map.
  • Kanban board.
  • Métricas y gráficas de rendimiento.

Acerca de este documento

Este documento fue ideado por integrantes de la Comunidad Latinoamericana de Metodologías Ágiles.

Quienes participaron en la creación del mismo fueron:

Alejandro Posada (Colombia), Giovanny Cifuentes (Colombia), Guillermo Alvarado (Colombia), Marcela Barrera, (Colombia), Pablo Tortorella (Argentina), Pablo Lischinsky (Uruguay), Rox Muñoz (México).

Colaboradores que aportaron con su lectura y comentarios oportunosTommy Christie (Argentina), Roberto Mejías (Chile).

¿Comentarios? Los invitamos a leerlo y agregar sus sugerencias en el documento compartido: https://docs.google.com/document/d/1_xa8xZYg3FTGH7ONhMYFIJLu3PDg6ncc9D3XYSIXBCQ/edit#heading=h.1rh3pipkg4by