Hay que estar comprometidos con aportar valor… no con echar horas

Cuando me junto con algunos equipos, que trabajan en Ágil, etc., en ocasiones, la vida es así, hablamos sobre la eficiencia de su proceso. Hay otras ocasiones en las que hablamos de cultura Ágil, de equipo, de deuda técnica, de TDD, etc., pero, en este caso, este post, es una reflexión (otra más) sobre el tema eficiencia del proceso Ágil.

Hay cosas que aunque las escribamos miles de veces, estén en muchos libros, foros, conferencias, etc., para ciertos equipos no terminan de calar. Y una de ellas es esa de que «el software funcionando es la medida principal de progreso» (creo que no es necesario citar la fuente).

Y si no entendéis lo anterior, y aunque lo que voy a decir parezca una obviedad (sin serlo), pues haréis cosas que no están alineadas con hacer el máximo de historias funcionando al final del Sprint (no voy a entrar por enésima vez a explicar que hay que hacerlo sin meter deuda técnica, que otra cosa es el valor, que si ritmo sostenible, bla, bla , bla, para eso tienes post como 3 cosas que debes entender sobre la velocidad ágil o como por qué muchos piensan que hablar de velocidad no es Ágil).

Ya ni te cuento lo importante que tiene que ser para el Scrum Master entender, saber y hacer ver todo esto (más que hacer «happy» dinámicas de retros sin saber para qué).

Si no tenéis en la cabeza que hay que terminar el máximo de historias que aportan valor al incremento (o, mejor dicho, historias que tienen alta probabilidad de aportar valor, pero esto es otra historia), pues, pueden pasar cosas como, por ejemplo…

  • Que nadie esté preocupado porque las Historias tengan un «time box» (una estimación de tiempo ideal, para entendernos) para que, una vez superado, hagamos algo, pensemos, levantemos una alerta, gritemos ¡ayuda! y evitemos tiempos indefinidos para terminar las historias (lo que provoca que se hagan menos historias en el Sprint).
  • Que el «echar muchas horas» se vea como algo bueno, e incluso el «objetivo» para estar comprometidos con el Sprint (cuando el objetivo es acabar historias funcionando puestas en el incremento, típicamente en producción o preproducción), en vez de buscar estrategias para echar menos horas y terminar más cosas. Porque echar horas no necesariamente es lo mismo que ser eficiente (hay un post de hace 5 años que habla de esto, el de horas en la oficina vs ideas y conocimiento aportado).
  • Que en los Dailys NO sea habitual hablar de qué historias ya han excedido el tiempo razonable que se suponía debían tardar y que, por ello, provocarán que terminemos menos «software funcionando». E, incluso, que ni se cuente el exceso de tiempo que llevan ciertas historias.

Y, así, otras tantas.

Interiorizalo, la eficiencia del proceso Ágil (otra cosa es la eficacia), es el número de historias que terminamos funcionando (normalmente en producción o preproducción, y, obviamente, testeadas). La eficiencia no es las horas que trabajamos. 

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

1 comentario en “Hay que estar comprometidos con aportar valor… no con echar horas”

  1. Me gusta que dos de las tres consecuencias negativas que anticipas tengan que ver con el control (entendido como comparación entre expectativa y realidad) del tiempo incurrido en algunas historias de usuario.

    Siempre me confunde tu visión sobre el #noestimates, puesto que parece que lo describas como el escenario ideal, pero me resulta difícil compaginar este #noestimates con el control del tiempo incurrido en las historias que se complican o se estiran como un chicle.

Dejar un comentario

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