No sé si te has visto envuelto/a en un entorno en el que tus jefes, siendo Scrum Master, te han pedido la métrica definitiva; la buena; la que realmente necesitan… Una parecida a: «¿Cuánto más (o menos) productivos somos ahora que hacemos Scrum con respecto a cuando no lo hacíamos?». Los jefes quieren saber cuál es el retorno de la transformación ágil que el departamento lleva haciendo ya 3 años, ya que en ese tiempo se han cambiado muchas cosas: se ha contratado a un Agile Coach, se han gastado 64574543 horas en reuniones, se ha dado formación a los empleados, se ha dado más libertad a los equipos para que decidieran… (por ejemplo, que decidieran cuánto trabajo podían hacer por sprint, o que decidieran con qué tecnología trabajar, o que decidieran refactorizar cierto método). En fin, quieren saber si los equipos ahora son más productivos. Me salen sarpullidos de recordar estas conversaciones, porque en ocasiones afloran creencias muy oscuras…
¿Qué es la productividad?
La productividad, en nuestro caso, se referiría a cómo de eficiente es el proceso de trabajo del equipo Scrum, cuál es su rendimiento. Incido en todo el equipo Scrum (incluyendo a Scrum Master y Product Owner) y no solo al equipo de desarrollo, que habitualmente las miradas se centran en éste último.
Me resulta muy curioso averiguar de dónde sale la motivación de medir la productividad de un equipo. He comprendido que dependiendo de quién haga la petición, el enfoque es muy diferente, y con él el impacto que produce en el sistema.
¿Por qué queremos medir la productividad?
Si buscamos la motivación que hay detrás de querer medir productividad, podemos llegar a estas razones:
- Medir la productividad permite conocer nuestras debilidades como equipo y adoptar medidas necesarias para mejorar (motivación intrínseca)
- Si la productividad de un equipo aumenta, entonces significa que está siendo más eficiente. Ser más eficiente significa hacer el trabajo a la perfección y encima ahorrando costes. Si la empresa ahorra costes, significa que está ganando más dinero (motivación extrínseca)
Motivación intrínseca
Cuando quien quiere medir la productividad es el propio equipo
Si la iniciativa de medirse así mismo la productividad es del propio equipo (o de un Scrum Master que instigue en el equipo las ganas de «mirarse hacia dentro» con el fin de ser mejores, sin que venga impuesto) entonces el efecto que produce la métrica que se elija será positiva, porque sirve como reflejo de la realidad que todos hemos acordado; una realidad que no duele, porque la usamos con el fin de compararnos con nuestros «nosotros» del pasado.
Hay muchos indicadores o métricas que nos pueden ayudar a saber si estamos siendo más productivos, por ejemplo:
- ¿Que nos levanten más bugs significa que trabajamos peor?, pues midamos el número de defectos levantados en Producción
- ¿Que tengamos tareas bloqueadas o en espera nos hace ir más lentos?, pues midamos nuestro cycle time versus touch time e intentemos reducir su diferencia a cero, reduciendo el cycle time
- ¿Nos parece interesante saber el número de features que somos capaces de hacer por unidad de tiempo? Quizás durante una época queremos medir nuestra velocidad, ya que nuestras features parecen ser similares en tamaño, pero a lo mejor durante otra época estamos trabajando de otra forma y no tiene tanto sentido medir velocidad porque estamos iterando a diario con el cliente
Motivación extrínseca
Cuando quien quiere medir nuestra productividad es el jefe
Depende de cómo un jefe entiende el proceso de trabajo del equipo, espera una respuesta u otra a la pregunta de «¿somos más productivos?»:
- Si entendemos el proceso de trabajo como un proceso de producción, entonces estamos más enfocados a outputs (resultados de un proceso derivado de la aplicación de unos inputs a un sistema) y lo que queremos son números creciendo, gráficas con tendencias hacia arriba; mayor volumen de trabajo realizado por unidad de tiempo. Muy similar al desempeño de una fábrica (¿os suena el concepto software factory? Creo que en ellas se ha llegado a medir el número de líneas de código producidas por un desarrollador al día, xD).
- Si entendemos el proceso de trabajo como un proceso creativo, entonces estamos más enfocados a outcomes (consecución de unos resultados buscados y ligados a un objetivo de negocio) y lo que queremos incrementar es el valor que aportamos al negocio y a nuestros clientes, y no tanto el volumen de tareas realizadas por unidad de tiempo. Nos interesa más saber si estamos cumpliendo y cuánto con nuestro propósito de negocio.
¿Qué es lo que me he encontrado recientemente?. Que hay jefes (middle management) que no saben cuál es su propósito de negocio, no saben qué es lo que quieren conseguir realmente, más allá de tareas recurrentes de mantenimiento. En empresas que llevan haciendo lo mismo durante 20 años, lo normal es seguir cumpliendo con «su deber» igual que se ha ido haciendo año tras año, intentando a ser posible mejorar la tendencia un poco, pero sin mucho dolor de cabeza.
Si estos jefes entienden el proceso de trabajo de un equipo Scrum como un proceso simple de producción, entonces al preguntar por productividad lo que quieren ver son números del estilo:
Productividad laboral = productos o servicios producidos / recursos utilizados
Donde acabamos en estimaciones del tipo «cantidad-trabajo-realizado / horas-hombre». ¿¿¿Se puede contabilizar o evaluar así un trabajo creativo???. ¡¡PELIGROOO!! ¡Aquí es donde tenemos un grave problema…!
El gran coste de medir
Parece que el ejercicio de medir algo (definir un indicador y hacer seguimiento del mismo durante un largo periodo de tiempo) sea un proceso que siempre compense, y es totalmente falso. Medir algo tiene sentido sí y solo sí sabemos para qué medimos realmente, porque la toma de datos a veces puede complicarse mucho.
Pongamos de ejemplo que queramos medir nuestra eficiencia de forma intrínseca. Por ejemplo, fijándonos en el cycle time de nuestras tareas versus el touch time. Nuestro cycle time correspondería al tiempo que transcurre desde que se empieza a trabajar en una tarea hasta que se completa. Nuestro touch time, en cambio, sería el tiempo en el que el equipo ha estado trabajando activamente en la tarea. En muchas ocasiones el cycle time es mayor que el touch time porque la tarea pasa de mano en mano. O alguien externo tiene que validar alguna cosa para poder seguir con ella hasta el final. Quizás ya nadie se acuerda del contexto de la tarea y ahora hay que re-aprender. A lo mejor sufre algún retraso por alguna urgencia o tarea unexpected con mayor prioridad que se cuela… Bueno, pues conseguir que el cycle time = touch time nos llevaría a una reducción de desperdicio muy elevada en nuestro ciclo de trabajo y por tanto seríamos mucho más eficientes.
Podríamos tomar este ejemplo como nuestro objetivo: cycle time – touch time = 0, e ir midiendo el valor de estas dos métricas por cada tarea de cada iteración, durante X iteraciones.
Cycle time: Si tenemos una herramienta de gestión de tickets como Jira o Trello, podríamos obtener de forma automática (programando usando su API o pagando algún plugin) el tiempo que transcurre desde que la tarea entra en el estado DOING hasta que llega al estado DONE. Habría que almacenar este tiempo por cada tarea de la iteración, de todas las iteraciones. Necesitamos almacenar este dato de forma persistente e incremental.
Touch time: Aquí viene el problema. Actualmente solo podemos confiar en el registro manual de este tipo de métrica. Durante un tiempo, nosotros intentábamos tomar nota en los dailies sobre si el día anterior se había podido trabajar en cada tarea. Nos acordábamos de anotarlo manualmente durante unos días, pero se nos acababa olvidando y además era muy costoso llevarlo al día y de forma fiable. Si quisieras pensar en automatizar esta métrica, quizás podrías delegarlo a la herramienta de gestión de tareas, si la tienes. En una empresa donde los desarrolladores tengan que imputar sus horas en tareas de Jira o Trello, se podría obtener a partir de esos tiempos, pero incluso en ese caso… ¿qué pasa cuando los desarrolladores se olvidan de imputar? ¿y con los diferentes criterios de imputación que varían de una persona a otra (lo que uno considera tiempo de autoformación, otro considera tiempo efectivo de desarrollo de tarea)? ¿qué ocurre cuando en el equipo se trabaja en pair programming o incluso si lo hacen en mob programming? ¿cómo podemos entonces calcular el tiempo natural de trabajo efectivo total si las personas imputan sus horas dedicadas individualmente?.
Y una vez tienes los tiempos (por cada tarea, por cada iteración, por muchas iteraciones) has de encontrar una fórmula automática que te permita analizar los datos de un único vistazo, con lo que necesitas diseñar la automatización de ese procesado, para la posterior interpretación.
Conclusión: medir la productividad de un equipo es un ejercicio complejo que puede no tener sentido
No sé si estarás de acuerdo conmigo, pero todo este trabajo de medir no es trivial ni gratis. Sobre todo si los datos dependen de que alguien se acuerde de hacer algo (por ejemplo, imputar horas en un sistema de tracking) y de que, además, lo haga «bien». Imagina si, también, quieres tener varios indicadores o métricas para poder combinarlos. Si no está todo automatizado bajo un sistema de información coherente y fiable, el trabajo y esfuerzo de mantener estas métricas pasa a ser exponencial. Básicamente, deja de tener sentido: empezamos a ser menos eficientes por querer ser más eficientes.
Por tanto, a la pregunta de «¿es posible medir la productividad de un equipo?» respondo que sí, es posible. Pero a la pregunta de «¿es útil medir la productividad de un equipo?» responderé que depende, y después te preguntaré: ¿quién eres y cuál es tu finalidad?, porque medir siempre exige un esfuerzo de recogida de datos, de procesado y de interpretación. Cada parte requiere atención y mimo para que las conclusiones tengan sentido y sirvan realmente para algo (recuerda la gran diferencia entre output y outcome). Si la iniciativa surge internamente en el equipo con un propósito de mejora continua estaremos en el buen camino. Si la iniciativa surge externamente como herramienta de control y de justificación de si el negocio va bien… ¿realmente es productividad de un equipo lo que quieres medir, o lo que de verdad quieres saber es la rentabilidad de tu departamento?. O como decían antiguamente en Oriente: ¿no estarás mirando el dedo en lugar de mirar la luna?