Las 3 principales quejas que escucho de mis estudiantes y que he visto en los equipos que he apoyado:
Dependencias (ya lo tratamos en la primera entrega de la serie)
Presión de las partes interesadas para asumir el trabajo independientemente de la capacidad
Requisitos poco claros
¿Le resultan familiares? Vamos a centrarnos en la presión de las partes interesadas.
A ver si te suena. Su Propietario de Producto comparte la Visión de nuevo (porque deberían estar compartiéndola continuamente) y luego comparte el Objetivo del Producto. El equipo está centrado y listo para averiguar cómo podemos avanzar para acercarnos a la consecución del objetivo.
Los Desarrolladores traen los elementos del Backlog del Producto que pueden realizar durante el Sprint... ¡desafiándose a sí mismos para ir realmente a por ello! Tenemos un Objetivo del Sprint que podemos apoyar y ver el propósito detrás del trabajo que estamos llevando a cabo. Todo es perfecto. Nos vamos con un plan impresionante.
Al día siguiente, nuestro Propietario de Producto entra con una parte interesada que tiene una "petición urgente". ¿La expectativa? Traer este elemento urgente Y aún así lograr nuestro Objetivo del Sprint, completando todos los PBIs planificados.
Al igual que la última vez, vamos a hacer una comprobación de la realidad. Van a aparecer elementos urgentes. Conocemos los sospechosos habituales: problemas de soporte de producción, ciberseguridad, legales y de cumplimiento. ¿Te suenan? Sin embargo, esto debería ser la excepción, no la regla.
Los otros tipos de interrupciones que vemos son nuevas ideas, cambios en las ideas y otros cambios no urgentes. Si absorbemos los cambios según los caprichos de las partes interesadas, ponemos en peligro nuestro objetivo o trabajamos a un ritmo insostenible. Si ignoramos las ideas y los comentarios de las partes interesadas, también perdemos. Entonces, ¿qué hacer?
Hacer las concesiones explícitas y transparentes.
Cuando llega esa petición urgente, lo primero que hago es dar un paso atrás y preguntarme: ¿es este cambio tan masivo que nuestro actual objetivo del sprint es básicamente obsoleto? Estamos hablando de la adquisición de la empresa, la retirada total del cliente clave o cambios normativos que borran por completo la dirección del producto. Esto es poco frecuente. Noventa y nueve de cada cien veces, la respuesta es no: el Objetivo del Sprint sigue teniendo valor.
Suponiendo que el objetivo sobreviva (que suele ser el caso), lo llevo directamente al equipo. La gente que hace el trabajo es la primera en opinar sobre lo que puede pasar. Nos reunimos rápidamente durante cinco o diez minutos y examinamos el plan al que nos hemos comprometido. ¿Qué podríamos eliminar, aplazar o reducir sin dejar de aportar algo significativo al Objetivo?
No estamos hablando de trabajar horas extra, hacer horas extra los fines de semana o "simplemente esforzarnos más". Eso no son compensaciones; son recetas para el agotamiento. Hablamos de repercusiones reales: abandonar una PBI de menor prioridad, reducir el alcance de una función o posponer algo que sería bueno tener para que llegue el valor principal.
Una vez que el equipo presenta las opciones realistas, el Propietario de Producto se las comunica a las partes interesadas. Se lo explicamos claramente: "Para encajar esto, tenemos que suprimir X o reducir Y. Esto es lo que significa para el objetivo del sprint y el valor que estamos ofreciendo". El PO toma la decisión final -es su responsabilidad-, pero la conversación es transparente. Todo el mundo ve el coste. No hay suposiciones ocultas.
Captura el cambio en el Sprint Backlog para que sea visible para todos. Actualice los elementos, ajuste el alcance y anote lo que se ha eliminado o aplazado. A continuación, anota por qué hemos hecho el cambio y de dónde procede. Un comentario rápido es suficiente: "Se ha añadido un elemento de cumplimiento urgente a petición del departamento jurídico; se ha aplazado el PBI Z para mantener el objetivo". De este modo, con el tiempo, podrás detectar patrones.
¿Se trata de la misma parte interesada que hace peticiones durante cada Sprint? ¿Siempre ganan ciertos tipos de elementos "urgentes"? ¿Seguimos aplazando los mismos tipos de trabajo? Estas percepciones convierten las decisiones puntuales en datos que alimentan mejores conversaciones, límites más firmes y, tal vez, incluso un ajuste de la política más adelante.
Este enfoque da sentido al Sprint, respeta la capacidad del equipo y genera confianza entre las partes interesadas. Empiezan a darse cuenta de que decir "sí" a todo significa en realidad decir "no" a otra cosa: mejor elegirlo juntos.
Así que la próxima vez que llegue una petición "urgente", prueba esto. En primer lugar, haz visibles las compensaciones para el equipo y, a continuación, hazlas transparentes para las partes interesadas. A ver qué cambia. Te sorprenderá ver cómo se hacen muchas más cosas... las que realmente importan.
En la Parte 3, abordaremos el tema de los requisitos poco claros, el tercer gran obstáculo del que siempre oigo hablar. Si estás listo para desatascarte en cualquiera de estos temas, ponte en contacto con Improving. Hemos ayudado a equipos a realizar estos cambios.
