estrategia flexible y adaptativa

Agile Product Management
¿Qué es?

Las necesidades y los deseos del cliente cambian, a menudo rápidamente. Nuevos competidores llegan al mercado con ofertas diferentes o mejoradas. Se introducen nuevas tecnologías y plataformas que luego evolucionan. La única constante es el cambio. Las empresas con productos exitosos no solo aceptan esto, sino que lo incorporan al ADN de la empresa. Es necesario adoptar estrategias flexibles y adaptativas. En este contexto Agile Product Management nos aporta diversas soluciones, en función de las necesidades.

¿Para qué Agile Product Management?

Las prácticas y métodos propuestos por Agile incorporan una serie de beneficios probados:

Mayor satisfacción del cliente

Mejora en el control de costes y mayor aprovechamiento del presupuesto

Incremento de la productividad y creatividad

Reducción del time-to-market

U

Mejora de la visibilidad y transparencia del desarrollo de producto.

Z

Mejora de la motivación y compromiso de los equipos

Modelos tradicionales vs agile

Comparando los modelos tradicionales de gestión del Portfolio con un enfoque Agile, tomando como referencia Scrum, encontramos algunas diferencias reseñables:

MODELO TRADICIONAL

AGILE PRODUCT MANAGEMENT

Varios roles comparten las decisiones sobre el producto (product manager, project manager, …) Una persona, el Product Owner, es responsable del producto y lidera el proyecto
Los Product Managers están separados de los equipos de desarrollo, separados por los límites del proceso, el departamento o las instalaciones El Product Owner es miembro del equipo Scrum, y trabaja junto con el Scrum Master y el equipo de desarrollo de manera contínua
Se realiza un trabajo previo exhaustivo sobre investigación de mercado, análisis del negocio, y planificación del producto Se invierte lo esencial en un trabajo inicial para crear una visión clara. Se lanza al mercado pronto una primera versión que permita aprender sobre el terreno real y tomar mejores decisiones
Definición y descubrimientos del producto por adelantado: los requisitos se detallan y se congelan al inicio El descubrimiento del producto es un proceso continuo. Los requisitos surgen. No hay una fase de definición ni especificación de requisitos del producto. Las capacidades del producto evolucionan en función del feedback de los clientes y usuarios
El feedback de los clientes se recibe al final, tras el lanzamiento y cuando el producto ya está en el mercado, apenas sin margen para el cambio Los lanzamientos tempranos y frecuentes, junto con las sesiones de revisión con clientes y usuarios, nos proporcionan feedback temprano con el que aumentar el éxito del producto

Agile Product Management: Claves

Agile Portfolio Management se basa en los valores y principios del Agile Manifesto. Adopta gran parte de su filosofía, para permitirnos disponer de un Portfolio flexible y adaptable a las necesidades del negocio y el cliente:

Valor para el cliente/usuario

Una parte de incorporar al cliente es comprender cuál es su experiencia completa con el producto. Es importante la comprensión de inicio a fin del flujo de valor desde el punto de vista del cliente. Agile Product Management implica diseñar soluciones para tus clientes y no solo crear software.

Detección de necesidades

Las necesidades y los deseos potenciales de los clientes deben dirigir las decisiones de Product Management. Se trabaja estrechamente con los clientes existentes, invirtiendo tiempo para identificar y comprender a los clientes potenciales, y así ampliar cuota de mercados.

Escuchar al cliente/usuario

Proporciona a los clientes pequeños incrementos de tu producto con mayor frecuencia. Reduce el ciclo de retroalimentación con tus clientes y aprende rápidamente. Conseguirás reaccionar más rápido a las necesidades del cliente y del mercado.

Enfoque incremental

Las personas, en ocasiones, no sabemos lo que queremos, o tendremos dificultades para describirlo. Es posible que nos resulte más fácil explicar lo que no queremos que lo que sí queremos, y podremos cambiar de opinión en cualquier momento. El enfoque experimental unido a la creación de productos viables mínimos (MVP) nos permite obtener algo tangible que validar frente a los clientes potenciales y determinar lo que quieren: observando las características de su MVP, qué usan, cómo lo usan y las funciones que no usan. Esta estrategia fue popularizada por Eric Ries a través de su trabajo The Lean Startup, y ensambla perfectamente con Scrum como marco básico de trabajo.

Planificación

Los productos se planifican estratégicamente a largo plazo y se implementan tácticamente a corto plazo. Con una estrategia de Agile Product Management apostamos por diseñar un camino que nos indique una dirección y concentrar todas nuestras fuerzas en implementar el corto plazo. Con lo que aprendamos llegando pronto al mercado, actualizaremos nuestra dirección cuando sea necesario. Hablamos, por tanto, de una planificación viva, que cambia y lo hace para aprovechar todas y cada una de las oportunidades que aparezcan durante el ciclo de vida de nuestro producto. En Scrum, por ejemplo, la planificación de corto, medio y largo plazo queda estructurada en el Product Backlog.

