Recientemente, en una conversación con algunos compañeros surgió una pregunta que a menudo es habitual en el mundo de la agilidad. ¿Cómo podemos medir la eficiencia de nuestro equipo?
Rápidamente, la conversación se dirigió hacia el conocimiento de la velocidad del equipo. En ese momento comenté: Pero la eficiencia no es sólo una cuestión de velocidad, ¿no? Y es que antes de responder habría que entender bien que significa que un equipo sea “eficiente”.
La eficacia está directamente relacionada con la consecución de los objetivos establecidos. Llevado al extremo, de forma aparente la eficacia no contempla limitaciones; y hace uso de los medios que sean necesarios para conseguir los objetivos establecidos.
La eficacia es el sueño húmedo para todo manager tradicional que se enfrenta a una planificación. Para cualquier proyecto, tiempo, recursos y costes ilimitados. Consiste en utilizar lo que necesites para tener lo que deseas de la mejor forma posible.
Poco importa en eficacia si estos medios se están empleando de una forma óptima, o tan sólo apropiada. Si favorece la consecución de los objetivos, está bien. Si lo piensas bien, esto no es tan raro como puedas imaginarte. He vivido muchas situaciones en las que personas de un equipo (obviamente no autogestionados) trabajaban en entornos en los que su talento y habilidades eran infrautilizados. El proyecto “va bien” desde la perspectiva de la eficacia, por tanto, todo estaba OK. Pero en realidad se estaba cociendo un desastre respecto a las personas que trabajaban en él. Sin embargo, a gran escala, en el mundo real siempre hay limitaciones. Nos hemos acostumbrado como sociedad a aspirar a todo, pero sabiendo que no existen ilimitados recursos.
La eficiencia tiene que ver con el uso apropiado de los recursos disponibles. En proyectos, la primera limitación (o la más evidente) llega con el coste. Alguien decide que cierto producto tiene un techo de coste X. Bien sea una puja, una oferta comercial o cualquier otro cálculo mágico. Pero también es común lidiar con:
La eficiencia consiste en ser consciente de las herramientas de que disponemos, y utilizarlas de la mejor forma posible para obtener los resultados deseados.
Si en nuestro cuadro de mando del proyecto nos fijamos únicamente en el velocímetro, puede que nos encontremos que un equipo eficiente es “lento” comparado con un equipo eficaz. Debemos comprender que ambos equipos no están jugando con las mismas reglas, ni se focalizan en los mismos parámetros. El equipo eficiente tiene restricciones y se focaliza al exprimir al máximo las herramientas de que dispone. Mientras que un equipo eficaz carece de limitaciones y utiliza las herramientas para maximizar el resultado deseado
Sería conveniente entonces, aunque sea por justicia poética, fijarnos en otros parámetros que, además, son muy interesantes, y nos ayudarán a tener una imagen 360º de la eficiencia de nuestro equipo. Algunos de estos parámetros pueden ser:
¿Cree que es justo para el equipo que centramos nuestros esfuerzos en el control del tiempo que tarda en construir cierta necesidad? ¿Qué ocurre con todo el proceso previo? ¿No merece cierto análisis también? El cycle time corresponde al tiempo de construcción de la necesidad, una vez se autoriza la construcción de ésta. Ese tiempo está focalizado en los técnicos.
Sin embargo, desde el momento en que un stakeholder verbaliza una necesidad, se inicia un proceso que tiene como principal objetivo determinar su idoneidad en el conjunto del producto. Tanto en lo que se refiere al encaje con la parte ya construida, como la todavía pendiente.
Este proceso tiene un flujo de trabajo que básicamente persigue la obtención de la información necesaria para poder determinar esa idoneidad. Por tanto, este proceso comporta el trabajo de personas durante un tiempo determinado. Y como tal, puede o debe ser evaluado a fin de buscar mejora aquí también.
No sería justo un proceso de definición y priorización de las necesidades lento o con graves carencias, en contrapartida a un proceso de construcción técnica ultramonitorizado. Error habitual aquí de los Scrum Masters, que olvidan la 1ª premisa de su función: Explicar Scrum a toda la organización
El lead time corresponde a todo el proceso, desde que se verbaliza la necesidad, hasta que ésta es finalizada y empaquetada con un lacito para la entrega. Todo el proceso es susceptible de mejora. Un lead time lento provoca incoherencias en la priorización, afectando negativamente a la calidad del valor entregado.
Deberíamos ser completamente autoorganizados como equipo. Pero desgraciadamente hay veces que la autoorganización termina donde la organización impone formas de hacer comunes. No estoy diciendo que me guste ni que haya mecanismos para mejorar esto. Digo que ocurre muy a menudo.
Por ejemplo, existen organizaciones que no comprenden bien las ventajas de utilizar historias de usuario. El Product Backlog puede ser una herramienta que ayuda verdaderamente al equipo, con necesidades claras, actuales, bien informadas (ready) y con un mínimo valor. O puede ser una especie de callejón sin salida de peticiones atómicas sin orden.
Los Scrum Boards de los equipos son un reflejo del Product Backlog. Si el Product Backlog no está bien, los Sprints Backlogs y los tableros tampoco estarán bien. Como en Scrum Masters debemos detectar esto, y hacer propuestas que mejoren la calidad de las herramientas de los equipos. Scrum Boards limpios y claros. Sprints con objetivos claros, alcanzables y que generen incrementos de valor. Y Products Backlogs centrados en la necesidad, criterios de aceptación y el MVP.
Como en Scrum Masters haríamos bien en tener en nuestro cuadro de mando, indicadores sobre la calidad de las herramientas operativas de nuestros equipos
Un equipo que prima la eficacia quizás no verá con buenos ojos que existan normas y condiciones necesarias que puedan hacer peligrar la consecución de los objetivos. Un equipo eficiente es consciente de estas tareas necesarias, adaptando su operativa para tenerlas presente como parte del resultado.
Es DoD todo aquello que la organización (por ejemplo: CI/CD), el cliente (por ejemplo: usabilidad y accesibilidad) el estado (por ejemplo: RGPD), el mismo equipo (por ejemplo: API, escalabilidad o calidad del resultado) u otros interesados creen necesario para tener los resultados deseados.
Además, dentro de este paraguas siempre debemos hacer énfasis en todo lo relativo a la calidad del resultado (calidad técnica y fiabilidad del resultado). Un producto fiable es necesario siempre. Las pruebas a múltiples niveles, los benchmarks de rendimiento y, especialmente importante en ciclos iterativos, la garantía de regresión del resultado. El DoD viene a decir que no es suficiente tener un producto que funciona, sino que además éste es útil en cualquier situación
Cuando nos preguntan cómo podemos medir la eficiencia de nuestro equipo, haríamos bien en tener valores sobre el desempeño del DoD
Los bugs. Sería muy inocente pensar que lo que hemos entregado en el sprint anterior, por muy rigurosos que seamos al asegurar su calidad, no generará ningún tipo de error o de sorpresa una vez el usuario lo haga. Como en Scrum Masters, en nuestra evaluación de la eficiencia del equipo, debemos medir los bugs. Saber su origen, la vía por la que se resolverán, y el impacto que esto tiene sobre el trabajo del equipo y de los resultados esperados en el próximo sprint.
No es objetivo aquí explicar los mecanismos para “convivir” con los bugs. Pero creo que siempre es bueno comentar algunas cosas que creo que son importantes:
Sea como fuere, creo que lo importante es hacer estimación de ese trabajo imprevisto que nos llega. Y lo mejor que podemos hacer es negociar con el Product Owner. Con el cariño se puede explicar que los bugs también son trabajo de personas. Y el trabajo nunca es a coste 0.
Si tienes un sistema iterativo consistente en que, de forma cíclica, das una porción del producto, esta porción debe ser útil para los suyos destinatarios. Si no lo es, aquella entrega irá a parar a un cajón a la espera de otras entregas posteriores, o peor aún, a tener el producto completamente terminado.
Si nuestras entregas van a parar a cajones, no tenemos feedback ni revisión que nos permita detectar y corregir desviaciones. Y esto comporta, muy probablemente, que el proyecto terminará mal.
El proceso por la correcta definición del MVP forma parte del Lead Time. En nuestro proceso de evaluación de nuestro equipo deberíamos contemplar indicadores sobre la definición del MVP y su cumplimiento en la entrega a cada ciclo
Por último, la evaluación de la satisfacción es la gran olvidada en los salpicaderos de los Scrum Masters. Quizá sea el indicador más importante. Cliente feliz, equipo feliz. Existen diversas formas complementarias de averiguar la satisfacción de todas las partes, pero la más efectiva es situar inputs en la Sprint Review (y posteriormente).
No olvidemos que la satisfacción nunca es exclusiva de los usuarios. Son importantes pero no son los únicos. La satisfacción es también objeto de deseo del equipo. Tenemos una oportunidad cíclica de evaluar la satisfacción con el equipo. La Retrospectiva.
La efectividad consiste en adquirir la conciencia necesaria de que, seremos efectivos en el momento en que alcancemos los objetivos establecidos (eficacia) con la maximización de los recursos y herramientas disponibles (eficiencia). El mundo no funciona siendo únicamente eficaces o eficientes. Se debe encontrar un equilibrio entre estos dos factores. Esto es la efectividad.
