Al igual que cuando íbamos al colegio, en aquellas dolorosas clases de física, nos enseñaban que la velocidad es igual a la distancia partido por tiempo, de una manera más amena, cuando tengo que hablar con alguien de qué es una gestión ágil, me gusta contar que uno de los objetivos que buscamos con la agilidad (o, véase, que buscamos aplicando buenas prácticas de gestión de proyectos software que no por ser poco conocidas dejan de llevar con nosotros muchos años, muchos) es aumentar la velocidad de los equipos.
En nuestro caso, en el de los equipos de desarrollo, la velocidad, entendida como el ritmo de entrega de valor a un producto software (bien sea añadiéndole funcionalidades, mayor calidad, etc.), tema que tratamos el otro día, al final del post de No puedes medir la productividad de un programador, en vez de depender de la distancia y del tiempo, se ve condicionado especialmente por dos componentes: el rozamiento y el desperdicio.
Si en física el rozamiento viene a estar relacionado con la oposición al movimiento que ofrecen las superficies de dos cuerpos en contacto, de forma similar, en un equipo de desarrollo software, el rozamiento es todo aquello que merma la velocidad de los equipos.
Rozamientos típicos son las interrupciones, recuerda aquello de que interrumpir a quien programa, o al que realiza cualquier actividad intelectual, hace que su productividad caiga (mas de lo que imaginas), programar con música debido a las oficinas ruidosas, recuerda aquello de porqué programar con música hace que seas menos productivo, tener un montón de tareas abiertas, por aquello de que trabajar en más de un proyecto a la vez genera perdidas de tiempo y disminuye la productividad, la baja calidad software que mermará la mantenibilidad, etc.
De la misma manera, tenemos el desperdicio, es decir, todas esas actividades y cosas que no sirven para nada y que son un desperdicio de tiempo. Tiempo perdido.
Desperdicios típicos, son los documentos y documentos que nadie leerá jamás, las especificaciones de cosas que nadie jamás implementará, las especificaciones de casos de prueba que nunca nadie ejecutará, las reuniones eternas sobre temas en los que nunca nadie se pondrá a trabajar, las funcionalidades programadas en una aplicación que ningún usuario utilizará, etc.
Si analizas tu entorno de trabajo, el equipo en el que estás, deberías echarle un vistazo a si hay mucho rozamiento y desperdicio, y preocuparte siempre de mantener ambos bajos, ya que, de manera similar a lo que ocurre en física, si ambos crecen mucho… puede que incluso tu velocidad sea cero.
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.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024