¿QUÉ PODEMOS HACER POR TI?

En Enciende la Luz somos expertos en la puesta en marcha de sesiones y herramientas, para crear una estraegia y roadmap de portfolio a partir de la visión de la compañía, y en la creación y puesta en marcha de equipos de trabajo con filosofía Agile y Lean. ¿Qué significa disponer de un Agile Portfolio Management?

Espacios de colaboración, entre todas las áreas involucradas en una iniciativa. Participativos, efectivos y eficaces, dónde generarán la estrategia general, establecerán los objetivos principales, y crearán un roadmap de alto nivel de la iniciativa.

Espacios de colaboración, dónde convertirán el roadmap de alto nivel, en un roadmap más detallado, que atenderá a las necesidades de todas las áreas involucradas. Orientado a la entregado temprada de producto a los clientes.

Una priorización conjunta y global, atendiendo a las necesidades de la compañía, que nos permitirá reducir el time-to-market para la puesta en marcha de las primeras versiones del prodcuto.

Creación de equipos de trabajo, bajo las premisas de Agile y/o Lean.

Obtención de feedback temprano de los clientes, que nos permitirá adapta nuestra visión a la realidad de nuestros clientes.

Sabiendo que puedes obtener estos resultados, ¿qué hemos hecho en otros clientes para conseguirlo?:

Estandarizar el uso de la Agile Inception como espacio colaborativo entre las áreas de negocio y de tecnología, para toda nueva iniciativa de la compañía.

Aplicar el método User Story Mapping para construir un plan de MVPs.

Crear y estandarizar una sesión periódica de priorización conjunta del portfolio entre las áreas de negocio y de tecnología.

Formar a las áreas de negocio y de tecnología en las herramientas y métodos de construcción del Agile Portfolio.

Poner en marcha un sistema Kanban para la gestión del Agile Portfolio. 

Poner en marcha y acompañar a Equipos Scrum.

Fomentar y apoyar en la recogida de feedback de los clientes internos y externos.

Tanto si quieres montar equipos nuevos como si crees que tus equipos aún pueden dar más de sí y no sabéis cómo, ¡pregúntanos sin compromiso!

Agile Inception

Agile Inception es un método participativo de conceptualización de productos. Está ampliamente extendido en el mundo Agile por sus magníficos resultados. También conocido como Inception Deck, esta técnica data del año 2010. Su autor, Jonathan Rasmusson, la describe en su libro The Agile Samurai.

Hay profesionales que utilizan la Agile Inception como una única sesión de trabajo. Nosotros preferimos verlo como un proceso completo de conceptualización que nos permite ir desde una idea primigenia hasta una propuesta aterrizada en un plan de entregas con validación temprana de hipótesis de negocio.

Consiste en una serie de pasos que se mueven en 2 ámbitos diferenciados:

Dominio del problema

Clarificar el propósito ¿Qué nos ha traído hasta aquí?

Encuadrar nuestro producto a través de la técnica Elevator Pitch

Profundizar en la principales ideas y segmentar las secundarias

Identificar los límites del producto ¿Que sabemos que no va ser parte de nuestro producto? ¿Qué elementos aún están en duda?

Entender cuáles serán nuestros Stakeholders y qué necesita cada uno de ellos

Dominio de la solución

Identificar potenciales riesgos y definir políticas de gestión de riesgos.

Acordar qué elementos son negociables y cuáles no. ¿Qué pasará cuando la realidad pase por encima de nuestro plan inicial? ¿Qué factores tendremos en cuenta para tomar decisiones? ¿Cuáles de ellos son negociables y cuáles no?

Realizar una estimación de muy alto nivel de los costes y plazos que manejamos para el proyecto. ¿Qué equipo necesitamos? ¿Qué hitos relevantes necesitamos marcar como referencia? ¿Hablamos de semanas, meses o años?

User story mapping

Se trata de una técnica propuesta por Jeff Patton en su libro User Story Mapping.

Trata de ampliar la información que manejamos de un producto, a través de la creación de nuevas dimensiones. Mezcla algunos conceptos clave como Customer Journey, Iterativo e Incremental, Customer Centric, etc. Constituye una magnífica herramienta para obtener una visión global de las capacidades del producto, un detalle de los elementos que queremos abortar en el corto plazo, y un plan de entregas. Podemos utilizarla como complemento de la Agile Inception, o de manera independiente.

Consiste en un proceso de conceptualización de productos y proyectos que basa su éxito en 4 pilares básicos:

w

Colaboración entre grupos de interés

Responsabilidad compartida y solidaria

A

Rápida toma de decisiones

l

Definición del problema y del modelo de solución

Realizando una sesión de User Story Mapping podemos reducir los primeros 3-4 meses del desarrollo de producto a un proceso de entre 2 y 4 semanas. Nos permite reducir costes, alinear a los grupos de interés y alcanzar acuerdos base sobre los que seguiremos tomando decisiones según avance el proyecto.

Agile Portfolio Management 

