Por qué muchos piensan que hablar de velocidad no es Ágil

Por alguna razón, en algunos grupos, que dicen trabajar de manera Ágil, se produce un estremecimiento en La Fuerza cuando se les menciona la palabra «velocidad», hasta el punto de que mencionar la palabra velocidad llega tacharse de actitud poco… poco Ágil.

Como no existen las Tablas de la Agilidad, cada uno puede entender e interpretar ciertas ideas como más o menos Ágiles. Sin embargo, sobre el uso de la velocidad en equipos Ágiles, parece que los que iniciaron el movimiento tenían pocas dudas, ya que mencionaron su utilidad en numerosas ocasiones.

Por ejemplo, en el propio manifiesto Ágil, ese que mucha gente que habla de agilidad no se ha leído, podemos ver cosas como:

  • «Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor», así que hay un ritmo de entrega, de entrega con valor (dejo para más abajo esto del valor).
  • «El software funcionando es la medida principal de progreso», así que medimos en avance según lo que entregamos.
  • «Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible», así que hay una frecuencia de entrega, parece sensato que sepamos cuál es para saber si realmente es frecuente esa entrega.
  • «Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida», así que hay un ritmo.

Todo lo anterior habla de velocidad, no dice si mucha, ni poca, pero habla de velocidad. No dice que el valor de lo que entreguemos no importe, ni que no sea lo más importante, pero tampoco se deduce de lo anterior que la velocidad no importe.

De hecho, por poner más referencias (y ya no pongo más, que aburre), si nos vamos a uno de los libros de uno de los padres de Scrum, y firmante del manifiesto Ágil, al Scrum: The Art of Doing Twice the Work in Half the Time (y ojo al título del libro) de Jeff Sutherland, podemos encontrar párrafos como el de la imagen de más abajo, que supongo no necesitan traducción, pero que hablan de velocidad, de cómo ir más rápido y sobre acelerar.
jeff sutherland velocidad velocity
Yo creo que tras el rechazo a la palabra velocidad están, como dice mi amiga Ángela (por cierto, tendremos nueva edición del curso Pragmatic Agile Coaching el 28 de febrero), las creencias, lo que a ti te viene a la cabeza cuando escuchas «velocidad», que probablemente esté asociado a periodos de sufrimiento, a tiempos en los que la velocidad era (o sigue siendo) un arma del Lado Oscuro para presionar a los equipos.

Entre esas creencias está que hay gente que asocia velocidad con control o con que eso me llevará a «echar más horas en la oficina que la puerta»… pero ese no es el espíritu de la velocidad en agilidad (esa es la velocidad del Lado Oscuro). La velocidad bien entendida es algo muy potente para buscar desperdicios, cosas que no aportan valor y que eliminándolas podríamos ir más rápido.

La velocidad es ritmo sostenible, no exceso de horas.

La velocidad esperada en un Sprint la fija el equipo (gran diferencia con los tiempos oscuros), lo cual es un poder y, a la vez, una responsabilidad.

La velocidad es entregar más al usuario. Es ser más competitivo (incluso sobrevivir).

Y, en un ciclo de inspección y adaptación, a más velocidad más probabilidad de acertar, de aportar valor y por ello que…

No puedo terminar un post sobre velocidad sin hablar del valor. Muchos hablan de que el valor es lo más importante, bla, bla, y de ahí deducen que la velocidad no importa. Cierto, ir muy rápido entregando cosas que no valen para nada… no sirve de nada. La «potencia sin control» y tal. Cierto, cierto, pero, como dicen en la Royal City… «lo cortés no quita lo valiente», hay que ir rápido (entendiendo rápido no como echar n-mil horas sino buscando eliminar desperdicio) y acertar con lo que se hace, la mucha importancia de una cosa no anula otra.
 

Javier Garzás

