¿Es compatible ser Agile y tener un Roadmap?

Tu empresa necesita un Roadmap a 1 año vista. Pero eres Agile… ¿Es posible tener un Roadmap y seguir siendo Agile? Sin problema, te contamos cómo hacerlo.

Piensa en un viaje por carretera largo, de unas 20 horas o más. Probablemente tendrás 2 ó 3 rutas para elegir, que dependerán de las necesidades que tengas (tiempo de viaje, peajes, sitios turísticos, etc.) Sabes dónde quieres llegar, y es probable que tengas una ruta elegida. Aunque en realidad hasta cada cruce de caminos, no sabes exactamente que ruta vas a seguir.
De la misma manera, podemos establecer un Roadmap de producto con Agile. No es anti-agile saber a dónde vas, dónde quieres llegar o que esté tu empresa en el futuro. De hecho, como bien sabes, es básico para cualquier negocio saber hacia dónde se dirige.

Lo que no es Agile es grabar ese Roadmap a fuego, y no abrirnos a la posibilidad de adaptarlo a lo que va ocurriendo en cada etapa del camino. La tensión entre agilidad y un Roadmap planificado es fácil de resolver si la planteamos como una ruta sugerida entre destinos. Si el viaje es lo suficientemente largo, sabemos que habrá desvíos por el camino: atascos, accidentes, obras, un paraje que no conocíamos, necesidades vitales, etc.
Esto lo entendemos, y lo asumimos. ¿Por qué no aplicarlo a nuestro Roadmap? El desafío está en lograr que las partes interesadas en que el Roadmap se cumpla y lleguemos a nuestro destino, entiendan la complejidad Ye incertidumbre inherentes al desarrollo del producto. Esa incertidumbre dificulta disponer de garantías, a menos que los Equipos Scrum recurran a un margen de maniobra excesivo.

Sería como si para ese viaje de 20 ó 22 horas, yo dijera que voy a tardar 30. Estoy sustituyendo adaptarme a la incertidumbre de lo que puede ocurrir por el camino, por un margen exagerado para asegurar que cumplo los tiempos.

Nuestra propuesta

En nuestro clientes resolvemos esta necesidad de disponer de un Roadmap a medio-largo plazo, estableciendo diferentes ciclos PDCA (Plan-Do-Check-Act).

Aunque depende de cada cliente, inicialmente siempre planteamos disponer de un Roadmap a 1 año vista, que marque qué esperamos que ocurra durante el próximo año a nivel de negocio en nuestra empresa. Dónde estamos y dónde queremos estar en 1 año, que necesidades de los clientes deben cubrirse y que objetivos estratégicos del negocio se deben cumplir.

Con el Roadmap a 1 año establecido, planteamos un segundo ciclo bimestral, que establezca qué queremos que ocurra en los siguientes 2 meses, qué parte del producto necesario para cumplir nuestro Roadmap vamos a construir o desarrollar. Marcamos etapas de 2 meses en nuestro viaje.

Además incorporamos un revisión del Roadmap cada 2 meses, revisando lo que hemos completado, lo que no hemos completado, y adaptamos el Roadmap a la realidad de lo ocurrido e incorporamos los cambios que se hayan podido producir en las necesidades de la empresa.

Y como último ciclo, aplicamos Scrum con Sprints de 2 semanas. Sprint a Sprint los Equipos Scrum van construyendo lo comprometido para el bimestre, revisando lo entregado, y promoviendo la mejora continúa para adaptarse a las necesidades cambiantes de la empresa, generar un producto de mayor calidad, etc.

Resumen

Es posible disponer de un Roadmap a 1,2, 3 años vista, lo que necesite nuestra empresa, sin dejar de ser Agile. Sólo tenemos que entenderlo como un viaje en el que vamos cubriendo etapas, y tras cada etapa revisamos y adaptamos nuestro Roadmap.

También te puede interesar.

Como empezar como Scrum Master

Acompañar a equipos es una gran responsabilidad pero es muy gratificante. Cada persona y cada equipo tiene unas necesidades diferentes en función de su realidad. Sin embargo, bajo nuestra experiencia, estos consejos pueden servirte para iniciarte como Scrum Master en un equipo.

Aprendiendo en un Equipo Scrum

El conocimiento compartido potencia a tu equipo. Aquí descubrirás cómo identificar las áreas de conocimiento y favorecer su aprendizaje continuo

Cómo convivir con las incidencias en un Equipo Scrum

En los Equipos Scrum que desarrollan nuevo software y mantienen el ya existente, es muy habitual tener que lidiar con incidencias provocadas por el software en producción. Su gestión es complicada ya que interrumpen directamente nuestro plan para el sprint, y al producto ya priorizado en el Product Backlog.

Burndown y Burnup para el Scrum Master

Como Scrum Master puedes obtener información muy valiosa analizando estos dos gráficos para entender lo que está ocurriendo en tu equipo.

Cómo mejorar tu Scrum Daily

En ocasiones nos encontramos con equipos en los que la Scrum Daily se ha convertido en un evento individualista donde cada miembro del equipo de desarrollo comenta las tareas realizadas durante el día anterior, muchas veces con cierto carácter de reporte. Sin embargo, la daily es un evento colectivo donde a través de la inspección y adaptación se traza un plan de trabajo del día para el equipo.

Scrum para disipar incertidumbre

Scrum es un marco que te puede servir para hacer lo mismo de siempre a trocitos. Sin embargo, puedes utilizar Scrum de manera inteligente y sacarle toda su potencia. ¿Cómo? Orientándolo a generar certezas sobre tu producto o tu mercado.

Cómo facilito una retrospectiva si no soy Scrum Master

Una buena retrospectiva da la oportunidad al equipo de analizar su funcionamiento y establecer mejoras. Te dejamos consejos para facilitarla.

Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

¿Es conveniente tener un Equipo Scrum en exclusiva para Incidencias?

En tus Equipos Scrum os encontráis en una situación en la que la cantidad de incidencias que hay que atender os penalizan demasiado, o la deuda técnica acumulada aumenta en exceso la complejidad de cualquier evolución en software.

La historia de scrum, su primera implementación

Actualmente Scrum es el marco de trabajo más utilizado para implementar modelos Agile. Hoy os contamos como era su primera versión.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

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

ACEPTAR
Aviso de cookies