|
Hola {{nombre}},
Trabajas en un equipo de producto o tech. Eso significa que conoces la distancia entre cómo se supone que esto funciona y cómo funciona en la práctica. Las metodologías están, los procesos están, las reuniones también. Y aun así, algo no encaja del todo.
El problema que nadie nombra en voz alta es este: el equipo no sabe qué significa el éxito. No en abstracto. En concreto. En este sprint, para esta funcionalidad, para este trimestre.
Cuando eso no está claro, pasan cosas predecibles:
- El backlog crece más rápido de lo que se entrega.
- Las historias de usuario describen funcionalidad, no comportamiento esperado.
- Los refinements se convierten en negociaciones de alcance, no en conversaciones sobre valor.
- El equipo entrega en velocidad, pero no en impacto.
El problema no es el proceso. Es que el proceso no está conectado a ningún resultado que el equipo pueda ver.
|
La pregunta que cambia las cosas
"¿Qué debería ser diferente para el usuario al final de estas dos semanas?"
Si nadie en el equipo puede responder eso con una frase concreta antes de empezar el sprint, el sprint no tiene dirección. Tiene lista de tareas.
|
No hace falta cambiar el proceso. Hace falta añadir criterio de éxito antes de que el proceso empiece.
El jueves que viene: OKR para el equipo — cómo usarlos sin que sean otra capa de reporting impuesta desde dirección.
— Alex
ITNOVE · Consultoría Agile, OKR e IA
|