Se encuentra usted aquí
¡No microgestiones!
Si no conocéis el blog de Jummp os recomiendo que lo añadáis a vuestro feed reader. Siempre que @jummp publica un nuevo post en su blog corro a echarle un vistazo. Y esto sucede a menudo, porque jummp es el blogger más prolífico que conozco - no lo conozco personalmente -. Pero aunque publica varios posts diarios consigue inyectar frases brillantes con bastante frecuencia. Por eso me pilló por sorpresa el contundente inicio de su post Desarrollo de software: La importancia de conocer la capacidad de producción.
A los gestores de equipos que venimos de las minas nos ocurre que nos encantan los números. Hemos sido adiestrados, por nuestra formación y experiencia, para el procesamiento de datos. Producir outputs a partir de inputs. Pero nunca nos han enseñado a gestionar personas, y por eso nos sentimos mucho más seguros manejando valores medibles y discretos.
Hace apenas unos meses hubiese suscrito el post de jummp íntegramente. Adoraba la microgestión. Desde mi posición de responsable de calidad recogía toda la información y me gratificaba con esa sensación de poder casi absoluto. Revisaba al milímetro las líneas de código que cada compañero enviaba al trunk, medía la complejidad ciclomática, la longitud de las funciones, los nombres de variables, los comentarios... Contaba los bugs detectados en cada iteración, y los separaba en graves y leves. Cuando durante un mes salían más bugs de lo normal, me devanaba el cerebro buscando soluciones o justificaciones. En mi afán de control llegué a hacer code reviews los fines de semana desde casa.
Después me tocó gestionar al equipo como scrum master, coordinador, o como lo queráis llamar. Y empecé a construir gráficas de productividad midiendo Story points. Me obsesionaba conseguir que el equipo produjese más a cada iteración. Y cuando la iteración no funcionaba según lo esperado, buscaba las causas y los culpables. Y entonces empecé a medir la productividad individual en Story Points.
No me daba cuenta de que estaba dinamitando la esencia misma de las metodologías ágiles.
Si fuera posible renunciaría a los Story Points. Mediría las User Stories según valores abstractos de lo que cuesta terminarlas. Casi nada, poco, bastante, mucho. Con esos valores sería suficiente. Pero los de arriba nos exigen mojarnos y estimar el trabajo, y para ayudarnos en esa estimación nos ayudamos de sucesiones numéricas para representar cada valor. 0.5, 1, 2, 3, 5... El problema viene cuando nos olvidamos de que estos valores no son más que representaciones, aproximaciones, indicadores nada más. Una User Story de 3 Story Points no es exactamente equivalente a otra User Story de 3 Story Points. Es más, una User Story de 3 Story Points puede acabar suponiendo mucho menos esfuerzo que una de 1 Story Point.
Cuando empezamos a adquirir una fe ciega en el valor de los Story Points, y nos creemos que es una unidad de medida objetiva, estamos cometiendo el mismo error que los arquitectos de software en el modelo tradicional en cascada. Pintan un diagrama de gantt de 70 tareas y te dicen que tendrán el proyecto listo el 15 de febrero del próximo año. No, el agilismo es otra cosa.
Las estimaciones fallan porque su naturaleza es imprecisa. Lo primero que debe hacer una empresa que acoja el agilismo es desprenderse de su obsesión por las estimaciones y aceptar que ningún gestor es capaz de evaluar el coste de un proyecto con precisión.
Volviendo al asunto del rendimiento individual, como bien dice jummp, un buen gestor ya sabe qué miembros de su equipo son productivos y cuáles no. Cuando un gestor mide los Story Points que produce un compañero, lo único que va a conseguir es confirmar algo que ya sabe. ¿Y para qué lo hace, entonces?. Sinceramente, el único objetivo que se me ocurre al medir los story points individuales es utilizar este dato como arma contra el presunto perezoso. Y este es un mal camino. Aún en el caso de que no se utilice este dato con ese objetivo, al final se filtrará al equipo que están siendo observados de cerca. Una cena con los compañeros con algunas cervezas de más, un comentario inoportuno, y el daño causado al equipo será mayúsculo. Nadie quiere trabajar en un equipo donde su esfuerzo es medido hasta el milímetro. La microgestión denota una absoluta falta de confianza en el equipo. Y si se utilizan valores como la suma de Story Points producidas por el individuo, entonces el individuo se centrará en resolver cuantos Story Points pueda. Y nada más.
Hay muchos otros factores a tener en cuenta en la evaluación del desempeño de un miembro del equipo. Y son tan difusos que no podemos medirlos objetivamente, del mismo modo que no podemos medir objetivamente el coste de un proyecto antes de realizarlo. ¿Qué aporta el desarrollador al equipo? ¿Cuál es su grado de implicación con los objetivos de la empresa? ¿Cómo de vinculado a ella se siente? ¿Influye en sus compañeros positiva o negativamente? ¿Cómo de bien diseña su software? ¿Es fácil introducir modificaciones en sus desarrollos? ¿Introduce muchos bugs y, por lo tanto, genera costes en el largo plazo? Estas son algunas de las cuestiones que se me plantean a bote pronto. Si lo pensamos más detenidamente, seguro que podríamos llenar folios y folios.
Las personas no somos máquinas. Incluso los desarrolladores más productivos tendrán caídas en su productividad. Todos pasamos por dificultades en el ámbito familiar, malos momentos emocionales o desmotivación. El gran reto de un buen gestor - y por esto no me considero uno de ellos - es identificar estos problemas en sus compañeros y tratar de compensarlos con los estímulos adecuados.
Si te abrazas a las unidades de medida como a las tablas de Moisés, estás perdiendo el foco. Estás centrándote en el procedimiento y no en el individuo. Recordemos un fragmento del manifiesto ágil, por favor:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Comentarios
Estoy de acuerdo
Hola Carles, en primer lugar te agradezco tu comentario, aunque creo que no lo merezco, soy muy nuevo en esto del enfoque ágil en el desarrollo de software (soy un converso que viene de una formación en metodologías clásicas y que viene de una organización donde el enfoque clásico es el prevalente) y estoy, por tanto, muy lejos de ti en conocimientos y experiencia. Esto también es extensible a otras muchas personas que estáis ayudando a la expansión de la actitud ágil.
Es posible que en el artículo al que haces referencia diera la imagen de que puedo defender prácticas de microgestión, pero no es así, renuncié a ellas hace tiempo, entre otras cosas porque me obligaban a invertir una cantidad de tiempo de la que no disponía y porque no terminaban de ser realmente efectivas.
No obstante, como es lo formación que he tenido, de vez en cuando la cabra tira al monte y termino haciendo, lo que intento evitar, determinadas prácticas que podrían entenderse como microgestión. Y eso se extiende como no podría ser de otra forma a lo que escribo.
¿Debe ser la velocidad una medida de la capacidad de producción? Personalmente no lo tengo claro, si bien es un indicador que resulta interesante de analizar. ¿Es esto microgestión? tampoco lo tengo claro, ya que forma parte de la dinámica de trabajo.
Me han parecido tremendamente interesantes tus reflexiones sobre los puntos por historia de usuario y estoy de acuerdo, aunque en el ámbito de un proyecto concreto con un equipo estable y con alguna iteración a las espaldas, sí que puede tener interés el análisis de la diferencia entre la velocidad estimada y la real porque como bien dices, una estimación inicial de 3 puntos para una historia y de 1 punto para otra, no quiere decir que al final la dedicación necesaria haya sido otra.
Pese a todo, sí que entiendo que de alguna manera se debería conocer la evolución en el nivel de productividad de una organización o de un equipo, ¿eso hace que los procesos tengan que dominar realmente una dinámica ágil de desarrollo? Sobre esto seguro que hay opiniones de todos los gustos y casi que podía ser objeto hasta de un congreso.
Muchas gracias Carles.
Hola Jummp.
Hola Jummp.
Gracias a tí por tu comentario. Quise responderte en tu propio blog, pero el post estaba cerrado.
Lo acabas de definir perfectamente, el agilismo es una cuestión de actitud. Los artefactos como los Story Points deben estar subordinados a esa actitud, y no al revés. Medir la velocidad de tu equipo es importante, claro que sí, porque ningún cliente va a aceptar invertir un solo euro sin una estimación. Lo que quería destacar en este post es que la velocidad de un equipo no es un sumatorio de velocidades individuales.
En el mundo del agilismo hay pocos maestros. He tenido la suerte de encontrar a varios, en libros y en personas, pero al igual que tú, en esto apenas acabo de empezar ;)