¿La velocidad es un fin o un medio? ¿importa tanto la velocidad de un equipo ágil?

Hoy, bueno ayer, asistía, participaba en un interesante debate… ¿la agilidad es un fin o un medio? ¿importa la velocidad?

Te pongo un poco en contexto. Típicamente, no exclusivamente, la velocidad (no entro en definiciones, que ya hay post como 3 cosas que debes entender sobre la velocidad ágil y otros muchos) viene a ser aquello de las cosas que terminamos en un Sprint (tampoco entro, por no alargar, en qué es terminado, ya sabes producto potencialmente entregable y tal)

¿Hasta qué punto es importante la velocidad? No entro aquí en equipos de alto rendimiento de sobrada velocidad, el contexto aquí es equipos que están en crecimiento…. ¿deberíamos fomentar que la velocidad sea incremental? A ritmo sostenible eso sí, ya lo sabemos (lee aquí ¿La agilidad es hacerlo más rápido?).

Por una parte tenemos la opinión de que si presionamos mucho con la velocidad estresamos al equipo… pero no hacerlo nos puede desorientar sobre las mejoras que estamos haciendo, sobre si esas mejoras de deuda técnica, realmente, están orientadas a quitar deuda técnica o son, en sí, mero desperdicio.

Por una parte… si incidimos mucho en la velocidad puede que el equipo haga cosas con poca calidad que luego vuelvan como incidencias, pero, eso realmente, a su vez, desde la otra parte, eso bajará la velocidad porque los bugs, típicamente, no cuentan en la velocidad.

¿De verdad nos debería dar igual no ir tan rápido como creemos que podríamos? Y no habló de ponerle más horas para ir más rápido, hablo de buscar incesantemente la eliminación de desperdicio (ya sabes… ¿Más horas más productividad? ¿Cuántas horas de trabajo somos realmente productivos?).

En un modelo de gestión ágil, cosas como la velocidad recaen mucho bajo el equipo, tiene mucha parte el equipo en la misma (como es lógico), pero ello, y a los Scrum Masters, que «defienden al equipo», debería hacerles pensar si… ¿la velocidad no importa?

Dejo, conscientemente, el debate abierto. Conscientemente y porque ya, ahora, me voy a la mejor conferencia de la Galaxia sobre equipos ágiles, la #PAM208., pero mientras… ¿a ti qué te parece? ¿deberíamos dejar la velocidad en un segundo plano o es algo prioritario? Espero tu opinión.

Ah, y por si los estás pensando, sí, lo sé, además de la velocidad está el valor de lo que hacemos, puedo hacer mucho y que no sirva para nada, pero este post no iba sobre eso.

5 comentarios en “¿La velocidad es un fin o un medio? ¿importa tanto la velocidad de un equipo ágil?”

  1. Miguel Ángel Díez Bielsa

    Muchas gracias por el post, Javier
    En mi opinión este es unos de los motivos por lo que ser ágil es tan difícil.
    Es una retrospectiva constante. Es un estado mental. Es una actitud. Es un camino. Es mejora continua.
    Lo que ocurre es que para percibir esa mejora es necesario tener indicadores objetivos que reflejen la misma. Uno de ellos puede ser lo que se llama velocidad. El tema es que la velocidad no se puede analizar de forma aislada, debemos analizara con otros indicadores que reflejen otros factores como la calidad del código, la satisfacción del usuario, …
    Otro punto primordial es ser conscientes que esos indicadores no van a reflejar la realidad 100% simplemente se acercarán a una realidad.
    Muchas gracias de nuevo, Javier

  2. Hola Javier
    Es tan complejo, de mediar entre decir: qué haremos para ir más rápido? o definitivamente dejar su ritmo de autoorganización para que no se sientan estresados, presionados.
    No sé, creo que me inclino más por el valor que entregamos, pero ya lo creo en equipos maduros.
    En equipo inmaduros o en etapa de crecimiento , considero que medir la velocidad puede coadyuvar a que logremos eliminar desperdicio de tiempo…

  3. Yo creo que la velocidad es claramente útil. De hecho para mi la discusión interesante es más bien ¿cual es la finalidad que buscas con el uso de la velocidad? La respuesta básica podría ser: Que el equipo tenga una referencia que le ayude en la próxima planificación, por aquello de la predicción por comparación y tal. Vale, ok, y ¿Qué debería esperar el PO, cliente, organización, etc. que ocurriera con esa velocidad a lo largo del tiempo? ¿Que tienda a subir? ¿Por qué? ¿Para qué? ¿Para medir el rendimiento del equipo? ¿Para ir más rápido? Entonces, la velocidad no será una herramienta para el equipo, será un campo de un excel dentro de un reporting. Y si el equipo percibe eso sucederán cosas como las que mencionas en el post. Yo opino que el objetivo debería ser conseguir una velocidad constante en el tiempo. ¿Por qué? ¿Para qué? Pues para conseguir predictibilidad. Que el PO pueda hacerse una idea de qué trabajo podrá obtener dentro de 3 meses, de 6 meses, de 1 año. Que pueda dar fechas aproximadas a los stakeholders, inversores, clientes… eso sí que es oro puro para negocio. Vale, y ¿cómo mejora el equipo entonces? Pues el objetivo no sería tanto ir más rápido, sino hacerlo mejor ¿Y cómo? Pues haciendo crecer las condiciones del DoD. Ahí está la gracia. El DoD de un equipo maduro podrá incluir muchos aspectos más allá de que se cumplan los criterios de aceptación y de que tenga tests funcionales automáticos. Podría incluir temas de rendimiento, seguridad, vulnerabilidades, resilencia, escalabilidad, … El DoD es lo que debería tender subir. La velocidad: constante.

  4. Yo creo que la velocidad sí es importante, la cuestión es cómo la vamos a manejar y para qué la vamos usar.
    En mi opinión la velocidad es una métrica que nos ayuda confeccionar o determinar el Sprint Backlog.
    Y eso es todo, y si uno lo usa simplemente para eso, está bien, y no tiene por qué usarlo para nada más. Pero en un entorno Agile yo sí lo usaría, mínimamente para esto.
    Ahora bien, ¿para qué más podemos usar la velocidad? Bueno, podemos usarla para medir el crecimiento de las personas, para medir el desempeño, o como dato a la hora de controlar un posible riesgo en las auto-asignaciones de tareas que se hagan los miembros del equipo.
    Yo sé que he dicho en el anterior párrafo cuestiones que no son muy «agile» que digamos, pero simplemente apunto a que se puede usar para eso, adicionalmente.
    Finalmente, está la cuestión del cómo manejamos la velocidad. Yo creo que el equipo podría no conocer su velocidad como equipo, y estaría bien; o al menos los miembros del equipo no deberían conocer ni su velocidad personal ni la de sus compañeros, porque ahí puede estar el origen del estrés, y de la pérdida de atención en el foco principal. El objetivo es entregar valor añadido, no es una carrera para ver quién es más rápido.

  5. Definitivamente es importante. La velocidad del equipo permite determinar el sprint backlog, sin embargo, solo centrarse en la velocidad es una equivocación. El valor que se entrega prima sobre la velocidad, doy un ejemplo: Si tengo una combinación con 50 de velocidad y 100 de valor y tengo otro con 45 de velocidad pero con 110 de valor, claramente prefiero tener 45 de velocidad.
    Existen muchas aristas que se deben tener en cuenta, no olvidemos la prioridad, y la velocidad es una mas que se suma a la hora de planificar.
    Siempre digo, que lo mas importante es lo que mejor acomode al equipo y su crecimiento.

Deja un comentario

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

Share This
Ir arriba