-
En la actualidad la planeación estratégica y la priorización presentan desafíos significativos para los Product Managers y Product Owners. La creación de product roadmaps[1] (u hojas de ruta) integral y efectivos es la piedra angular para superar estos obstáculos. De la misma forma que un mapa de calles guía desde el punto A al punto B, una hoja de ruta o product roadmap[1], como lo llamaremos en esta entrada, conecta la brecha entre la estrategia del producto y el proceso de construcción o desarrollo.
Entendiendo la escencia de un Product Roadmap
Piensa en el product roadmap[1] como tu brújula estratégica. Proporciona un plan estructurado para delinear la dirección de tu producto, articular la visión y definir las fases cruciales de entrega. Este roadmap[1] ofrece un contexto esencial para los interesados, aclarando el razonamiento detrás tus esfuerzos y tu equipó de desarrollo. Idealmente, ofrece una visión general concisa que fomenta la alineación entre los product managers y las partes interesadas clave, como el marketing de productos, las áreas de venta o el servicio al cliente. Sin embargo, es fundamental recordar que el product roadmap es un plan, no un compromiso inflexible.
El product roadmap va más allá de una simple lista de características o tareas en un backlog. Debe pintar un panorama más amplio, resaltar iniciativas que impulsen el progreso, capitalizar en mercados emergentes, responder a dinámicas competitivas y brindar valor al cliente.
Distinguiendo Entre Product Roadmap and Backlog
Es fundamental distinguir entre un product roadmap[1] y a backlog. Aunque existe una tendencia, especialmente en entornos de emprendimiento, a difuminar las líneas entre ellos, comprender sus roles únicos es crucial. El roadmap de producto opera a un nivel superior, centrándose en la comunicación y la alineación estratégica. En contraste, el backlog se crea meticulosamente para la ejecución, detallando tareas y requisitos específicos. Para establecer un paralelo, imagina la hoja de ruta del producto como una descripción atractiva del menú de un plato, mientras que el backlog funciona como la receta detallada que guía su preparación.
Enlarge
Roadmap vs Backlog Vale la pena señalar que, aunque el product roadmap opera a un nivel superior que el backlog, utilizar herramientas capaces de sincronizar elementos entre el product roadmap y el backlog es ideal. Esto garantiza que la información se mantenga actualizada, minimizando el riesgo de desalineamiento del equipo o errores de priorización.
El Rol Crucial del Product Roadmap en el Éxito del Negocio
Un product roadmap funciona como un ayudante de navegación, simplificando el viaje hacia su destino. Para un product manger y un product owner, es la herramienta primordial para articular la visión y la estrategia de un producto, así como para obtener el respaldo de partes interesadas cruciales. Imagínala como el vínculo vital entre la planificación estratégica y el proceso de desarrollo.
Comprendiendo la Importancia de los Product Roadmaps
Piensa en el product roadmap como tu brújula en el vasto bosque del desarrollo de productos, proporcionando dirección clara y orientación para navegar desde la concepción hasta la ejecución. Justo como un esquema detallado antes de un trabajo de investigación, el product roadmap ofrece un plan estructurado, empoderando a los product managers con información valiosa y una ventaja estratégica.
Objetivos Clave en la Creación de un Product Roadmap
Un product roadmap bien diseñado cumple múltiples propósitos, incluyendo:
- Definir la visión y estrategia del producto.
- Dirigir la ejecución de iniciativas estratégicas.
- Alinear a las partes interesadas internas hacia objetivos comunes.
- Facilitar discusiones sobre opciones y escenarios potenciales.
- Comunicar de manera transparente el progreso del desarrollo.
- Compartir la dirección estratégica con partes interesadas externas.
Tu mejor recurso para delinear tus objetivos y enfoque para un producto es un product roadmap.
Enfrentando los Desafíos: Problemas y Soluciones de los Product Roadmaps
Aunque los product roadmaps ofrecen transparencia e información sobre la trayectoria futura de un producto, también presentan desafíos y posibles problemas. Un desafío es el riesgo de revelar planes estratégicos a competidores, lo que podría permitirles aprovechar características innovadoras antes del lanzamiento de tu producto. Para mitigar este riesgo, considera implementar roadmaps duales: uno para la planificación interna y otro para la comunicación externa. Además, una vez divulgado el roadmap, hacer cambios puede ser difícil, ya que puede vincularse inadvertidamente a contratos, convirtiendo un plan estratégico en un compromiso vinculante. Para abordar esto, ten cuidado con la distribución de roadmaps físicos y asegúrate de que exclusivamente el product manager maneje las discusiones sobre el futuro del producto.
Otro tema al cual estar atento, es que las prioridades pueden cambiar debido a la retroalimentación del cliente, el mercado o la competencia. Mantén y difunde una mentalidad flexible para adaptar el product roadmap y sus objetivos a las nuevas realidades.
Dominando el Arte de Crear Product Roadmaps
En el dinámico ambiente del desarrollo de productos, dominar el arte de la creación de product roadmaps es esencial para lograr el éxito empresarial. Al aprovechar un product roadmap bien diseñado, los product managers pueden alinear a las partes interesadas, comunicar la visión estratégica y navegar las complejidades del desarrollo de productos con confianza. Aprovecha el poder de la creación de product roadmaps como la guía para alcanzar los objetivos comerciales y mantenerte a la vanguardia en el competitivo panorama del mercado.
Explorando Product Roadmaps Efectivos: Tipos y Estrategias para el Éxito
Cuando hablamos de gestión de productos o product management, dominar el arte de la creación de product roadmaps, como ya mencionamos, es esencial para impulsar iniciativas estratégicas y lograr objetivos comerciales. Sin embargo, es crucial entender que no todos los product roadmaps se crean de la misma manera. En esta guía, hablaremos de los tipos comunes de product roadmap efectivos y exploramos estrategias para su implementación exitosa.
Revelando la Diversidad de los Product Roadmaps
Aunque el término “product roadmap” a menudo se usa en forma singular, la realidad es que las organizaciones suelen utilizar múltiples product roadmaps, cada uno adaptado a propósitos y audiencias específicos. Al comprender los matices de los diferentes tipos de product roadmaps, los product managers pueden comunicar efectivamente la estrategia, alinear a los interesados y conducir iniciativas exitosas de desarrollo de productos.
Tipos de Product Roadmaps Efectivos
- Roadmap de Portafolio: Este es un plan alto nivel que describe hitos generales para ejecutar la estrategia en todo un portafolio de productos. Es fundamental para demostrar cómo las contribuciones individuales o de equipo se alinean con el panorama más amplio.
- Roadmap de Estrategia: Considéralo como el product roadmap inaugural para un nuevo producto. Comunica la estrategia del producto, hitos importantes, características centrales y lanzamientos planificados.
- Roadmap de Entregas (Releases): Manteniendo una perspectiva de alto nivel, este product roadmap profundiza más en las entregas o lanzamientos del producto. Incluye detalles específicos sobre las tareas previas a una entrega y designa a individuos o equipos responsables.
- Roadmap de Funcionalidades (Features): Este product roadmap describe la línea de tiempo para lanzar funcionalidades o características específicas del producto. Enfatiza en fechas generales (por ejemplo, “Semana 2” o “Q3”) evita comprometerse con fechas específicas que pueden ser difíciles de cumplir.
- Roadmap Theme-Based: En lugar de un roadmap de funcionalidades, basado en mi experiencia, recomiendo adoptar un theme-based roadmap. Este enfoque proporciona flexibilidad al agrupar funcionalidades similares del producto, epicas o iniciativas bajo temas generales vinculados a objetivos estratégicos mesurables. Por ejemplo, un tema como “Completar la Primera Compra Más Rápido” se alinea con un objetivo estratégico. El theme-based roadmap permite la repriorización sin establecer expectativas poco realistas para los interesados.
En el entorno cambiante del product management, comprender la diversidad de product roadmaps es fundamental para lograr resultados exitosos. Al aprovechar estratégicamente diferentes tipos de roadmaps, los product managers pueden comunicar eficazmente la visión, alinear a las partes interesadas y navegar las complejidades del desarrollo de productos con confianza. Aprovecha el poder de la creación de product roadmaps como su brújula guía para alcanzar los objetivos comerciales y fomentar la innovación en el competitivo panorama del mercado actual.
No olvides diferenciar tus product roadmaps para audiencias internas versus externas. Por ejemplo, desarrolladores frente a personas de marketing, etc.
Creando un Product Roadmap Convincente
Antes de sumergirnos en las complejidades de la creación de product roadmaps, es fundamental establecer una base sólida. La fase más crítica del proceso de hoja de ruta ocurre durante la planificación estratégica, donde se establecen la visión y los objetivos del producto en alineación con las partes interesadas. Este paso fundamental es clave para diseñar una hoja de ruta que resuene con tu equipo y genere resultados significativos.
Estableciendo la Estrategia y Visión del Producto
Al desarrollar una estrategia para tu product roadmap, es imperativo comenzar familiarizándote con la estrategia de tu producto. Esto implica identificar y articular la visión y los principios que sustentan tu producto, es decir, el “por qué” de su existencia. Al invertir tiempo en definir la misión de tu producto, sientas las bases para una hoja de ruta orientada a propósitos y alineada con tus objetivos generales.
Documentando la Misión del Producto
Antes de adentrarte en la planificación del roadmap, dedica tiempo a destilar la misión de tu producto en una declaración clara y concisa. Esta declaración debe encapsular la visión del producto, la base de clientes objetivo, los problemas abordados y la propuesta de valor que ofrece al mercado. Documentar esta información solidifica los elementos clave que dan forma a tu hoja de ruta y facilita la comunicación y alineación con las partes interesadas.
Ventajas de un Enfoque Basado Primero en la Estrategia
Adoptar una metodología basada en la estrategia ofrece numerosas ventajas en la creación de un product roadmap. Simplifica la comunicación de la visión del producto en toda la organización, asegurando la alineación antes de que comiencen las discusiones detalladas. Además, proporciona claridad sobre las prioridades y ayuda a identificar elementos que pueden no estar alineados con la visión general del producto.
Formulación de Objetivos Orientados a Resultados
Partiendo de la visión del producto, establece objetivos claros y orientados a resultados que den forma a las iniciativas delineadas en tu roadmap. Estos objetivos sirven como columna vertebral del roadmap, traduciendo la visión estratégica en planes concretos que generan resultados tangibles. Para lo anterior se puede partir de contestar la pregunta: ¿Qué impacto tendrán estos objetivos en el éxito general del proyecto o la organización?, esperando que las respuestas incluyan números realistas en lugar de solo ideas, es decir, en lugar de decir “mejorar las ventas”, sé más preciso: “aumentar las ventas en un 20% en el próximo trimestre”.
Impulsando el Éxito a Través de la Creación Estratégica de Producto Roadmaps
Elaborar un product roadmap convincente requiere una planificación cuidadosa, visión estratégica y alineación con las partes interesadas. Al invertir en la fase de planificación estratégica y establecer una visión clara del producto, preparas el terreno para un roadmap que no solo guía a tu equipo, sino que también genera resultados significativos y éxito en el competitivo panorama del mercado actual.
Maximizando el Éxito del Product Roadmap con Indicadores Clave de Desempeño Integrados
Cuando se ve involucrado en la creación de Product Roadmaps, la integración de Indicadores Clave de Desempeño (KPIs)[2] juega un papel fundamental para tomar decisiones estratégicas y elevar la efectividad del product roadmap. Veamos cómo la integración estratégica de los KPIs puede mejorar tu hoja de ruta de productos y propulsar tu negocio hacia adelante.
Estableciendo el Escenario para la Planificación Estratégica
Una vez que tu visión de producto está cristalizada, el siguiente paso implica definir objetivos de producto distintos acompañados de métricas asignadas. Estos objetivos, que abarcan períodos más cortos, generalmente de uno a dos años, proporcionan un roadmap para el éxito. Ya sea que optes por un modelo de métrica North Star o un conjunto de métricas igualmente ponderadas, la integración de KPIs garantiza la alineación con los objetivos estratégicos generales.
Aprovechando las Métricas para la Toma de Decisiones Informadas
Las métricas son herramientas invaluables para dirigir tanto las decisiones de producto como la trayectoria de tu product roadmap. Las métricas orientadas al negocio, como ingresos, margen, costo de adquisición y retención, actúan como conectores efectivos, vinculando las iniciativas del roadmap con tu estrategia general. Además, las métricas centradas en el cliente, como el uso del producto y la retención, ofrecen información valiosa, alineándose con objetivos estratégicos más amplios y fomentando un crecimiento sostenible.
Priorización Estratégica: Elevando la Clasificación de las Iniciativas
Con tus objetivos de producto y métricas en su lugar, la priorización estratégica se vuelve fundamental. Priorizar las iniciativas para incluirlas en tu hoja de ruta de productos garantiza el máximo impacto y éxito. Mi recomendación es utilizar un modelo Valor vs. Esfuerzo. Evalúa cada iniciativa esencial para lograr tu visión de lanzamiento del producto y colócala en la escala Valor vs. Esfuerzo. Este enfoque estratégico optimiza la asignación de recursos, priorizando e alineando las iniciativas de alto impacto con tu estrategia general del producto.
En conclusión, la integración de los Indicadores Clave de Desempeño (KPIs) en la creación de hojas de ruta de productos mejora la toma de decisiones, impulsa la alineación estratégica y maximiza el éxito empresarial. Al aprovechar las métricas de manera efectiva, puedes impulsar tu hoja de ruta hacia adelante y alcanzar tus objetivos organizacionales con precisión y claridad.
Mezcla Estratégica de Iniciativas
Lograr una combinación equilibrada de iniciativas en ambos cuadrantes azul y amarillo es crucial. Comienza con tareas de bajo esfuerzo y alto valor, es decir, el “fruto fácil”. Luego, incorpora iniciativas de alto valor y alta complejidad que puedan diferenciarte de tus competidores
Atender las Solicitudes de los Clientes
Para satisfacer las necesidades de los clientes, incluye algunas iniciativas de bajo valor y bajo esfuerzo que los clientes han solicitado. Aunque individualmente pueden no tener un impacto significativo, abordar colectivamente los comentarios de los clientes mejora la satisfacción general.
Enfoque y Priorización Refinados
Como alternativa, entre otros métodos, explora diferentes modelos de priorización como el Modelo Kano, que evalúa las iniciativas según la satisfacción del cliente, o quizás puedes utilizar el modelo MoSCoW, que es útil para identificar características o cualidades. Categoriza las iniciativas como esenciales, mejoradores de rendimiento o características que generan satisfacción para destacarte entre los competidores.
Utilizando Modelos Contemporáneos: El Modelo de Puntuación RICE
El Modelo de Puntuación RICE[3] es un enfoque moderno para la priorización. Evalúa las iniciativas según los siguientes criterios:
- Reach (Alcance): Influencia en la base de clientes.
- Impact (Impacto): Efecto generado.
- Confidence (Confianza): Nivel de confianza en el alcance y el impacto.
- Effort (Esfuerzo): Tiempo y esfuerzo requeridos.
Como mencioné, RICE no es el único modelo de priorización, pero es un excelente punto de partida, la consistencia es clave. Comprométete con un método de priorización y úsalo como base para adaptar su roadmap a las solicitudes de las partes interesadas durante todo el proceso de desarrollo. La coherencia garantiza la alineación con los objetivos estratégicos y mejora la efectividad del roadmap. En conclusión, las estrategias de priorización efectivas son esenciales para la creación exitosa de products roadmaps. Al adoptar una combinación estratégica de iniciativas, abordar las necesidades de los clientes y aprovechar los modelos de priorización modernos, puede optimizar su roadmap para impulsar la innovación y mantenerse a la vanguardia en el panorama competitivo.
Participación de los Interesados: Involucrando a tus Colaboradores para el Éxito del Product Roadmap
Manteniendo la Participación de los Interesados Durante la Ejecución
Incluso cuando el product roadmap está en marcha, mantener una participación frecuente con los interesados es esencial. El roadmap sirve como un punto de referencia valioso durante las interacciones con los interesados, facilitando la toma de decisiones colaborativa y la alineación con los objetivos estratégicos. Escenario de Ejemplo: Aprovechando la Hoja de Ruta para la Toma de Decisiones Colaborativa, por ejemplo, si el Vicepresidente de Ventas insiste en incluir una función específica basada en los comentarios de los clientes, hacer referencia al método de priorización y a la hoja de ruta permite evaluar objetivamente el valor de esa función. Este enfoque colaborativo garantiza que las decisiones del roadmap se base en datos y alineación estratégica en lugar de preferencias individuales.
El desarrollo de productos está evolucionando rápidamente, impulsado en gran medida por las prácticas ágiles de desarrollo de software. Han quedado atrás los días de ciclos de desarrollo prolongados que duraban de 12 a 24 meses; hoy en día, los productos pueden materializarse en tan solo tres a seis meses, o incluso menos.La Clave es la Adaptabilidad: Revisando su Product Roadmap
La frecuencia con la que debes revisar y actualizar tu product roadmap depende de varios factores, como tu línea de tiempo de desarrollo, los cambios en el mercado, el panorama competitivo y las expectativas de los consumidores. Idealmente, realizar una revisión y actualización semanal o diaria de tu roadmap resulta beneficioso. Sin embargo, esto no implica necesariamente comunicar estas actualizaciones con la misma frecuencia. Dependiendo de tu audiencia, la comunicación periódica semanal o mensual puede ser suficiente. Abrazar la agilidad en la creación de product roadmap es esencial para mantenerse a la vanguardia en el dinámico panorama del mercado actual. Adoptar un enfoque flexible para la revisión y comunicación del roadmap te permite navegar el cambiante paisaje del desarrollo de productos con confianza y agilidad.Adaptando Product Roadmaps a Entornos Ágiles
Mejorando la Efectividad de Roadmaps con Indicadores Medibles de Éxito
- Métricas Clara de Éxito: Introduce indicadores medibles de éxito para cada elemento del roadmap para proporcionar claridad y fomentar la responsabilidad dentro del equipo de desarrollo. Esto garantiza que cada característica o funcionalidad se alinee con objetivos comerciales tangibles y pueda rastrearse su impacto en el éxito general.
- Alineación con el Propósito: Conecta cada aspecto del roadmap con el propósito general del producto, estrechamente vinculado a la misión de la organización. Al enmarcar los elementos del roadmap dentro del contexto de su propósito, los equipos ágiles obtienen una comprensión más profunda de la importancia de su trabajo y su contribución a los objetivos organizacionales más amplios.
En conclusión, integrar un roadmap de productos en las prácticas ágiles mejora la planificación, la transparencia y la alineación con los objetivos comerciales. Al adoptar enfoques centrados en el cliente, proporcionar actualizaciones incrementales e incorporar indicadores medibles de éxito, los equipos ágiles pueden navegar el desarrollo de productos con claridad y propósito, avanzando hacia el éxito sostenido en mercados dinámicos.Los planes son nada…planear lo es todo
Establezca un Marco de Comunicación Robusto
Para saber más:
[1] El concepto de “product roadmap” se originó en los tempranos 1900s como ayuda para los automovilistas, con los primeros mapas de carreteras o roadmaps que enumeraban instrucciones sobre cómo llegar de una ciudad a otra, dónde encontrar gasolina y dónde encontrar un taller de reparación.
[2] El concepto de Indicadores Clave de Desempeño (KPIs) experimentó su último gran cambio en la década de 90s con la introducción del Cuadro de Mando Integral (Balanced Scorecard) por el Dr. Robert Kaplan y el Dr. David Norton en 1996. The Balanced Scorecard: Translating Strategy into Action.
[3] El modelo de priorización RICE fué desarrollado por Intercom, un fabricantes de software de mensajería, para mejorar su proceso interno de toma de decisiones https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/
[4] “Attractive Quality and Must-Be Quality” – El profesor Noriaki Kano introdujo el Análisis Kano, un enfoque revolucionario para entender la satisfacción del cliente la cual se expandió más allá de las teorías del marketing convencional en 1984. https://www.jstage.jst.go.jp/article/quality/14/2/14_KJ00002952366/_article/-char/en
Enlaces Relacionados:
El Origen Y Los Valores De Agile
El Tamaño del Equipo Scrum
¿Que certificación elegir como Scrum Master?Libros para saber más:
Geoffrey Moore introduce la teoría de marketing “cruzando el abismo”, que segmenta a los clientes en diferentes grupos (innovadores, adoptantes tempranos, mayoría temprana, mayoría tardía y rezagados). El libro proporciona ideas sobre cómo comercializar productos para cada grupo de manera secuencial, basándose en el éxito del grupo anterior.
Clayton Christensen explora porque las empresas establecidas a menudo no logran adaptarse a las tecnologías disruptivas. Al comprender “el dilema del innovador”, los product managers pueden tomar decisiones informadas y navegar los cambios tecnológicos.
Este libro compila los artículos más populares de la columna “Product Bytes” de Mironov. Cubre temas como, entender a los clientes, el precio de los productos y el mantenimiento efectivo de organizaciones creadoras de productos.Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Destacadas / Featured / Product ManagementStrategic planning and prioritization present significant challenges for today’s Product Managers and Product Owners. A comprehensive and effective product roadmap[1] creation is the cornerstone for navigating these hurdles. Just as a street map guides you from point A to point B, a product roadmap[1] bridges the gap between product strategy and the development process.
Understanding the Core of a Product Roadmap
Think of the product roadmap[1] as your strategic compass. It provides a structured plan for outlining your product’s direction, articulating the vision, and delineating crucial deliverable phases. This roadmap[1] offers essential context for stakeholders, elucidating the reasoning behind your development endeavors. Ideally, it offers a concise overview that fosters alignment among product managers and key stakeholders such as product marketing, sales, and customer service. However, it’s essential to remember that the product roadmap is a blueprint, not an inflexible commitment.
The product roadmap[1] transcends a mere list of features or tasks in a backlog. It must paint a broader picture, highlighting initiatives that drive progress, capitalize on emerging markets, respond to competitive dynamics, and deliver customer value.
Distinguishing Between Product Roadmap and Backlog
It’s vital to distinguish between a product roadmap[1] and a backlog. While there’s a tendency, particularly in startup environments, to blur the lines between them, understanding their unique roles is crucial. The product roadmap operates higher, focusing on communication and strategic alignment. In contrast, the backlog is meticulously crafted for execution, detailing specific tasks and requirements. To draw a parallel, envision the product roadmap as an enticing menu description of a dish, while the backlog serves as the detailed recipe guiding its preparation.
Enlarge
Roadmap vs Backlog It’s worth noting that, while the product roadmap operates at a higher level than the backlog, utilizing tools capable of synchronizing items between the roadmap and the backlog is ideal. This ensures that information remains updated, minimizing the risk of team misalignment or prioritization errors.
The Crucial Role of Product Roadmaps in Business Success
A product roadmap serves as a navigational aid, streamlining the journey toward your destination. For a product manager, it stands out as the paramount tool for articulating the vision and strategy of a product and securing support from crucial stakeholders. Picture it as the vital link between strategic planning and the development process.
Understanding the Significance of Product Roadmaps
Imagine a roadmap as your compass in the vast terrain of product development, providing clear direction and guidance to navigate the journey from conception to execution. Much like a detailed outline before a research paper, a product roadmap offers a structured plan, empowering product managers with invaluable insights and a strategic advantage.
Key Objectives of Product Roadmap Creation
A well-designed product roadmap serves multifaceted purposes, including:
- Defining the vision and strategy of the product
- Directing the execution of strategic initiatives
- Aligning internal stakeholders toward common goals
- Facilitating discussions on potential options and scenarios
- Communicating development progress transparently
- Sharing the strategic direction with external stakeholders
Your best resource for outlining your goals and approach for a product is a product roadmap.
Navigating the Challenges: Roadmaps Pitfalls and Solutions
While product roadmaps offer transparency and insight into a product’s future trajectory, they also present challenges and potential pitfalls. One such challenge is the risk of revealing strategic plans to competitors, potentially enabling them to capitalize on innovative features before your product launch. To mitigate this risk, consider implementing dual roadmaps – one for internal planning and another for external communication. Furthermore, once a roadmap is disclosed, making alterations can be challenging, as it may become inadvertently tied to contracts, transforming a strategic plan into a binding commitment. To address this, exercise caution in the distribution of physical roadmaps, ensuring the product manager exclusively manages discussions about the product’s future.
Mastering the Art of Product Roadmap Creation
In the dynamic landscape of product development, mastering the art of Product Roadmap Creation is essential for driving business success. By leveraging a well-designed roadmap, product managers can confidently align stakeholders, communicate strategic vision, and navigate the complexities of product development. Embrace the power of Product Roadmap Creation as your guiding compass toward achieving business objectives and staying ahead in the competitive market landscape.
Exploring Effective Product Roadmaps: Types and Strategies for Success
When we talk about product management, mastering the art of Product Roadmap Creation is essential for driving strategic initiatives and achieving business objectives. However, it’s crucial to understand that not all roadmaps are created equal. In this guide, we get into common types of effective product roadmaps and explore strategies for their successful implementation.
Unveiling the Diversity of Product Roadmaps
While the term “product roadmap” is often used in singular form, the reality is that organizations often utilize multiple roadmaps, each tailored to specific purposes and audiences. By understanding the nuances of different roadmap types, product managers can effectively communicate strategy, align stakeholders, and drive successful product development initiatives.
Types of Effective Product Roadmaps
- Portfolio Roadmap: This high-level plan outlines general milestones for executing the strategy across an entire product portfolio. It’s instrumental in demonstrating how individual or team contributions align with the broader picture.
- Strategy Roadmap: Consider this as the inaugural roadmap for a new product. It communicates the product’s strategy, major milestones, core features, and planned releases.
- Releases Roadmap: While maintaining a high-level perspective, this roadmap delves deeper into product releases. It includes specific tasks leading up to a release and designates responsible individuals or teams.
- Features Roadmap: This roadmap outlines the timeline for releasing specific product features. Emphasizing general dates (e.g., “Week 2” or “Q3”) prevents committing to specific dates that may be challenging to meet.
- Theme-Based Roadmap: Instead of a features roadmap, based on experience I recommend adopting a theme-based roadmap. This approach provides flexibility by grouping similar product features, epics, or initiatives under overarching themes tied to measurable strategic goals. For instance, a theme like “Customers Complete First Purchase Faster” aligns with a strategic objective. The theme-based roadmap allows for reprioritization without setting unrealistic expectations for stakeholders.
In the changing environment of product management, understanding the diversity of product roadmaps is key to driving successful outcomes. By leveraging different roadmap types strategically, product managers can effectively communicate vision, align stakeholders, and navigate the complexities of product development with confidence. Embrace the power of Product Roadmap Creation as your guiding compass toward achieving business objectives and driving innovation in today’s competitive market landscape.
Do not forget to differentiate your roadmaps for internal versus external audiences. An example, developers versus marketing people, etc.
Crafting a Compelling Product Roadmap
Before diving into the intricacies of Product Roadmap Creation, laying a strong foundation is essential. The most critical phase of the roadmap process occurs during the strategic planning phase, where the vision and goals for the product are established and aligned with stakeholders. This foundational step is key to crafting a roadmap that resonates with your team and drives meaningful outcomes.
Establishing Product Strategy and Vision
When developing a strategy for your Product Roadmap, it’s imperative to start by familiarizing yourself with your product strategy. This involves pinpointing and articulating the vision and principles that underpin your product—the “why” behind its existence. By investing time in defining your product’s mission, you lay the groundwork for a roadmap that is purpose-driven and aligned with your overarching goals.
Documenting the Product Mission
Before diving into roadmap planning, take the time to distill your product’s mission into a clear and concise statement. This statement should encapsulate the product vision, target customer base, problems addressed, and the value proposition it brings to the market. Documenting this information solidifies key elements that shape your roadmap and facilitates communication and alignment with stakeholders.
Advantages of a Strategy-First Approach
Embracing a strategy-first methodology offers numerous advantages in Product Roadmap Creation. It streamlines communication of the product vision across the organization, ensuring alignment before detailed discussions begin. Additionally, it provides clarity on priorities and helps identify elements that may not align with the overarching product vision.
Formulating Outcome-Oriented Goals
Building on the product vision, establish clear and outcome-oriented goals that shape the initiatives outlined on your roadmap. These goals serve as a roadmap’s backbone, translating strategic vision into actionable plans that drive tangible results.
Driving Success Through Strategic Product Roadmap Creation
Crafting a compelling Product Roadmap requires careful planning, strategic vision, and alignment with stakeholders. By investing in the strategic planning phase and establishing a clear product vision, you set the stage for a roadmap that not only guides your team but also drives meaningful outcomes and success in today’s competitive market landscape.
Maximizing Product Roadmap Success with Integrated Key Performance Indicators
When you get involved in Product Roadmap Creation, the integration of Key Performance Indicators (KPIs)[2] plays a pivotal role in driving strategic decision-making and elevating roadmap effectiveness. Let’s explore how the strategic integration of KPIs can enhance your product roadmap and propel your business forward.
Setting the Stage for Strategic Planning
Once your product vision is crystallized, the subsequent step involves defining distinct product goals accompanied by assigned metrics. These goals, spanning shorter durations, typically one to two years, provide a roadmap for success. Whether you opt for a North Star metric model or a set of equally weighted metrics, the integration of KPIs ensures alignment with overarching strategic objectives.
Leveraging Metrics for Informed Decision-Making
Metrics serve as invaluable tools for steering both product decisions and the trajectory of your roadmap. Business-oriented metrics such as revenue, margin, acquisition cost, and retention act as effective connectors, linking roadmap initiatives to your overarching strategy. Additionally, customer-centric metrics like product usage and retention offer valuable insights, aligning with broader strategic objectives and driving sustainable growth.
Strategic Prioritization: Elevating Initiative Ranking
With your product goals and metrics in place, strategic prioritization becomes paramount. Prioritizing initiatives for inclusion in your product roadmap ensures maximum impact and success. Our recommendation is to utilize the Value vs. Effort model. Assess each initiative essential to realizing your product release vision and place it on the Value vs. Effort scale. This strategic approach optimizes resource allocation, prioritizing and aligning high-impact initiatives with your overarching product strategy.
In conclusion, the integration of KPIs into Product Roadmap Creation enhances decision-making, drives strategic alignment, and maximizes business success. By leveraging metrics effectively, you can propel your roadmap forward and achieve your organizational goals with precision and clarity.
Strategic Initiative Blend
Achieving a balanced mix of initiatives across both blue and yellow quadrants is crucial. Start with low-effort, high-value tasks—the low-hanging fruit. Then, incorporate high-value, high-complexity initiatives that could set you apart from competitors.
Addressing Customer Requests
To cater to customer needs, include some low-value/low-effort initiatives that customers have requested. While individually they may not drive significant impact, collectively addressing customer feedback enhances overall satisfaction.
Refining Focus and Prioritization
Alternatively, among other methods, explore different prioritization models like the Kano Model[4], which evaluates initiatives based on customer delight, or maybe you can use the MoSCoW model, which is useful for finding features or qualities. Categorize initiatives as essentials, performance enhancers, or delight-inducing features to stand out from the competitors.
Utilizing Contemporary Models: The RICE Scoring Model
The RICE[3] Scoring Model is a modern approach to prioritization. Assess initiatives based on Reach, Impact, Confidence, and Effort:
- Reach: Influence on customer base
- Impact: Effect brought about
- Confidence: Level of confidence in reach and impact
- Effort: Time and effort required
As I mentioned, RICE is not the only prioritization model but is an excellent starting point, consistency is key. Commit to a prioritization method and use it as a foundation for adapting your roadmap to stakeholder requests throughout the development process. Consistency ensures alignment with strategic objectives and enhances roadmap effectiveness. In conclusion, effective prioritization strategies are essential for successful product roadmap creation. By adopting a strategic blend of initiatives, addressing customer needs, and leveraging modern prioritization models, you can optimize your roadmap to drive innovation and stay ahead in the competitive landscape.
Stakeholder Involvement: Engaging Your Collaborators for Product Roadmap Success
Product development is swiftly evolving, largely driven by agile software development practices. Gone are the days of lengthy development cycles lasting 12 to 24 months; today, products can materialize in as little as three to six months, or even less.Collaboration with stakeholders should be ingrained in your planning and development processes from the project’s inception. By incorporating their input early on, you ensure alignment and buy-in throughout the roadmap creation process. After crafting your product roadmap, it’s crucial to secure stakeholder endorsement. While close collaboration throughout the process minimizes surprises, obtaining formal endorsement ensures alignment and commitment to the roadmap’s objectives. Collaborating with stakeholders to refine prioritizations further enhances roadmap effectiveness and stakeholder satisfaction.Maintaining Stakeholder Engagement Throughout Execution
Even as the product roadmap is set into motion, maintaining frequent engagement with stakeholders is essential. The roadmap serves as a valuable reference point during stakeholder interactions, facilitating collaborative decision-making and alignment with strategic objectives. Example Scenario: Leveraging the Roadmap for Collaborative Decision-Making For instance, if the VP of Sales urges the inclusion of a specific feature based on customer feedback, referencing the prioritization method and roadmap allows for an objective assessment of the feature’s value. This collaborative approach ensures that roadmap decisions are driven by data and strategic alignment rather than individual preferences.Optimal Update Frequency: How Often Should You Revise Your Product Roadmap?
Adaptability is Key: Revisiting Your Product Roadmap
The frequency of revisiting and updating your product roadmap depends on several factors, including your development timeline, market shifts, competitive landscape, and consumer expectations. Ideally, conducting a weekly or daily review and update of your roadmap proves beneficial. However, this doesn’t necessitate communicating these updates at the same frequency. Depending on your audience, periodic weekly or monthly communication may suffice. Embracing agility in product roadmap creation is essential to stay ahead in today’s dynamic market landscape. Adopting a flexible approach to roadmap revision and communication allows you to navigate the evolving product development landscape with confidence and agility.Adapting Product Roadmaps to Agile Environments
Enhancing Roadmap Effectiveness with Measurable Success Benchmarks
- Clear Success Metrics: Introduce measurable success benchmarks for each roadmap item to provide clarity and encourage accountability within the development team. This ensures that every feature or functionality aligns with tangible business goals and can be tracked for its impact on overall success.
- Alignment with Purpose: Connect every aspect of the roadmap with the product’s overarching purpose, closely tied to the organization’s mission. By framing roadmap items within the context of their purpose, scrum teams gain a deeper understanding of their work’s significance and its contribution to broader organizational goals.
Plans are nothing … Planning is everything
Establish a Robust Communication Framework
To know more:
[1] The concept of the “product roadmap” originated in the early 1900s as motorist aids, with the first roadmaps listing instructions on how to get from one town to another, where to find gasoline, and where to find a repair shop.
[2] The concept of KPIs saw its last big change in the 1990s with the introduction of the Balanced Scorecard by Dr. Robert Kaplan and Dr. David Norton Kaplan, in 1996 The Balanced Scorecard: Translating Strategy into Action.
[3] RICE prioritization model was developed by Intercom, a messaging-software producer, to improve its internal decision-making process https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/
[4] “Attractive Quality and Must-Be Quality” – Professor Noriaki Kano introduced Kano Analysis, a revolutionary approach to understanding customer satisfaction that expanded beyond conventional marketing theories in 1984. https://www.jstage.jst.go.jp/article/quality/14/2/14_KJ00002952366/_article/-char/en
Related links:
Agile’s Origins and Values
The Scrum Team Size
What Scrum Master Certification to Choose?Some books to know more:
Moore introduces the “crossing the chasm” marketing theory, which segments customers into different groups (innovators, early adopters, early majority, late majority, and laggards). The book provides insights on how to market products to each group sequentially, building upon the success of the previous one.Christensen explores why established companies often fail to adapt to disruptive technologies. By understanding the innovator’s dilemma, product managers can make informed decisions and navigate technological shifts.This book compiles Mironov’s popular articles from his column, “Product Bytes.” It covers topics like understanding customers, pricing products, and maintaining effective product organizations.Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Probablemente usted o su organización ya tienen muy claro la Meta y los Objetivos que desea para su proyecto, si es así déjeme felicitarlo porque no siempre es fácil, si por el contrario aún no ha dedicado tiempo a esa tarea o sigue luchando para definir sus metas y objetivos quizá quiere echar un vistazo a nuestro video anterior Definiendo Metas y Objetivos.
Ahora bien, suponiendo que sus metas y objetivos están establecidos, es probable que usted tenga algunas ideas para poder cumplirlos, aquí es donde la participación de los miembros del equipo con el cual usted trabaja se vuelve importante, ya que las perspectivas de diferentes integrantes llega a la creación, fusión o discriminacón de ideas. Todas esta interacción que puede ser impulsado por prácticas de design thinking provoca una lluvia de ideas que se convertirán eventualmente en estrategias de ejecución.
Cuando obtenga muchas ideas y/o estrategias el siguiente paso consistirá en evaluar cuales respaldan de mejor manera a sus objetivos, en el video de este post, llamado Eligiendo Una Estrategia, puede obtner una referancia rápida de como evaluar el grado de cumplimiento de sus ideas y estrategias a los objetivos que persigue:
- Lluvia de ideas
- Matriz de evaluación
- ¿La estrategia satisface los objetivos?
- ¿La estrategia es factible?
- ¿Los riesgos de la estrategia son aceptables?
- ¿La estrategia es compatible con la cultura de la organización?
Recuerde que este video es parte del segundo capítulos del curso en videos de Introducción a la Administración de Proyectos, si desea puede ver los videos anteriores para comprender mejor el tema tratado.
Si desea ver más videos y como se compone este curso tiene disponible la estructura del mismo aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.
YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones, comentarios y todo eso que los youtubers siempre piden.
También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica (sólo los videos que lo ameriten).
Video Eligiendo Una Estrategia:
Eligiendo Una EstrategiaAlgunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Puede pensar que la principal responsabilidad de alguien a cargo de un proyecto es entregarlo a tiempo y dentro del presupuesto, de hecho, es una manera muy común de pensar de organizacione, pero estan equivocados. Como parte de un cuerpo estratégico de alto nivel o como un independiente, los responsables de la administración de proyectos, en primer lugar, ayudan a impulsar, guiar y ejecutar acciones para lograr los objetivos de valor agregado identificados de cualquier organización.
Cuando las organizaciones maduran eventualmente crean cosas como las oficinas de gestión de proyectos (PMO) y las buenas prácticas de gestión de proyectos tienen más probabilidades de ser bien recibidas por los ejecutivos y partes interesadas de la organización como elementos tácticos indispensables una vez que reconocen su verdadero valor estratégico.
Muchas organizaciones hoy ya saben que contratado y capacitado a los pensadores estratégicos, aumenta la probabilidad de ejecutar proyectos de alto impacto. Este alto impacto, entre otras cosas, se logra identificando metas y objetivos de largo, mediano y corto plazo con el que los posteriores esfuerzos se deben alinear. Cada involucrado en un proyecto debe poder tener una comprensión clara de la línea directa desde las tareas de un proyecto hasta la visión estratégica de alto nivel.
En el video de este post, llamado Definiendo Metas Y Objetivos, puede aprender las bases para poder crear metas y objetivos apropiados para sus proyectos. En este video se hablamos de :
- Definición de una meta
- Definición de objetivo
- Tipos de objetivos
- Elementos a tomar en cuenta para crear y redactar objetivos
Recuerde que este video es parte del segundo capítulos del curso en videos de Introducción a la Administración de Proyectos, si desea puede ver los videos anteriores para comprender mejor el tema tratado.
Si desea ver más videos y como se compone este curso tiene disponible la estructura del mismo aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.
YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones, comentarios y todo eso que los youtubers siempre piden.
También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica (sólo los videos que lo ameriten).
Video Definiendo Metas Y Objetivos:
Definiendo Metas Y ObjetivosAlgunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
¿Cuántos proyectos que se alejan de su objetivo? ¿cuántos malos entendidos sobre lo debe hacer su sistema ha tenido? ¿cómo comenzar a priorizar sus tareas? Saber definir el problema que estamos resolviendo con suficiente claridad desde el principio puede ser un factor muy importante.
Continuando con el curso en videos de Introducción a la Administración de Proyectos, Internet80.com y @ManuGekko han comenzado con el segundo capítulo de este curso, el cual estará dedicado el grupo de procesos de Inicio en un proyecto. Es aquí donde comenzaremos a aprender cómo establecer la visión inicial de proyecto y a obtener buy-in de los involucrados en el mismo.
Este segundo capítulo comienza con un video de introducción en dónde hablamos del Inicio de un Proyecto como proceso esto abarca de manera introductoria los conceptos de:
- Grupo de procesos de inicio
- Acta de constitución del proyecto
Enseguida tenemos el siguiente video donde se aborda el tema de la definición del Enunciado de Problema, por qué es importante y como crearlo, para ellos se cubren los temas:
- Concepto de enunciado de problema
- Diferencia con una solución
- La importancia de preguntar por qué
Si desea ver más videos y como se compone este curso tiene disponible la estructura del mismo aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.
Recuerde que YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones, comentarios y todo eso que los youtubers siempre piden. También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica (sólo los videos que lo ameriten).
Video Iniciando un Proyecto:
Iniciando Un ProyectoEnunciado De Problema:
Enunciado De ProblemaAlgunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
First of All
If you don’t know the four Agile Value Statements, I invite you to take a look at Agile’s origins and values post before continuing, if you already did or already know these values, now you can focus your attention on how the agile team approach actually is in the field. Together, the Agile Value Statements add up to a highly iterative and incremental process and deliver tested code at the end of each iteration. The next points, in general, include the overall way I which an agile team carries the project:
- Works as one
- Works in short iterations
- Release something every iteration
- Focuses on business priorities
- Inspects and adapts
The Agile team works as one
Unfortunately, is usual to see some business and systems analysts throw processes or requirements to designers and programmers like a ball over the wall and just continuing with their lives, also there are designers and architects who elaborate their appealing designs without the slightest consultation to their programmer coworkers, or talented programmer who finish their assigned part of the system and then shake their hands and disappear; and we can go on with sad stories. A successful agile team must have a “we’re in this together” mindset.
I really like using video games analogies, because are a great way to illustrate what happens in real life. A lot of online games are team games, where each member of the team has a role. In this teams, there are roles such as the healer who heals his teammates, the tank who receives hits becoming in a shield for the rest of team who can attack more efficiently, the DPS who do damage to the enemy and the special class who does some kind of damage. When a player doesn’t perform their role properly, puts the rest of the team at a considerable disadvantage, sometimes this breaks the whole team completely. Everybody must work as one!
Just like happens in this games, the agile teams also have roles, and it’s worth identifying them in a general way:
Product Owner
The main responsibilities of the product owner include making sure that the whole team shares the same vision about the project, establishing priorities in a way that the functionalities that contribute the most value to the business are always in which the team is working on. Take decisions that take the best return on investment of the project is the highest priority.
Customer
The customer is the person who made the decision to finance the project, usually represents a group or division. In these cases, it is common for this role to be combined with the product owner. In other projects, the customer can be a user.
Developer
In the context of agile teams, a developer title is used in a wide way, this is a developer can be a programmer, a graphic designer, a database engineer, user experience experts, architects, etc.
Project manager
We have to take this carefully because an agile project manager focuses more on leadership than traditional management. In some projects and agile frameworks, this figure doesn’t even exist or if it does, the person in charge of this role shares the traditional project management responsibilities with other roles such as product owner. Also can be an advisor on the adoption and understanding of the agile approach. In very small projects can even have a role as a developer, but this practice is not recommended.
The Agile team works in short iterations
Already mentioned this in previous posts, in agile projects, there is not a phase delineation too marked. There are not an exhaustive establishment of requirements at the beginning of the project followed by an analysis, there is not architectural design phase for the entire project. Once the project really starts, all the work (analysis, coding design, testing, etc.) occurs together within an iteration.
The iterations are done within a previously delimited time-space (timeboxed). This means that each iteration is completed is the agreed time without excuses, even if the planned functionalities are not finished. The iterations are often very short. Most agile teams use iterations between one week and four weeks.
The Agile team release something every iteration
Something crucial in each iteration is that within its space of time one or more requirements are transformed into codified, tested and potentially packageable software. In reality, this does not mean that something is delivered to the end users, but it must be possible to do so. The iterations one by one add up the construction of only some functionalities, in this way an incremental development is obtained by going from one iteration to the next.
Because a single iteration usually does not provide enough time to develop all the functionalities that the customer wants, the concept of release was created. A release comprises one or more (almost always more) iterations. Releases can occur in a variety of intervals, but it’s common for releases to last between 2 and 6 months. At the end of a release, this can be followed by another release and this one can be followed by another, and so on until the project is finished.
The Agile team focuses on business priorities
Agile teams demonstrate a commitment to business priorities in two ways. First, they deliver functionalities in the order specified by the product owner, which is expected to prioritize and combine features in a release that optimizes the return on investment for the project organization. To achieve this, a plan is created for the release based on the capabilities of the team and a prioritized list of the new desired functionalities. For the product owner to have greater flexibility in prioritization, the features must be written down minimizing the technical dependencies between them.
Secondly, agile teams focus on completing and delivering functionalities valued by the user instead of completing isolated tasks.
The Agile team inspects and adapts
It is always good to create a plan, but the plan created at the beginning does not guarantee what will happen in the future. In fact, a plan is just a guess at a point in time. If you live persecuted by Murphy’s Law like me 😀, there will be many things that will conspire against the plan. Project staff can come or go, technologies will work better or worse than expected, users will change their minds, competitors can force us to respond differently or faster, and so on. Agile teams see that each change represents both, an opportunity and the need to update the plan to improve and reflect the reality of the current situation.
At the beginning of each new iteration, an agile team incorporates all the new knowledge obtained in the previous iteration and adapts accordingly. If a team learned something that is likely to affect the accuracy or value of the plan, the plan must be updated. That is, perhaps the team discovered that they have overestimated or underestimated their ability to progress (capacity) and that a certain type of work consumes more time than previously thought.
In the same way, the plan can be affected by the knowledge that the product owner has gained from the users. Perhaps because of the feedback obtained from a previous iteration the product owner has learned that users want to see more of some kind of functionality and no longer value so much that they had considered. This type of situation can alter the plan, so you have to adapt it to improve its value.
Sorry about my English I’m not a natural speaker (don’t be grumpy, help me to improve).
This is all for now folks, I hope this can be useful for you.
Related links:
Agile’s origins and values
Roles on Agile Teams: From Small to Large Teams
What Is Agile?These are some recommended books to know more:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Finalmente este es el último video del primer capítulo Explorando La Administracion De Proyectos que forma parte del curso gratuito en video de Introducción a la Administración de Proyectos, así que ahora tocó el turno de hablar de algunas de las opciones que están diponibles en el mercado de software que le pueden ayudar en su labor como responsable de un proyecto.
Siguiendo la tradición del curso, los videos abordan el tema de manera breve, pero buscando siempre ponerlo a usted en la pista correcta para averigüe más y llegue a sus propias conclusiones. En este video se aborda las características esenciales de:
- Software especializado en gestión de proyectos
- Procesadores documentos
- Hojas de cálculo
- Software para presentaciones
- Consideraciones generales
Todos los videos previos están disponibles en YouTube o si prefiere, en los siguientes enlaces:
- Definición de Proyecto
- Definición de Gestión de Proyectos
- Lo Necesario Para Ser Un Administrador de Proyectos
- Los Cinco Procesos De La Administración de Proyectos
- Cascada VS Agile
Estos videos forman parte del primer capítulo del curso Explorando La Administracion De Proyectos. La estructura del curso puede verla aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.
Recuerde que YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones y todo eso que los youtubers siempre piden. También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica (sólo los videos que lo ameriten).
Con usted el último video de este capítulo Opciones Software Para La Administración de Proyectos:
Algunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Winds of Change
Much is heard about Agile, Agile project management or the “Agile methodology” as something from the 21st century, but actually, the origin and Agile values began to take shape a little earlier. The 90s were a very interesting decade, MTV had its best moment, the Grunge music invaded the radio and the Internet came to the life of the masses. Along with the Internet boom, the way of making software changed completely, companies began to learn how to create software on a large scale and for interconnected users all over the world, which brought new demands. In the search for success, many of these companies began to import “good practices” from other industries expecting good results, which in the end were mixed in many cases (see Waterfall Model).
Many electromechanical systems were already beginning to be replaced by electronic systems, and sometime later the software began to have more and more relevance, but the development and interaction of these elements were trapped in predictive models that tried to know all elements involved in a system of beforehand, which were (and still are) very difficult to establish at the beginning of software projects with high levels of uncertainty, which has since caused very long development periods with hard-to-predict end dates. This situation led to the frustration of many leaders, who despite the situation were creating and adapting their own techniques, methods, and frameworks to the traditional models of development, which eventually gave rise to the first winks of Agile thinking.
Agile is born
After several previous meetings, in February of 2001, a group of professionals had a new and now famous meeting whose main contribution was The Agile Manifesto. This manifesto was written and signed by seventeen software development leaders (now known as the Agile Community). Their document gave a name to how this group was developing software and provided a list of Agile value statements:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
And this group added:That is, while there is value in the items on the right, we value the items on the left more.
You can know more about history and the original manifesto at agilemanifesto.org
In particular, these opinion leaders looked for ways to quickly build functional software and put it in the hands of end users. This quick delivery approach provided a couple of important benefits. First, it allowed users to get some of the business benefits of the new software faster. Second, it allowed the software team to obtain quick feedback on the scope and direction of software projects on a regular basis. In other words, the Agile approach was born.
Behind the Agile Value Statements
You already know the list of value statements, but let’s see what are the reasons behind them:
Value people and interactions over processes and tools. Those of us who have a path in the development world know that a team with great people works well even using mediocre tools also these teams always overcome other dysfunctional teams with mediocre people who have excellent tools and processes. If people are treated as disposable pieces there will be no process, tool or methodology capable of saving their projects from failing. Good development processes recognize the strengths (and weaknesses) of individuals and take advantage of it instead of trying to make everyone homogeneous.
Value software that works over the comprehensive documentation. Because it leads us to have incrementally improved versions of the product at the end of each iteration. This allows us to collect early and often, some feedback about the product, and the process allows us to know if we should correct the course of action, make adjustments or move forward with the same vision. As the developed software grows with each iteration, it can be shown to the probable or real users. All this facilitates the relationship with customers and improves the chances of success.
Value the collaboration with the customers over contracts negotiation. Because in order to create Agile teams we must seek that all parties involved in the project work to achieve the same set of goals. Contract negotiation sometimes conflicts with the development team and the customer from the beginning. I think the multiplayer online battle arena games are a great example, personally, I like games like Heroes of the Storm o League of Legends. These are cooperative games where teams with five members are formed, the objective is that the team must destroy the base of the enemy by working together. All players win, or all players lose. These matches are surprisingly fun, and what we would like, for software development teams and customers, is to come together with this same attitude of collaboration and shared goals. Yes, contracts are often necessary, but the terms and details of a contract can exert a great negative influence on the different parties involved, and turn a collaborative environment into an inner competitive one.
Value responding to change over following a plan. Because the main objective is to provide the greatest possible amount of value to the project’s customers and users. In large and/or complex projects, you will find that it is very difficult even for users and/or customers, to know every detail of each feature they want. It is inevitable that users come with new ideas, or that they decide that some critical features initially are no longer so. For an Agile team, a plan is a vision of the future, but many points of view are possible and environmental factors can change over the time. As a team gains knowledge and experience about a project, the plan should be updated accordingly.
With the four Agile Values Statements from the Agile Manifesto in mind, I think you can begin to understand what it means to have an Agile approach to estimating and planning.
Sorry about my English I’m not a natural speaker (don’t be grumpy, help me to improve 🙂 ).
Related links:
To agility and beyond: The history—and legacy—of agile development
What Scrum Master Certification to Choose?
These are some books to know more:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Agile / Cursos / CoursesEste es un video que no pensé incluir cuando estaba diseñando el curso gratuito en video de Introducción a la Administración de Proyectos, pero recordé que hay muchas personas que aun siguen discutiendo y enfrentado los modelos ágiles y los modelos tradicionales de gestión de proyectos, cual si fueran personajes de Street Fighter. Me imagino las pantallas arcade de mi infancia mostrando Cascada Vs Agile, RUP VS Scrum, PSP VS XP, cuando en realidad se trata comprender el contexto de su proyecto para aplicar el enfoque más adecuado.
Finalmente he creado para usted el quinto video de este curso en donde se explica en que situaciones en las cuales debería de aplicar estas aproximaciones de administración de proyectos y cual es su relación con los cinco grupos de procesos del Project Manament Institute o PMI independientemente de pasiones mal ubicadas por marcos de trabajo o técnicas específcas. En este video encontrará:
- Modelo de Cascada, Tradicional o Waterfall
- Modelo Ágil o Agile
- Su relación con los grupos de procesos
Todos los videos previos están disponibles en YouTube o si prefiere, en los siguientes enlaces:
- Definición de Proyecto
- Definición de Gestión de Proyectos
- Lo Necesario Para Ser Un Administrador de Proyectos
- Los Cinco Procesos De La Administración de Proyectos
Estos videos forman parte del primer capítulo del curso Explorando La Administracion De Proyectos. La estructura del curso puede verla aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.
Recuerde que YouTube vive de vistas, likes y suscriptores (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones y todo eso que los youtubers siempre piden. También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica (sólo los videos que lo ameriten).
Sin más el quinto video Cascada VS Agile del curso de Introducción a la Administración de Proyectos, del Capítulo 1 Explorando la Administración de Proyectos:
Algunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Agile / Cursos / Courses / IT / Scrum
Aquí está el cuarto video del curso gratuito en video de Introducción a la Administración de Proyectos desde cero. Esta vez se abordarán los cinco grupo de procesos de la administración de proyectos de acuerdo al Project Manament Institute o PMI. En mi opinión el PMI en su Project Management Body of Knowledge o PMBOK es donde mejor engloban los procesos generales y las áres de conocimiento requeridas para la gestión de proyectos; independientemente de metodologías, técnicas o herramientas.
En el video se explica brevemente la relación entre los cinco grupo de procesos de la administración de proyecto y las preguntas que nos planteamos en el video Definición de Gestión de Proyectos. Los temas tratados en el video son:
- Inicio
- Planeación
- Ejecución
- Monitoreo y Control
- Cierre
Todos los videos previos están disponibles en YouTube o si prefiere, en los siguientes enlaces:
- Definición de Proyecto (Video)
- Definición de Gestión de Proyectos
- Lo Necesario Para Ser Un Administrador de Proyectos
Estos videos forman parte del primer capítulo del curso Explorando La Administracion De Proyectos. La estructura del curso puede verla aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.
El mundo de YouTube vive de vistas, likes y suscripciones (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones y todo eso que los youtubers siempre piden. También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica (sólo los videos que lo ameriten).
Como parte de Introducción a la Administración de Proyectos, del Capítulo 1 Explorando la Administración de Proyectos tenemos este cuarto video:
Algunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Agile / Cursos / Courses / IT / Scrum
Ahora tenemos el tercer video del curso gratuito en video de Introducción a la Administración de Proyectos desde cero. En esta oportunidad veremos lo necesario para ser un administrador de proyecto o project manager, veremos cuál es el perfil general que este rol require para hacer una adecuada gestión de proyectos, habilidades como:
- Habilidades técnicas
- Comprensión del negocio
- Habilidades interpersonales
- Liderazgo
El primer y segundo video están disponibles en YouTube o si prefiere, en los siguientes enlaces:
- Definición de Proyecto (Video)
- Definición de Gestión de Proyectos
- Los Cinco Procesos De La Administración De Proyectos
El mundo de YouTube vive de vistas, likes y suscripciones (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares y todo eso que los youtubers siempre piden. También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa y además pueden obtener:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica (sólo los videos que lo ameriten).
La estructura del curso puede verla aquí, estoy actualizando esta estructura según avanzo en la misma.
*Algo que no mencioné en el video es que este aplica también para Scrum Masters, aunque en la aproximación Scrum este rol cambia un tanto respecto al de Project Manager tradicional, ambos comparten una buena cantidad de reponsabilidades y características.
Sin más el tercer video de Introducción a la Administración de Proyectos, del Capítulo 1 Explorando la Administración de Proyectos. Este tercer video se titula Lo Necesario Para Ser Administrador de Proyectos:
Algunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Revelación
Hacer la estimación y la planeación del desarrollo de un producto puede ser una tarea desalentadora que se hace más complicada por nuestra ignorancia o mala interpretación acerca de los proyectos, como concepto y en proyectos específicos. Hace tiempo leí (enlaces al final) que un proyecto no debía ser visto sólo como una secuencia de pasos, sino que también debía ser visto como un flujo rápido que genera nuevas capacidades y nuevo conocimiento. Las nuevas capacidades se entregan como parte del nuevo producto y el nuevo conocimiento se utiliza para hacer un mejor producto (Cohn 2006). Esto es la base para el enfoque de la Planificación Agile sobre la planeación.
Al comenzar a leer sobre administración de proyectos, trabajaba como desarrollador, y esa frase (del párrafo anterior) fué una de mis primeras revelaciones serias acerca de porque trabajaba tan duro codificando para funcionalidades que al final no se utilizaban o bien en proyectos que no lograban sus objetivos plenamente. Parte de las fallas de esos proyectos fueron desde luego, a veces no planear en lo absoluto, pero también tratar de planear todo desde el principio.
Plan En un proyecto Agile utilizamos las nuevas capacidades y el nuevo conocimiento obtenido como guía para el trabajo mismo que se está realizando. El conocimiento obtenido puede ser acerca del producto o del mismo proyecto en general, lo importante es que este nuevo conocimiento nos da mejor idea de cómo debería ser el producto en el cual trabajamos o bien se convierte en mejor entendimiento sobre una tecnología, sobre el equipo, sobre los riesgos, etc.
Cuando pretendemos planear todo desde el principio (ni hablar cuando no planeamos) estamos fallando en integrar nuevo conocimiento al plan, y por lo tanto eso nos lleva a caer en suposiciones erróneas, como creer que estamos incluyendo TODO lo necesario en nuestro plan (lo que en el mundo del software rara vez sucede).
Mis amigos desarrolladores son mayormente gordos y feos (pero aún así los quiero 😃) y no les gusta correr (ejercitarse, hacer cardio, etc.) , pero a mí sí, por lo que utilizaré la siguiente analogía: Una aproximación tradicional a un proyecto puede ser como una carrera de 10km donde usted sabe exactamente dónde está la meta y trata de alcanzarla tan rápido como sea posible. Un proyecto Agile es como cuando usted se toma el tiempo y ve que tan lejos puede llegar en 60 minutos. Un equipo Agile sabe cuándo termina, pero no exactamente que entregará al final. Por lo tanto, planear se convierte en proceso en donde crean y revisan objetivos periódicamente que eventualmente llevan a una meta de más largo término.
Niveles de planificación Agile
Cuando estamos preparando los objetivos de un plan es importante reconocer que no podemos ver más allá de cierto horizonte y que la exactitud de nuestro horizonte será cada vez menor entre más lejos queramos ver. En mis cursos menciono los primeros capítulos de una serie de TV llamada Vikings en donde plantean someramente el uso regular de un compás solar, un piedra solar y cuervos para poder corregir el rumbo periódicamente y mantener un curso correcto; de esta misma manera nosotros debemos revisar el estado de nuestro proyecto y ajustar nuestro plan de acuerdo a ello. Desde este punto ya estamos hablando de la elaboración de una planeación estratégica con el enfoque Agile.
Como ya expresé, el riesgo de un plan se incrementa de acuerdo a que tan lejos en el futuro queramos planear, por ello cada cierto tiempo debemos levantar nuestra vista para ver el nuevo horizonte y ajustar el plan. Los equipos Agile hacen esto planeando en por lo menos 3 distintos horizontes (podrían ser más dependiendo de la aproximación de su organización, pero en esta entrada solo explicare estos). Los 3 horizontes son el Release (Liberación), Iteración y Diaria (actual). Puede tomar como referencia el siguiente diagrama (este no es un estándar, puede encontrar diferentes diagramas similares, pero los 3 horizontes principales no cambian):
Niveles de la Planificación Agile Planificación del Release (Liberación).
Aquí determinamos respuestas a preguntas que se relacionan con el alcance, el calendario y los recursos del proyecto. Este plan debe ser actualizado a lo largo del proyecto, usualmente al inicio de cada iteración para reflejar las expectativas actuales que serán incluidas en el Release.
Planificación de la Iteración.
Esta se lleva a cabo al inicio de cada iteración y basada en el trabajo que se hizo en la iteración anterior (si no es la primera desde luego). El cliente o sus representantes (el Product Owner) deben identificar los elementos de mayor prioridad en los cuales el equipo concentrará sus esfuerzos en la nueva iteración. Esto porque estamos en un horizonte más cercano que el del Release. En este horizonte se establecen las tareas requeridas para obtener una parte funcional y probada de nuestro producto.
Planificación Diaria.
Puede sonar muy excesivo (y quizá lo es) llamar planificación a este horizonte, esto no son más que reuniones diarias e informales (que usualmente se hacen de pie ya que solo deben durar unos minutos) en donde se sincronizan los esfuerzos diarios individualmente. Esto es, que cada miembro del equipo comparte que ha hecho el día anterior, que piensa hacer hoy y comunica los obstáculos que afronta.
Con estos tres horizontes (Release, Iteración y Diaria) los equipos ágiles se concentran sólo en lo que es visible e importante en el plan que han creado. De esta manera han adoptado el enfoque de la planificación Agile.
Condiciones de Satisfacción.
En una futura entrada dedicaré más detalle a esto (lo merece) pero no quiero dejar de mencionar el tema en esta misma entrada, por lo menos de manera breve. Todo proyecto debe comenzar con una meta, quizá de esta se deriven varios objetivos relacionados con fechas, presupuesto, recursos humanos, etc., pero típicamente solo habrá una meta. No dé por hecho que usted debe crear el mejor auto del mundo, la mejor puerta del mundo, el mejor ERP del mundo; los objetivos sólo deben alinearse con las condiciones de satisfacción del Producto Owner (la voz del cliente); esto es, los criterios que serán utilizados para evaluar y determinar el éxito del proyecto.
Lo pondré de otra forma, hace mucho tiempo, cuando estaba en la secundaria era común que a la clase entera nos asignaran escribir un artículo sobre un libro, y de inmediato aparecía la pregunta obligada al profesor, la cual era qué tan largo debía ser artículo. El respondía algo así como “cinco páginas”, entonces conociamos su primera Condición de Satisfacción. Hubo, por supuesto, una serie de condiciones adicionales de satisfacción no escritas, como que el documento estubiera bien escrito, que fuera mi propio trabajo (no plagios), sin faltas de ortografía, etc.
Al comienzo de la planificación Agile del Release o lanzamiento, el equipo y el propietario del producto exploran en colaboración las condiciones de satisfacción del propietario del producto. Estos incluyen los elementos habituales (alcance, calendario, presupuesto y calidad), aunque los equipos ágiles suelen prefieren tratar la calidad como no negociable. El equipo y el propietario del producto buscan formas de cumplir con todas las condiciones de satisfacción. El propietario del producto puede, por ejemplo, estar igualmente satisfecho con un Release en cinco meses que incluya un conjunto de historias de usuarios, que con un sólo lanzamiento de un mes que incluya historias de usuarios adicionales.
A veces, sin embargo, no se pueden cumplir todas las condiciones de satisfacción del propietario del producto. El equipo puede construir el mejor procesador de textos del mundo, pero no pueden construirlo para el próximo mes. Cuando no se puede encontrar una solución factible, las condiciones de satisfacción deben cambiar. Debido a esto, la planificación del lanzamiento y la exploración de las condiciones de satisfacción del propietario del producto son altamente iterativas
Conclusión
Los proyectos deben considerarse como una generación rápida y confiable de un flujo de nuevas capacidades útiles y nuevos conocimientos, en lugar de solo la ejecución de una serie de pasos. Los proyectos generan dos tipos de conocimiento nuevo: conocimiento sobre el producto o servicio y conocimiento sobre el proyecto. Este conocimiento debe ser validado para evitar trabajo infructuoso (waste).
La siguiente imagen muestra como la planifiación Agile existe dentro de una dinámica que busca adaptar conocimiento de manera pronta y altamente iterativa (como ya se mencionó). Hemos basado esta ilustración en la propuesta del buen @sdelbecque quien toma en cuenta la filosofía de Lean, con la cual la agilidad es altamente compatible:
Lean Agile Enlaces relacionados:
El Origen Y Los Valores De Agile
Planeación, Cono de Incertidumbre y Estimaciones en IT
Estos son alguno libros recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Administración / Management / Administración de Proyectos / Project Management / Agile / Cursos / Courses / IT / Scrum
En esta ocasión estoy emprendiendo algo nuevo, esto es un curso gratuito en video de Introducción a la Administración de Proyectos desde cero. En este video habla de la definición de proyecto con el fin de diferenciarlo de otro tipo de esfuerzos. Se abordan las características esenciales de un proyecto como son:
- Esfuerzo único
- Meta específica
- Fechas de inicio y fin
- Recursos
- Diferencia con operación y cadena de producción.
Como instructor de estos cursos para diferentes compañías, sé que hacerlos de manera presencial tiene una serie de ventajas y requiere cierta dinámica, sin embargo, la realidad es que estos cursos no son precisamente económicos. Debido a esto he decidido hacer una serie de videos cortos preo precisos, que tienen como objetivo compartir las bases de este conocimiento. De manera tal que pueda poner estos conocimientos en práctica o bien aquellos que resulten muy interesados pueden, posteriormente, profundizar aun más pero ya contando con los fundamentos necesarios para abordar conceptos más avanzados.
Mi objetivo es mantener todo el contenido de este curso (y este blog) gratis para todos, pero también es cierto que mantener este esfuerzo vivo es un reto (sobre todo si estudias o trabajas), es por ello que pido su paciencia y apoyo si es que ven alguna imagen o enlace con contenido publicitario. Por otro lado, he abierto un espacio en Patreon donde la gente que así lo desee pueda apoyar para mantener este barco a flote, desde luego las personas que donen obtendrán contenido adicional:
- Video descargable en alta definición.
- Transcripción del contenido.
- Documentos y preguntas de práctica.
En este enlace puede consultar el contenido del curso, puede ver su estructura y decidir el ritmo y el orden en que quiere tomarlo. Los videos que conforman este curso se irán publicando progresivamente. Puede consultar las redes sociales de internet80.com para estar al pendiente de la publicación de cada video.
Sin más preámbulo este es el primer video de Introducción a la Administración de Proyectos, del Capítulo 1 Explorando la Administración de Proyectos. Este primer video se titula Definición de Proyecto:
Algunas publicaciones recomendables para saber más:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
Antes de continuar
Si usted no conoce las cuatro Declaraciones de Valor Agile, lo invito a que antes de continuar le eche un vistazo a la entrada El Origen Y Los Valores De Agile, si ya lo hizo o bien ya conoce estos valores, ahora puede enfocar su atención en como es el enfoque del equipo Agile en la práctica. Las cuatro Declaraciones de Valor Agile juntas suman un proceso altamente iterativo e incremental y entregan código probado al final de cada iteración. Los siguientes puntos cubren en lo general la manera en que un equipo Agile lleva un proyecto:
- Trabaja en unidad
- Trabaja en iteraciones cortas
- Libera algo en cada iteración
- Se enfoca en las prioridades de negocio
- Inspecciona y se adapta
El equipo Agile trabaja en unidad
Desafortunadamente es común ver que analistas de negocios y de sistemas arrojan procesos o requerimientos a diseñadores y programadores cual pelota sobre la barda y sin más continúan con su vida, también hay diseñadores y arquitectos que elaboran sus atractivos diseños sin la más mínima consulta a sus compañeros programadores, o bien programadores talentosos que terminan la parte del sistema que les toca y acto seguido se sacuden las manos y desaparecen; y así podemos seguir con historias tristes. Un equipo Agile exitoso debe tener una mentalidad de “todos estamos en esto juntos”.
Me gusta mucho usar analogías de juegos online, porque son una gran manera de ilustrar lo que sucede en la vida real. Muchos juegos en línea se juegan en equipo, donde cada miembro de dicho equipo tiene un rol. En esos equipos de jugadores existen roles como el healer que cura a sus compañeros, el tank que recibe golpes haciendo de escudo para que el resto ataque más eficientemente, los DPS que se encargan de hacer daño al enemigo y la clase especial que hace algun tipo de daño. Cuando algún jugador no cumple con su rol pone al resto del equipo en desventaja considerable, a veces esto quiebra al resto del equipo por completo. ¡Todos deben trabajar como uno!
Así como sucede en estos juegos los equipo ágiles también tienen roles, y vale la pena identificarlos de manera general:
Product Owner
Las responsabilidades principales del product owner incluyen el asegurarse de que todo el equipo comparte la misma visión para el proyecto, estableciendo prioridades de manera que las funcionalidades que aportan mayor valor al negocio sean siempre en las que se trabaja. Tomar decisiones que lleven al mejor retorno de inversión del proyecto y la satisfacción de usuarios finales es la máxima prioridad.
El cliente
El cliente es la persona que tomó la decisión de financiar el proyecto, usualmente representa a un grupo o división. En estos casos es común que este rol se combine con el de product owner. En otros proyectos puede ser que el cliente sea un usuario.
Desarrollador
En el contexto de equipos agile un desarrollador se usa en un contexto amplio, esto es que un desarrollador puede ser un programador, un diseñador gráfico, un ingeniero de base de datos, expertos en experiencia de usuario, arquitectos, etc.
Project manager
Hay que tomar esto con algo de cuidado, porque un agile project manager se enfoca más en el liderazgo que en el management o (gestión tradicional del proyecto). En algunos proyectos y marcos de trabajo ágiles la persona encargada de este rol comparte las responsabilidades de un project manager tradicional con otros roles como el de product owner. También puede hacerse cargo de asesorar en la adopción y comprensión del enfoque agile. En proyectos muy pequeños puede incluso tener un rol como desarrollador, pero esta práctica no recomendable.
Un equipo Agile trabaja en iteraciones cortas
Ya lo mencionaba anteriormente, en proyectos ágiles no hay una delineación de fases demasiado marcada. No hay un establecimiento exhaustivo de requerimientos al comienzo del proyecto seguido de un análisis, no hay fase de diseño de arquitectura para todo el proyecto. Una vez que el proyecto inicia de verdad, todo el trabajo (análisis, diseño codificación, testing, etc.) ocurre junto dentro de una iteración.
Las iteraciones se hacen dentro de espacio de tiempo delimitado previamente (timeboxed). Esto significa que cada iteración se termina en el tiempo acordado sin excusas, incluso aunque las funcionalidades previstas no se terminen. Las iteraciones son a menudo muy cortas. La mayoría de los equipos ágiles utilizan iteraciones de entre una semana y cuatro semanas.
Un equipo Agile libera algo en cada iteración
Algo crucial en cada iteración es que dentro de su espacio de tiempo uno o más requerimientos se transformen en software codificado, probado y potencialmente empaquetable. En la realidad esto no significa que algo se les entregue a los usuarios finales, pero se debe estar en posibilidades de hacerlo. Las iteraciones una a una van sumando la construcción de solo algunas funcionalidades, de esta manera se va obteniendo un desarrollo incremental al ir de una iteración a la siguiente.
Debido a que una sola iteración usualmente no provee tiempo suficiente para desarrollar todas las funcionalidades que el cliente desea, se creó el concepto de release. Un release comprende una o más (casi siempre más) iteraciones. Los releases pueden ocurrir en una gran variedad de intervalos, pero es común que los releases duren entre 2 y 6 meses. Al terminar un release a este le puede seguir otro release y a su vez a este le puede seguir otro, así hasta terminar el proyecto.
Un equipo Agile se enfoca en las prioridades del negocio
Los equipos ágiles demuestran un compromiso con las prioridades comerciales de dos maneras. Primero, entregan funcionalidades en el orden especificado por el product owner, de quien se espera priorice y combine características en un release que optimiza el retorno de inversión de la organización en el proyecto. Para lograr esto, se crea un plan para el release basado en las capacidades del equipo y en una lista priorizada de las nuevas funcionalidades deseadas. Para que el product owner tenga mayor flexibilidad en la priorización, las características deben ser escritas minimizando las dependencias técnicas entre ellas.
En segundo lugar, los equipos ágiles se centran en completar y entregar funcionalidades valoradas por el usuario en lugar de completar tareas aisladas.
Un equipo Agile inspecciona y adapta
Siempre es bueno crear un plan, pero el plan creado al inicio no garantiza lo que ocurrirá en el futuro. De hecho un plan es solo una suposición en un punto del tiempo. Si usted vive perseguido por la Ley de Murphy como yo 😀, habrá muchas cosas que conspirarán contra el plan. El personal del proyecto puede ir o venir, las tecnologías funcionarán mejor o peor de lo esperado, los usuarios cambiarán de opinión, los competidores pueden obligarnos a responder de manera diferente o más rápida, y así sucesivamente. Los equipos ágiles ven que cada cambio representa tanto una oportunidad como la necesidad de actualizar el plan para mejorar y reflejar la realidad de la situación actual.
Al comienzo de cada nueva iteración, un equipo agile incorpora todo el nuevo conocimiento obtenido en la iteración anterior y se adapta en consecuencia. Si un equipo aprendió algo que probablemente afecte la precisión o el valor del plan, hay que actualizar el plan. Esto es, que quizá el quipo descubrió que han sobreestimado o subestimado su capacidad de progreso (capacity) y que un cierto tipo de trabajo consume más tiempo del que se pensó anteriormente.
De la misma forma el plan se puede ver afectado por el conocimiento que el product owner ha ganado de los usuarios. Quizá por la retroalimentación obtenida de una iteración previa el product owner ha aprendido que los usuarios quieren ver más de algún tipo de funcionalidad y ya no valoran tanto otra que havían considerado. Este tipo de situaciones pueden alterar el plan, de manera que hay que adaptar el mismo para mejorar su valor.
Enlaces relacionados:
Roles on Agile Teams: From Small to Large Teams
El Origen Y Los Valores De Agile
What Is Agile?
Planeación, Cono de Incertidumbre y Estimaciones en ITEstos son alguno libros recomendables para saber más:
¡Caulquier ayuda en bienvenida para mantener este esfuerzo vivo! PayPal Account BTC (Bech32): bc1qx6f8nczr5ram6d57svlnsfmk5mhu6lsr9q7mxw BTC: 1DDcWbphm1bKMvWruotNKLSM8ypVaHg5Nv ETH: 0x58D137fb142D946bCD815f0ded0fa3b3fE5AB3BF
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
No Comment
About This Post
Some years ago I get interested in Agile software development and I have been using the Scrum product development framework in several projects, but eventually, I decided to formalize this knowledge starting with a Scrum Master certification. When I talked about this with some friends and acquaintances I was surprised when a lot of them started to ask me about it with many doubts and confusions.
To try to shed some light, I will get into a heated territory within the Scrum community, sharing my experience while and I will try to answer several of the first questions that come to mind when you’re interested in a Scrum certification. It should be noted that nobody is paying me for my opinion (I wish….).
Why get a Scrum Master certification?
I was a developer who finds himself involved with Agile and Scrum some years ago (more by emergency than by good judgment) in order to finish projects near of collapse. Little by little and still with many setbacks but also proposing good practices to the management and in an active role, the teams which I was part of, successfully managed to get out of several quagmires, but the truth is that I never felt the need to obtain any formal validation for that knowledge. Eventually, fate, time and several fellow developers pushed me to take a more active role on the project management side, but I found that several clients and employers were asking me for certified Skills in Scrum and/or Project Management (foolish!).
Around 2013, while I was looking for a new job, I began to notice that more and more vacancies, for project managers and even developers, required Scrum knowledge. Considering that many times in the past managers, directors and even project managers asked me what was that Scrum thing, I noticed that things were changing in a remarkable way.
So, the message was clear. If I wanted to have a better chance of finding interesting (and reasonably paid) jobs, I had to certify my knowledge. But that was the easy part; I spent a good amount of time researching what my options were. In the rest of this post, I condensed what I learned about Scrum certifications under the Scrum Master role.
Scrum Master Certifications
The first thing is to clarify that there are several organizations offering Scrum Master certifications, the best known are:
- Certified Scrum Master (CSM) by Scrum Alliance.
- Professional Scrum Master (PSM) by Scrum.org.
- Scrum Master Certified (SMC) by SCRUMstudy.
- SAFe Scrum Master by Scaled Agile Framework
This post only addresses these four certifications, but there are others that probably you want to consider:
- PMI_ACP. Project Management Institute Agile Certified Practitioner is offered by the Project Management Institute.
- ICAgile Certifications. Certifications offered by the International Consortium for Agile.
*Please note that all figures presented are valid as of the date of publication of this entry and may change without prior notice.
Certified Scrum Master (CSM) from Scrum Alliance
This is the most known and long-lived certification of all. The Scrum Alliance was founded by one of the two creators of Scrum, Ken Schwaber along with other heavyweights of Agile and Scrum world such as Esther Derby and Mike Cohn.
However, today there are some criticisms for this certification because although it is the most widely recognized certification, it’s open knowledge that all certifications issued before 2012 did not require any evaluation, being the only requirement to attend an official course of the Scrum Alliance. In response, the Scrum Alliance has changed the Certified Scrum Master (CSM) certification process to the following mandatory steps:
- Familiarize yourself with the basic concepts of Scrum.
- Attend the official CSM course.
- Obtain the certificate that verifies the completion of the CSM course and passes the CSM evaluation with a minimum score of 69% (still considered a low percentage by some practitioners).
The courses can only be taught by the Certified Scrum Trainers, but as the courses are not approved, it seems that the quality of each course depends on the skills, experience, and materials that each instructor can offer independently.
The course cost includes the evaluation, can change from region to region, but ranges are between *$850 USD and *$1,300 USD. To maintain valid CSM certification, it must be renewed every two years at a cost of *$100 USD but the Scrum Alliance also introduced the Scrum Education Units, which can be used to renew its certifications. In the same vein, for those holding PMI certifications, these courses also provide PDUs.
Update 2018: The Scrum Alliance integrated new certifications to its offer, including one more as Scrum Master. Following a similar strategy to Scrum.org a certification called Advanced Certified ScrumMaster (A-CSM) have been added, which has as requirements:
- Attend to a required A-CSM course.
- Successfully complete the previous or later work to the course that the instructor may consider necessary in order to meet the learning goals.
- Validate at least one year of work experience specific to the role of ScrumMaster (within the past five years). This point is important because at least 12 months must be logged since you got your CSM certification before you can try for A-CSM.
- Hold an active Certified ScrumMaster (CSM) certification with the Scrum Alliance.
The cost of the course and the right to A-CSM exam also can vary depending on the region but according to our investigation, this is about $2500 USD.
Professional Scrum Master (PSM) from Scrum.org
The Scrum Alliance and Ken Schwaber had a separation in 2009 and this led to the latter founding of a new organization called Scrum.org, which offers courses and certifications for PSM among others. After the Scrum Alliance certification, this is the most widespread Scrum Master certification, gaining more and more recognition in the industry. Something different in Scrum.org is they don’t offer just a single certification, you can get three different levels of Scrum Master certification from them, this is the PSM I, PSM II and PSM III.
It’s important to mention that today a large part of the Scrum community address to these certifications as the most difficult to obtain, because PSM I, PSM II and PSM III require evaluations with minimum scores of 85% and since they include questions of high difficulty, being required to get the PSM I to be able to obtain the PSM II, and these two before being able to try the PSM III test. Several sources reported that there is a relatively high amount of people who, even with experience in Scrum or other certifications, fail these assessments.
In spite of how intimidating this may sound, an encouraging point is that none of these evaluations require the applicant to attend a course, so in theory, these certifications can be achieved with the appropriate time for study, revision and/or experience, in addition, these certifications do not need to be renewed.
The cost for the PSM I evaluation is *$150 USD, for the PSM II it’s *$250 USD and for the PSM III it’s *$500 USD, with the right to one single attempt.
The optional Professional Scrum Master course offered by Scrum.org can only be taught by the Professional Scrum Trainers, who have approved materials. The costs of the courses seem to go between *$1295 and *$1995 USD.
As with the Scrum Alliance courses, PMI certification holders can obtain PDUs for the PSM courses.
PSM I Exam Simulator: In order to help those who want this certification, in internet80 we have undertaken the task of developing a simulator of this test completely free. The simulator is in the testing phase but is now available to everyone. Evaluate your knowledge about the Scrum framework now here: PSM I Exam Simulator 1
Scrum Master Certified (SMC) from SCRUMstudy
This is the most controversial certification of those mentioned in this post and within the Scrum community, So far I don’t know who is/are exactly the founders of this organization, but they have the credit of having created a free book in its digital version, called the SBOK Guide or Scrum Body of Knowledge whose main author is Tridibesh Satpathy. This organization offers SCM certification.
The SCM certification bases its assessment on the SBOK Guide, which has a process approach (similar to the PMI’s PMBOK), and another concepts called principles and aspects, that is, everything is in the context of the interpretation made by the authors about Scrum in the SBOK Guide, which has caused this organization to have serious differences with many practitioners and founders of Scrum who even took part in the creation of the Agile manifesto and therefore with a large part of the Scrum community; although on the other hand, it has achieved a certain amount of acceptance from the industry.
One point against this certification, which may be eventually important for some people, is that the most popular Scrum scaling frameworks such as SAFe, LeSS or Nexus are based on the Scrum Guide and do not recognize SBOK. This may be important since being SAFe the most influential scaling framework so far, and if you want to obtain a certification as SAFe Advanced Scrum Master, the Scaled Agile organization does NOT consider relevant the SCRUMstudy certification.
Update 2017: The Scaled Agile Framework organization who provides SAFe, now offers its own Scrum Master certification, called SAFe Scrum Master (SSM), don’t get confused with SAFe Advanced Scrum Master certification, this one puts a pre-prerequisite neither CSM nor PSM anymore, but put them as highly suggested in order to take its certification course.
The minimum score in their respective evaluation to obtain this certification is of *95%, although in my research I have obtained testimonies and mixed comments on their difficulty, they do not have prerequisites although their SBOK must be strongly studied since apparently the exam attacks only the perspective of this guide.
The cost of the test is *$450 USD with *3 attempts and requires *40 re-certification units every *3 years (these units are obtained by different activities).
According to my research, the SMC course content is approved and can only be provided by the SCRUMstudy Certified Trainers whose are based mostly on the SBOK guide, the costs are around *$450 USD, but costs can change between regions and partners. The testimonials I got were quite mixed, I got good comments about the courses materials offered but one thing I was told several times is that when the trainers face questions and/or scenarios outside the context of the SBOK Guide, these instructors really struggle a lot to solve doubts from the “real world”. SCRUMstudy has several partners to offer their courses.
PDUs are also offered if you take the SMC course.
Update 2018: SCRUMstudy has followed the strategy that Scrum.org started and also Scrum Alliance followed. Now, this organization offers an advanced Scrum Master certification which is called Expert Scrum Master Certified (ESMC), and its requirements are:
- Having three years of experience in Scrum / Agile project management.
- Hold the certifications SMC, SAMC y SPOC.
- Submit 500 words write up about two Scrum / Agile projects.
- The official web page also indicates that you can attend to a 2-days ESMC face to face training, of course, provided by SCRUMstudy, however, doesn’t clearly indicate whether this is mandatory, substitute or facilitates any of the previous requirements.
The cost of the exam to obtain this certification at the time of this publication is $800 USD which may vary depending on the region. You will also have to obtain 60 RCUs every 3 years to maintain this certification.
SAFe Scrum Master
I added this certification this year (2018) because this emerged in late 2016 (months after this post), don’t get confused with the SAFe Advanced Scrum Master certification. SAFe focuses on large organizations Agile model implementation and today is the most popular escalation framework, but it’s not the only one (there are others such as Nexus, LeSS, DaD, and others). But let’s take it one step at a time because I’ve discovered out that this certification has aroused some confusion.
Previously the Scaled Agile Framework only offered the SAFe Advanced Scrum Master which is totally dedicated to this Scrum scaling framework approach, and within its prerequisites, it was required to have either CSM or PSM certifications.
Now offers its own “basic” certification which uses the Scrum Guide approach but also introduces its SAFe escalation framework approach early on, this is the SAFe Scrum Master certification. The prerequisites for this certification are knowing the agile approach and knowing the Scrum, Kanban and XP frameworks, and at the same time having first-hand experience in the software and hardware development process, and of course to take obligatorily the SAFe Scrum Master course.
According to the testimonies I’ve got, the contents of this course are homologated and are abundant, I didn’t find anything about the instructor’s qualifications who teach the courses, but apparently, both the instructors and the exam are totally oriented to the content provided during it. The first attempt for this certification test is included in the course cost (which varies between countries and regions), each additional attempt costs *$50 USD, it is a web-based test (is not clear for me if you can take the this from anywhere), to approve requires between *33 and 45 correct answers (73% of accuracy).
Something good is that just about three years ago you had to travel to the United States to take some of the SAFe courses and exams, but now these are available in several countries on all continents, which speaks of the popularity of this scaling model. Keep in mind that if you get this certification you must renew it *every year at a cost of $100 USD (which is a short-term compared with rest of the certifications).
This course offers PDUs for PMI certification holders and SEUs for those with some Scrum Alliance certifications.
Resumen
- The Certified Scrum Master (CSM) certification is more widely known than the Professional Scrum Master (PSM) and the Scrum Master Certified (SMC).
- The training costs for PSM are (on average) higher than CSM and SMC training courses and are not available in all countries. The costs of CSM are usually higher than SMC.
- The costs of acquiring and maintaining CSM certification are higher than those for SMC and PSM, the latter being the cheapest since no payment is required to maintain the certification.
- The value of CSM certification is very questioned especially if it was issued before 2012 (it was granted without evaluation).
- The materials and the quality of the courses for CSM can vary greatly since they are not approved.
- The materials provided for PSM and SMC in their training are approved (and according to several testimonies are usually good).
- The SMC certification is based on the practices described in the SBOK and not necessarily as described in the Scrum Guide (text by the creators of Scrum).
- The value of the SMC certification is questioned by many important members and organizations in the Scrum community.
- The most important scaling framework at the moment (SAFe) strongly suggests holding either the SAFe Scrum Master (SSM), Certified Scrum Master (CSM) or Professional Scrum Master (PSM) certifications in order to obtain several of its certifications including the SAFe Advanced Scrum Master (SASM).
- SAFe offers the SAFe Scrum Master (SSM) certification which is oriented to Scrum scaling in large organizations but is not the only escalation model and not every organization have or plan to use this approach.
- The SAFe Scrum Master (SSM) certification must be renewed every year for a cost, which is short-term compared with the rest of the certification.
* Correct figures at the time of publication. They can change without notice.
Sorry about my English I’m not a natural speaker (don’t be grumpy, help me to improve 🙂 ).
Related Links:
PSM I FREE Exam Simulator 1
Agile’s origins and valuesSome book that can be interesting for you:
Emmanuel Herrera
IT professional with several years of experience in management and systems development with different goals within public and private sectors.
Emmanuel worked through development and management layers, transitioning from developer and team development leader to Project Manager, Project Coordinator, and eventually to Scrum Master, Product Owner, and Agile Coach.
Some certifications include: PSM, PSPO, SSM.