5 comentarios en “Por qué muchos piensan que hablar de velocidad no es Ágil”

  1. Realmente la palabra velocidad no aparece citada en el Manifiesto (principios) ni en la Guía de Scrum (Scrum.org). Deducir que está ahí me parece un poco ejercicio de imaginación.
    Entregar, valor, tempranamente, frecuentemente, feedback, software que funciona y ritmo constante (predecible). Esas son las palabras exactas que aparecen.
    Para mí, la velocidad es un intento de proporcionar predecibilidad al Product Owner sobre el tamaño del sprint en Scrum. El problema es que es una métrica pervertible en extremo, hasta el punto de llegar a ser contraproducente facilmente.
    Si para aumentar la velocidad, entregas software que no funciona o funciona peor (bugs), qué sentido tiene?
    Si además no trabajas en iteraciones de duración fija, qué sentido tiene?
    Ojo que no estoy diciendo que si el Product Owner necesita algún grado de predecibilidad, no se la demos. Necesita estimaciones? Adelante. Con el mínimo de desperdicio; no estimemos en horas si vale con días. Necesita una fecha de compromiso? Adelante. De forma realista para no tener que estresar el ritmo del equipo.
    Para mí, la prioridad en Agile debe ser entregar software que funciona de forma temprana y continua, con el objetivo de obtener feedback lo antes posible e iterar.

    1. Mismamente, en uno de los 12 principios dice… Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
      Y. según la RAE.. frecuencia es
      1. f. Repetición mayor o menor de un acto o de un suceso.
      2. f. Número de veces que se repite un proceso periódico por unidad de tiempo. La frecuencia de esta emisora es de tantos kilociclos por segundo.
      3. f. Estad. Número de elementos comprendidos dentro de un intervalo en una distribución determinada.
      A mí me suena mucho a velocidad, pero bueno, cada uno hace sus interpretaciones. Porque si nos salimos del manifiesto, no son pocos los firmantes que han mencionado la velocidad, véase la cita de Sutherland en el post o un framework que poca duda de ser ágil tiene como es eXtreme Programming, donde, por ejemplo, véase http://www.extremeprogramming.org/rules/velocity.html
      El problema, que yo lo entiendo, porque lo he sufrido, es que escuchamos velocidad y nos vienen malos recuerdos, incluso presentes, de gerentes que nos van a hacer currar a morir, pero eso no es problema de la velocidad es… de la cultura. Lo que hay que hacer es tener una cultura sana… no eliminar del mundo la velocidad, sin cultura, puedes eliminar la palabra velocidad… y pasará lo mismo con otros nombres.
      «Si para aumentar la velocidad, entregas software que no funciona o funciona peor (bugs), qué sentido tiene?» Es que eso es no haber entendido la velocidad en agilidad, yo no sé cuantas veces lo habré dicho… velocidad a ritmo sostenible, meter bugs o deuda técnica se carga lo de ritmo sostenible. Ademas, es que lo que no sea working software… es que no debería sumar velocidad.
      Si no tienes sprints o iteraciones es… lo mismo. Eso ya lo inventó Kanban hace años, y hace algo, que viene a ser la misma idea con los cycle y lead time.
      Y le voy a pedir a los Reyes que por favor, nadie me vuelva a decir que hablar de velocidad en agilidad… es no hablar de valor (que ni siquiera es, necesariamente, software que funciona, valor va más allá). Que lo cortés no quita lo valiente.
      Si es que es de sentido común, yo, por ejemplo, mido los tiempos que tardo en escribir según tipo de post… para eliminar desperdicios. Si alguien hace fitness pues parece lógico que se mida tiempos para mejorar. Si sales a correr, lo mismo. El problema es que llegue el Sargento de Hierro con el látigo, pero el problema es el Sargento… no la velocidad, que sin hacerla oscura es muy útil para detectar desperdicio, es más, es que si la velocidad a tope y sin control era un destructor de negocios, el otro extremo, pasar de ella… también PUEDE llegar a serlo (y lo digo porque lo he visto).

      1. Si a mí la idea de la Velocidad, como idea, me parece fantástica. Igual que a mucha gente le parece fantástica la idea de tener una fase de Análisis y otra de Desarrollo.
        Pero cuando vas a llevar la Velocidad a la práctica es cuando te das cuenta de que no es tan buena idea. Es demasiado pervertible. Al menos esa es mi opinión.
        Por lo que yo me preguntaría: qué valor aporta realmente la Velocidad y a quién? Le podemos dar algo parecido de otra forma?
        Puntos débiles de la Velocidad en la práctica (no es una relación detallada):
        – Estimar se vuelve crítico. Y ya sabemos todos los problemas que trae estimar. Volvemos a los puntos de historia? En un equipo grande, con personas con diferentes capacidades, estimar en horas puede traer conflictos internos.
        – Necesario actualizar las estimaciones. Te vas a equivocar en una estimación antes o después.
        – La Velocidad no es una métrica que permita comparar equipos. En cuanto tengas un cambio en el equipo, ya puedes borrar todas las velocidades anteriores.
        – La Velocidad puede variar por muchísimos motivos que no tienen que ver con el desperdicio.
        – El equipo se va a sentir observado por la Velocidad. Va a sentir medida su productividad por esa métrica. Ya sabemos lo que pasa cuando te miden con una métrica. Es nuestra naturaleza.
        Ya te digo, utopicamente, me parece genial la Velocidad pero cuando he intentado llevarlo a la práctica, no me ha aportado nada bueno.
        Si quiero buscar desperdicios, lo hago principalmente con observación directa y retrospectivas.
        Si el Product Owner quiere predecibilidad, le doy estimaciones con tamaños de camisetas. Si quiere una fecha de compromiso, sudo un poco, le hablo de calidad, seguridad, etc. y uso buffer.

Deja un comentario

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

Ir arriba