Responder a un cambio antes que seguir un plan

Agile dedica uno de sus cuatro valores a "Responder al cambio antes que seguir un plan". Esta lectura tiene como objetivo aclarar algunas consideraciones importantes al implementar un cambio en el plan de lanzamiento. 

La mejor manera de pensar en cambiar tu plan es dividirlo en tres etapas:

1. Identificar un cambio necesario.

2. Decidir hacer el cambio.

3. Implementar el cambio.

Paso 1: Identificar un cambio necesario.

Primero, ¿Cómo sabes si necesitas cambiar tu plan? Estos son algunos aspectos de tu proyecto que pueden ser candidatos para el cambio: alcance, tiempo y costos (o recursos). Como aprendimos anteriormente, estos se denominan "restricciones triples" y proporcionan un gran framework para evaluar el cambio en proyectos Agile y tradicionales.

● En Agile, el alcance se refiere al contenido de la hoja de ruta del producto, los elementos del Backlog de producto, los entregables previstos del proyecto y los usuarios o clientes previstos. Este es el “qué” del proyecto.

● El tiempo se refiere a los elementos de tiempo o diseño de los entregables durante un período de tiempo. Esto podría incluir la línea de tiempo de la hoja de ruta del producto, el cronograma de lanzamiento o incluso la duración del Sprint. Este es el “cuándo” del proyecto.

● Los costos o recursos hacen referencia a la composición del Equipo de desarrollo, los gerentes de proyectos y los propietarios de productos y otras "personas de negocios", así como el equipo disponible para crear el entregable. Este es el “cómo” del proyecto.

Los proyectos Agile están abiertos a cambios en cualquiera de estas tres áreas, y cualquier interesado del proyecto podría identificar un cambio necesario, incluido el propietario del producto, el gerente de proyectos, el Scrum Master o el propio equipo de desarrollo. Las fuentes de cambios identificados podrían incluir:

● Los comentarios de los clientes sobre los primeros prototipos dan como resultado nuevas características y algunas características eliminadas (cambio de alcance).

● La retrospectiva de Sprint identifica un área de escasez de personal (cambio de costos o recursos).

● Las dependencias críticas del proyecto o las fechas de entrega se han desplazado, lo que ha dado lugar a un cambio en la hoja de ruta del proyecto (programación o cambio de hora).

Paso 2: Decidir hacer el cambio.

A continuación, ¿Cómo decides hacer realmente el cambio? Hay muchos modelos de toma de decisiones disponibles para referencia. Estos son los pasos básicos involucrados en la mayoría de estos modelos:

● Identificar al “responsable de tomar decisiones” Lo mejor es tener una sola persona, generalmente el propietario del producto o un interesado de alto nivel, en el papel de responsable de tomar decisiones para garantizar la coherencia y la responsabilidad.

● Desarrollar y compartir qué factores son importantes para la decisión y recopilar datos de respaldo que ayudarán a quien toma la decisión.

● Analizar abiertamente los beneficios y costos de la decisión. Identificar áreas de incertidumbre y capturar supuestos.

● Documentar la decisión.

Paso 3: Implementar el cambio.

Una vez que se aprueban los cambios, es importante hacer varias cosas:

● Documentar el cambio y el proceso de toma de decisiones. Incluye notas de reuniones, listas de pros y contras, suposiciones y datos que se utilizaron para tomar la decisión de cambiar el proyecto.

● Capturar el cambio en cualquier artefacto afectado. Actualiza cualquier hoja de ruta, acumulación de productos, planes de dotación de personal y fechas de integración, e incluye una referencia a la fuente del cambio para que los interesados puedan consultarlo. Considera usar etiquetas de revisión o fechas en los documentos afectados como "versión 1.2" o "actualizado el 20 de diciembre" para que el equipo pueda reconocer claramente que el documento ha cambiado.

● Compartir el cambio con todos los interesados afectados. Puedes hacerlo de muchas maneras: en persona en reuniones, en documentación y notas de reuniones, y mediante anuncios por correo electrónico.

● Supervisar el cambio durante un cierto período de tiempo. Esto asegura que el equipo brinde apoyo y sea consciente del cambio.

Si el cambio no se aprobó durante la etapa de decisión, aún debes documentar la información y la lógica utilizada para tomar la decisión. Incluso puedes considerar poner un cambio en espera mientras esperas más información para tomar la decisión con mayor confianza.

Fuente:
Coursera-Gestión de Proyectos de Google.