La utilización del Portfolio nos permite tener una visión en el largo plazo, nos da un contexto en el que tomar decisiones en el corto plazo y tener la seguridad de que aquello que estamos realizando nos compensa el esfuerzo necesario.

El entendimiento del largo plazo ayuda a los equipos Agile a tomar decisiones con más información sobre el desarrollo del producto en corto y medio plazo. El Portfolio Management tiene la responsabilidad principal de asegurar que la dirección estratégica representada en el portfolio está alineada con el modelo y la estrategia del negocio. Esto requiere un claro entendimiento y comunicación de la visión contenida en el portfolio.

Visión del portfolio

En su libro Switch, Dan y Chip Heath nos proponen hacernos algunas preguntas, para ayudarnos a definir esa visión de futuro en el portfolio:

}

Largo Plazo (práctico)

¿Cómo resuelven los grandes problemas de los clientes/usuarios, las soluciones futuras contenidas en nuestro portfolio?

¿Cómo nos diferencian de los competidores esas soluciones?

¿Cuál es el contexto futuro que se encontrarán esas soluciones?

¿Cuál es nuestro contexto de negocio actual, y cómo debemos evolucionar para alcanzar el contexto futuro?

Visión del Futuro (aspiracional)

Aspiracional, a la vez que realista y alcanzable

Suficientemente motivador para que otros quieran unirse por el camino

Resultado: Todos comienzan a pensar sobre como sumar sus capacidades para conseguir llegar hasta allí.

Resumiendo, la visión del Portfolio debe tener las características siguientes:

Aspiracional, realista y alcanzable

Convincente y con visión del futuro, pero suficientemente práctico como para ser factible durante un periodo de tiempo significativo.

Motivador

Alineado con el modelo y estrategia de negocio

Transparente y conocido por los equipos, fomentando el compromiso y la creatividad para obtener los mejores resultados.

Conectar el portfolio con el mercado

Una de las claves de un Agile Portfolio es su capacidad constante de adaptación a la realidad que emana tanto del mercado como de los equipos Agile. El trabajo y las entregas tempranas de los equipos Agile nos dan información muy valiosa sobre cómo funcionan nuestros productos cuando se ponen en manos de nuestros clientes. Podemos ignorar esa información o aprovecharla en nuestro beneficio. 

Cuando diseñamos un Portfolio de proyectos utilizamos la información actual, lo que sabemos hoy. ¿Te imaginas qué potencia podría adquirir si, cada cierto tiempo, pudieras revisarlo e incluir lo que sabrás dentro de 2 ó 3 meses?

Existen múltiples maneras de estructurar un Agile Portfolio. Por ejemplo, con Kanban puedes descubrir cómo orientar de manera óptima todos tus recursos para reducir el tiempo que tardas en llevar soluciones a las manos de tus clientes. Algunos marcos de escalado Agile, como SAFe (Scaled Agile Framework for Enterprises), Scrum Nexus o LESS también incluyen su propia gestión de portfolio y su conexión con los equipos ágiles.

Priorización

En nuestro producto tendremos siempre características que son imprescindibles, otras que podrían estar y algunas que de momento no vamos a desarrollar. A partir de esta clasificación, podemos priorizar nuestro Portfolio. 

MoSCoW es una técnica definida por Dai Clegg en su libro Case Method Fast-Track: A RAD Approach. Es ampliamente utilizada para realizar una primera priorización de alto nivel. Permite, de manera razonablemente rápida y barata, hacer una segmentación de las características del producto. La clave no está en seguir este orden de manera estricta, sino en utilizar esta segmentación de manera equilibrada.

MoSCoW es un acrónimo, que identifica:

M - Must have

Son los elementos imprescindibles. Los colocaremos como los más prioritarios. Sin ellos nuestro producto carece de una identidad clara. Son elementos que probablemente no generen una especial satisfacción cuando estén presentes pero que sí generen un alto grado de insatisfacción si no lo están.

S - Should have

Son elementos importantes para el producto y que deberían estar presentes. Sin embargo, ante una causa justificada, podríamos prescindir de ellos. Se trata, principalmente, de elementos que generan satisfacción cuando están presentes y que pueden generar insatisfacción si no lo están. Los colocaremos a continuación de los prioritarios.

C - Could have

Son elementos deseables. Hablamos, por ejemplo, de características que ofrecen un alto nivel de satisfacción si están presentes pero que no generen insatisfacción si no lo están. Se desarrollarán si no hay elementos más prioritarios. 

W - Won’t have

Son elementos que no vamos a abordar por el momento. Los reservaremos para el final por si pudieran abordarse más adelante.

Algunos de los criterios que podemos utilizar para priorizar con MoSCoW, son:

Mercado

competidores

cliente/ usuario

tecnología

estrategia

¡conócenos sin compromiso!

Hazlo antes que tus competidores. ¡Nosotros invitamos al café!

¡Síguenos en nuestras redes!

Icono ELL blanco transparente
Logo The Agile Program

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies