Pocos se percatan en las compañías sobre 2 actitudes similares de hacer frente al trabajo que obtienen resultados antagónicos.
Hace algún tiempo atrás me tocó ayudar a un conjunto de equipos de una empresa (llamémosla LECO) que necesitaban contar con una herramienta para guardar el conocimiento resultado de sus sesiones de comunidades de excelencia técnica. La idea era capturar durante las reuniones toda la información generada para así poder compartirla posteriormente con otros grupos o nuevos miembros de la organización.
Los equipos Scrum se ofrecieron para instalar la herramienta, lo que podía incluirse como una tarea compartida entre ellos. La idea era simple… se adicionaba a una pila (backlog) compartida para luego ser llevada adelante en 1 o 2 días.
Como LECO contaba con sus propios procedimientos y departamento encargado de infraestructura, decidió solicitárselo a éste último para que el proceso fuese más eficiente. Ello no distraería a los equipos Scrum de sus tareas habituales y conservaría el foco al 100% de los mismos en la entrega de valor al cliente. A su vez, no ofendería a ninguna persona ya que nadie se sentiría que otra persona estaba haciendo su trabajo.
Pese a la buena voluntad del departamento de infraestructura de LECO, no tuvieron otra opción que adicionar la tarea a su pila interna, a la espera de contar con el tiempo y la persona adecuada para hacer realidad la instalación de la herramienta. Esto se tradujo en un retraso de semanas (sino meses), lo que hizo que se perdiese de forma irrecuperable la posibilidad de capturar el conocimiento adquirido durante las sesiones de comunidades de excelencia técnica.
Otra experiencia fue la de una organización (llamémosla ATOP) donde el Product Owner realizaba constante presión en el equipo para así aumentar la cantidad de características factibles de terminar al final de cada Sprint. La idea era sencilla… aumentar la eficiencia del equipo traería como resultado un mayor valor para el cliente.
Ambos casos son un ejemplo claro donde se busca hacer más eficientes las tareas o procesos a los que se está directamente expuesto.
¿Qué hay de malo en ello?
En el caso de LECO, se optó por una solución que parecía la más adecuada. La trampa consistió en que el traspaso de información y delegación aumentó la eficiencia pero disminuyó su eficacia, debido a que el nuevo dueño de la tarea estaba más ocupado que quien se había ofrecido inicialmente, lo que hizo que se incrementase su complicación (pasos necesaros para llevar adelante la tarea).
El caso de ATOP es similar, se trató de aumentar el valor entregado al cliente, pero al observar el plazo de espera (Leadtime), esto es, desde la concepción de la idea hasta la entrega final al cliente, ello no hacía mayor diferencia.
Estos son ejemplos claros de Eficiencia vs. Eficacia.
En la primera (eficiencia) se favorece a una optimización local para obtener un resultado tangible de forma veloz o se opta por seguir y mejorar los caminos habituales sin desafiar al status-quo de la organización. Ellos son comunmente vistos en empresas altamente jerárquicas o con alto número de silos o burocracia o entornos altamente politizados y sin mejora continua.
En la segunda (eficacia), se centra en aquellas piezas del puzle necesarias para que a nivel global se pueda cumplir el objetivo lo antes posible sin un incremento en deuda de conocimiento, técnica o humana (emocional). Aquí pones tu energía en completar el rompecabezas, mientras que en la primera opción (eficiencia) en poner tu pieza de la forma más rápida posible.
Marcar la diferencia cada día entre eficacia y eficiencia es un buen sitio donde comenzar a trabajar en las futuras organizaciones ágiles.
Gracias por escucharme,
Erich.
