CASO 02
El equipo hacía exactamente lo que se le pedía.
El problema reportado era una baja productividad en ingeniería.
El equipo de desarrollo parecía no cumplir las expectativas y tener dificultades para entregar a tiempo.
Pero al seguir el propio trabajo, surgió un patrón distinto.
Lo que nos dijeron
Una organización de desarrollo tenía problemas de productividad.
El trabajo tardaba más de lo previsto. Las funcionalidades llegaban a revisión pero no se aceptaban. Los lanzamientos se retrasaban.
Desde el lado de producto, la explicación parecía sencilla: el equipo de desarrollo no entregaba de forma consistente lo que se había solicitado.
Si esa explicación era correcta, el lugar obvio donde investigar era la productividad de ingeniería.
Lo que observamos
El equipo trabajaba de forma iterativa.
Antes de la implementación, se discutía una historia y se definía el comportamiento esperado. El equipo de desarrollo implementaba después ese comportamiento durante el sprint.
Los ingenieros no ignoraban esos requisitos.
Los implementaban.
El problema aparecía más tarde.
Durante la revisión, a veces se volvía necesario un comportamiento que no había formado parte de los criterios de aceptación acordados para que el trabajo fuera aceptado.
Por ejemplo, una historia podía definir un flujo de trabajo para una operación concreta.
En el momento de la revisión, podía introducirse una condición adicional: bajo determinada circunstancia, parte de ese flujo debía omitirse automáticamente.
En otro caso, el comportamiento acordado podía especificar cómo debía informar el sistema a un usuario cuando una operación fallaba.
En el momento de la revisión, la expectativa podía pasar a ser que el propio sistema se recuperara del fallo, sin requerir que el usuario tomara esa acción.
En otro, una función de vista previa podía haber satisfecho los criterios acordados, solo para que, durante la revisión, se volviera necesaria además una función de manipulación adicional.
Cada solicitud podía ser razonable.
Ese no era el problema.
El patrón
Las nuevas expectativas no se trataban como cambios en la especificación.
Se trataban como evidencia de que el equipo de desarrollo no había implementado correctamente la especificación original.
Esa distinción lo cambiaba todo.
Desde la perspectiva del product owner, la funcionalidad solicitada no se había completado.
Desde la perspectiva del equipo de desarrollo, los criterios de aceptación acordados se habían implementado — y nuevos requisitos aparecían después de la implementación.
La organización describía el retraso resultante como una mala productividad de ingeniería.
Pero la secuencia observable del trabajo era distinta:
- Se acordaban los criterios de aceptación.
- El equipo de desarrollo los implementaba.
- Surgían nuevas expectativas durante la revisión.
- Las nuevas expectativas no se clasificaban como cambios.
- La implementación original se consideraba, por tanto, incompleta.
- El trabajo adicional ampliaba el tiempo de entrega.
- El retraso se atribuía a la productividad de ingeniería.
Nuestra hipótesis
El equipo de desarrollo no sufría, principalmente, un problema de productividad.
El sistema utilizado para determinar si el trabajo estaba completo era inestable.
El equipo podía satisfacer los criterios de aceptación vigentes al comenzar la implementación y, aun así, no superar la revisión, porque los criterios realmente aplicados habían cambiado para cuando se evaluaba el trabajo.
Eso genera un problema de productividad especialmente difícil de resolver.
Mejorar la velocidad de codificación no lo soluciona.
Mejorar las herramientas no lo soluciona.
Pedir a los desarrolladores que estimen con más precisión no lo soluciona.
Incluso hacer que el equipo fuera drásticamente más rápido solo haría que alcanzara antes un objetivo en movimiento.
Por qué el problema era difícil de ver
Nadie necesitaba ser deshonesto para que surgiera este sistema.
El product owner podía creer sinceramente que el comportamiento adicional era una parte obvia de lo que se había solicitado originalmente.
Los desarrolladores podían creer sinceramente que habían implementado exactamente lo acordado.
Ambas afirmaciones podían describir con precisión la comprensión de cada persona.
Ninguna de las dos afirmaciones, por sí sola, describía lo que le estaba ocurriendo al trabajo.
Así que no necesitábamos decidir qué interpretación era correcta.
Comparamos los criterios de aceptación vigentes antes de la implementación con las expectativas aplicadas durante la revisión.
La diferencia era observable.
Lo que mostró la evidencia
El problema reportado era una baja productividad de ingeniería.
El problema observado era que las condiciones para aceptar un trabajo terminado podían cambiar después de que ese trabajo ya se hubiera implementado.
Como resultado, un trabajo que cumplía la especificación acordada podía, aun así, clasificarse como incompleto.
Se estaba midiendo al equipo con requisitos que no necesariamente existían cuando comenzó el trabajo.
Eso significaba que el aparente problema de productividad no podía resolverse optimizando únicamente a los desarrolladores.
Los desarrolladores no estaban dejando de cumplir los criterios de aceptación. Eran los criterios de aceptación los que se movían después de terminado el trabajo.
La perspectiva de Pulsar
Si hubiéramos aceptado el diagnóstico original, habríamos empezado preguntando cómo hacer más rápido al equipo de desarrollo.
En cambio, seguimos el trabajo desde el acuerdo hasta la implementación y la revisión.
La diferencia entre lo que la organización llamaba el problema y lo que el propio trabajo nos mostraba fue la señal útil.
El problema declarado era la productividad de ingeniería. El problema observable estaba en otro lugar.