Thread by @entropikus

Hace un tiempo un manager acudió a mí para pedirme métricas de 'productividad' de los equipos con los que trabajo. Cuando le pregunté qué definía él por productividad, sin atisbo de duda afirmó: ' items realizados por unidad de tiempo por persona'.

https://twitter.com/allenholub/status/1228904883891212289

Enarcando una ceja le pregunté si había considerado tener en cuenta la complejidad de esos items y, en esencia, su naturaleza. "no lo veo relevante, respondió. Lo importante es cuanto trabajo finalizan mis recursos por cada ciclo y si cumplen con El plan".
#peoplenotresources

Antes de responderle me dijo que mi responsabilidad era la de reportar sobre el avance de los equipos.
Más enarcamiento de cejas por mi parte. Cambié mi pregunta previa por un, "¿Estás seguro de que es así?"... Un si rotundo fue su respuesta.
"Espera aquí un minuto"...

Salí a hablar con alguno de los miembros de varios equipos. Les pedía permiso para mostrar sus Dashboards al sujeto, obviando aquello que no quisieran. No pusieron pegas a que mostrase todo lo que quisiera...
Volví con el manager portátil en ristre y le acompañé a una sala.

"Antes que nada, reportar y medir la productividad personal no es mi trabajo. Ayudar a los equipos en la mejora contínua, colaboración, comunicación y gestión de su trabajo, si. De hecho,
si tienes dudas al respecto agradeceran que les preguntes directamente a ellos." #gogemba

"Dicho ésto, y a pesar de los post-its de las retros, desde que empezamos a medir salta a la vista que 'items por unidad de tiempo y persona' no es algo significativo. Tras analizar el flujo de trabajo establecimos una mínima política para medir. Y medimos varias cosas..."

"... Lo hacemos para ver qué causa impacto en su flujo y, precisamente, porque no pueden cumplir con lo que surgía de los Sprint planning de acorde con los requisitos de negocio que se transmiten a los P.O.
Y descubrimos cosas interesantes... Como puedes ver."

"Primero, la alta carga de trabajo extraordinario que surge en cualquier momento de cada sprint. Segundo, quién pide el trabajo. Tercero, qué tipo de trabajo. Cuarto, el esfuerzo que supone y cuánto de lo planificado se queda fuera. Y quinto, la naturaleza de los errores..."

"como puedes ver los equipos no están compensados en cuanto a carga de B.A.U. o la naturaleza del trabajo que afrontan. Éste, por ejemplo, ha pasado a modo de demanda continua porque el 60% de su trabajo impide cumplir con el vial de las planificaciones. Pero no es lo único..."

"Este mismo equipo recibe las peticiones por múltiples peticionarios y todas son marcadas como 'high priority' por la capa de managing que, precisamente, elude consultar al P.O. para acudir directamente a cada desarrollador con un a.s.a.p. y obviando la política de priorización"

"Mira ésto también. Los items de este otro equipo son pocos porque su complejidad es mayor. Y los de este otro son numerosos porque su complejidad es menor. Aunque si no tenemos en cuenta ésta complejidad parece que uno es más 'productivo' que el otro... ¿No?"

"Pero la cosa no se queda ahí... El de los items numerosos se hace cargo de la mayor parte de los 'supuestos bugs'. Así que hemos decidido analizar cuál es la naturaleza de cada uno. ¿Ves esos altos porcentajes?. Errores de definición porque no se transmiten bien los requisitos".

"... También porque se exige rapidez en la resolución sobre calidad en el desarrollo. Es curioso ver el alto porcentaje de errores de legacy, seguramente causados por lo mismo.
Aunque aún es pronto para sacar conclusiones más elaboradas ya que hemos empezado a medir hace poco."

"Dicho ésto, mi sugerencia es que, para medir lo que realmente necesitas, tengas en cuenta todos estos datos. Y antes hables con ellos que son los que no me han puesto problemas para compartir contigo esta información. #gogemba

"Una última cosa, ¿por qué razón quieres medir la productividad personal de -¿Cómo has dicho?- 'tus recursos'?... disculpa 'recursos' me da repeluco.
Si es 'personal' considero mejor llamarles por su nombre y hablar con ellos antes que mirar sólo números."
medium.com/notbinary/peop…

Pongamos un poco de 'contexto'. Mi ámbito de actuación eran los equipos de trabajo, es decir, había otros consultores enfocados a trabajar la capa de managing. Precisamente accedía al trabajo tras unos cuantos meses en el que esos equipos había estado en manos de otros.

Más aún, y ésto es algo que me he encontrado habitualmente, esas intervenciones formaban parte de una estrategia global que, erróneamente, se articula bottom-up. Es decir, se espera que la agilización de la organización surja sin necesitar modificar la estructura jerárquica.

Es decir, se opta por hacer convivir 2 formas de gestión que, a priori, chocan entre sí. De esta manera nos encontramos con equipos motivados y, a la vez, limitados por la política de la capa de managing. Más aún, una capa a la que 'han de rendir cuentas'.

En este caso existía una dinámica por parte de ciertos managers para fiscalizar el trabajo de los equipos. Razón por la que los equipos tuvieron una alta resistencia en registrar su trabajo y medir. Algo demasiado habitual, por cierto.

Además, y entre otras cosas, yo ejercía de S.M. y era el último eslabón de una cadena de consultores que, también, estaban 'agrupados' por capas jerárquicas. La estrategia 'global' se decidía en otras conversaciones y mi foco eran los equipos.

Medir siempre aporta. Es revelador y es un buen punto de comienzo para hacer visible qué ocurre en un sistema, detectar ineficiencias y qué medidas se pueden tomar para solventarlas. En el punto en que estábamos (arrancando o retomando el trabajo de otros) fundamental.