Durante el verano de 2023 apareció McKinsey con un artículo muy polémico acerca de la productividad del programador. Según esta organización, era viable poder medir su productividad. A pesar de que McKinsey goza de una gran aceptación por parte de las capas directivas de muchas empresas importantes a nivel mundial, existe una animadversión bastante extendida en la comunidad Agile y en el desarrollo de software, precisamente por artículos cómo estos.
Vamos a analizar este artículo sobre la productividad individual y cómo encontramos incoherencias claras que nos hacen entender que el software es una actividad ciertamente diferente.
Métricas de Equipo o Métricas Individuales
El artículo de McKinsey arranca bastante bien, haciendo entrever que el Desarrollo Software sigue una línea diferente a otras disciplinas como las ventas. De hecho, hacen bastante distinción entre las métricas de equipo y las individuales, un hecho en el que estoy de acuerdo. En el artículo se comentan métricas como DORA y SPACE, bastante extendidas en el mundo DevOps.
Hay un párrafo bastante inquietante. Cuando analizan en detalles las métricas comentan que en equipos de Ventas se pueden medir beneficios pero en software no. Es curioso, porque precisamente en Software deberíamos medir nuestra capacidad de dar resultados de negocio ¡Agile une desarrollo y negocio!
Métricas Individuales, el gran error
En el momento en el que McKinsey analiza las métricas individuales comienzan los problemas. En primer lugar, propuestas como la contribución al trabajo del equipo, algo imposible de medir. Si estamos hablando de resultados de equipo, entender qué contribuye cada persona cuando las tareas son muy heterogéneas y diferentes hace inviable medir esta contribución. Pongamos algunos ejemplos:
- ¿medir el número de clases Java que hace cada miembro?
- ¿medir el número de pantallas que realiza cada persona?
- ¿medir el número de ideas genuínas que han conseguido que el cliente alucine con la aplicación?
¡Es imposible!
Otra propuesta de McKinsey se centra en medir las capacidad de los miembros del equipo. Cierto es que hay herramientas como la Skill Matrix que nos ayuda a identificar estas habilidades pero nunca será tan objetivable cómo parece. En la Skill Matrix buscamos desarrollar un debate que permita a un equipo mejorar. Sin embargo, McKinsey propone que este conocimiento se traslade a un manager para que actúe en consecuencia.
Además, McKinsey argumenta la importancia de esta productividad tras la crisis de la Covid en la que se ha normalizado el teletrabajo o el trabajo híbrido. Y sí, ha habido un gran cambio de paradigma pero debemos evitar el viejo vicio de medir a las personas para tratar de saber si están trabajando.
Cambio de paradigma, cambio de métricas
Agile y sobre todo Scrum traen una propuesta clara al Desarrollo Software y a otros equipos que resuelven problemas complejos. Da igual cuanto trabajemos, da igual si realizamos muchas tareas o si somos muy productivos, el mercado solo quiere resultados (de negocio). Por tanto, necesitamos traer estos resultados a los equipos. Solo entendiendo el resultado (de negocio) final que produce un equipo podemos buscar puntos de mejora.
Podemos medir el número de release que realizamos en el tiempo, el número de bugs y el lead time. Ahora bien, el mercado dictará sentencia sobre nuestra capacidad de generar valor real y por el que los usuarios pagan.
¡Cuidado! las métricas de negocio solo funcionan si los equipos tienen una relación directa entre su trabajo y el propio negocio. En muchas empresas, el resultado final se diluye entre tantos departamentos que es casi imposible mapear la contribución de un equipo a su mercado. Esto requiere de un cambio muy profundo a nivel organizativo que muchas empresas deciden evitarlo.
Sin embargo, solo cuando un equipo entiende su capacidad real de entregar valor (de negocio) es cuando puede tomar decisiones maduras que le lleven a una mejora real.
¿Qué pasa si alguien trabaja mal?
Si has llegado hasta aquí, pensarás que Scrum es un mundo ideal donde todo el mundo contribuye y da lo máximo de sí mismo por el bien común y la entrega de valor. Esta idea está desalineada con la realidad de muchos equipos y empresas que ven como hay compañer@s que trabajan inadecuadamente, no se esfuerzan o incluso boicotean el trabajo de otras personas.
Evidentemente, si una persona no está alineada con el propósito de su equipo ni es capaz de encajar, quizás no deba estar en ese equipo. Hemos asumido durante años que el equipo es el que es y nuestra labor es potenciarlo. Agile y Scrum proponen un cambio de paradigma, nuestro objetivo es resolver un problema compleja entregando valor y una vez definido, que el equipo que esté dispuesto lo resuelva.
Ahora bien, la primera medida contra una persona desalineada no es el despido, hay muchas opciones previas. Un equipo fuerte es capaz de resolver estos problemas y, para ello, debe tener el “poder” de autocomponerse. Un equipo que puede decidir quién se queda y quién se va es un equipo que sabrá expulsar aquellos miembros que no se alinean con sus objetivos. Puede parecer duro pero el mercado es mucho más implacable con los equipos.
Y tú, ¿mides la productividad de los desarrolladores?
