¿Los proyectos en tu organización se demoran cada vez más y necesitas entregar resultados? ¿Dicen que estiman mal? No estás solo. Conoce las posibles causas y cómo resolver este problema de manera sistémica en cuatro pasos.
Revisión 2025: Este artículo fue publicado originalmente el 26/5/21 (ver versión original), y revisado Enero 2025 con nuevas imágenes para ajustar a la notación de LeSS y cambios menores.
Hace unos años trabajé para un importante banco de Buenos Aires. El equipo estaba desarrollando un nuevo sistema para la red de cajeros automáticos que reemplazaría al actual -aún operativo, pero ya obsoleto y sin soporte del proveedor.
Cuando me convocaron, el proyecto ya tenía dos años de demora y varias renegociaciones de plazos en su haber. Como el nuevo sistema no llegaba, lo que inicialmente era una migración tecnológica derivó en nuevos proyectos: no podían esperar más, se hacía necesario implementar nuevas funcionalidades en el sistema vigente, más el retrabajo de replicar esas funciones en el nuevo.
En esos años habían probado todo lo que pudieron: pagar horas extras, reemplazar a la mayoría de las personas por otras de mayor Seniority, ampliar la capacidad con más equipos, capacitación, incluso cambiaron al gerente a cargo del proyecto, pero nada daba resultado. La desconfianza y las relaciones dañadas generaban más reuniones de status y control que quitaban tiempo de desarrollo. Los equipos se sentían muy presionados y estresados. Sin embargo, el proyecto no parecía avanzar.
Cuando no se entiende la causa del problema, se miran solamente los síntomas. Pueden decir que las estimaciones están equivocadas, y que los equipos tienen que mejorar como estiman. Como consecuencia se invierte más tiempo en análisis cada vez más detallado de requerimientos en lugar de resolver el problema de fondo.
¿Qué estaba fallando?
Yo sabía que este era solamente la punta del iceberg, para entender las causas del problema, debemos tener un entendimiento profundo del sistema organizacional. Fue entonces cuando decidí hacer un modelado sistémico con diagramas de relación causal para ver el sistema completo.
“Cuando no vemos los Sistemas, estamos a su merced”
Barry Oshry, Seeing Systems
Causa #1: La cantidad de trabajo en curso
La conocida «Ley de Little» 1 explica la relación sistémica entre la cantidad de trabajo en curso y los tiempos de entrega: para un proceso dado, en general, cuanto más cosas trabajes simultáneamente (en promedio), más tiempo tomará que cada una de esas cosas termine (en promedio)
A mayor cantidad de proyectos en curso, mayor será el tiempo promedio de entrega de cada proyecto. Por otra parte, cuanto más tiempo demoran los proyectos menor es la paciencia de los stakeholders de esperar a que se completen para comenzar nuevos proyectos. En otras palabras, mayor es la presión de comenzar a trabajar en nuevos proyectos, que representan nuevas oportunidades de negocio.
Por otra parte, la “falacia del costo hundido”2 explica por qué muchos proyectos rezagados no se cancelan. Se trata de un sesgo que nos hace pensar que como ya se ha invertido mucho tiempo y dinero en un proyecto, debemos continuar hasta terminarlo. Ya que cancelarlo sería reconocer que todo lo invertido fue un completo desperdicio, lo que muchas veces conlleva un alta costo político.
El siguiente diagrama ilustra esta situación, donde se puede apreciar que se genera un ciclo vicioso: a mayor tiempo de entrega – si no se toman medidas explícitas- eventualmente habrá más proyectos en curso. Lo cual a su vez genera más demoras. Este efecto de «bola de nieve» en el modelo sistémico se conoce como «bucle reforzador«.
Nota: Adopto la notación gráfica que se emplea en los cursos de LeSS (Large LeSS Scrum) 3
¿Cuál es la relación con la agilidad organizacional?
La popular frase “fail fast, learn fast” (fallar rápido, aprender rápido) refiere a que debemos realizar experimentos cortos para aprender de ellos. Cada proyecto ejecutado es una oportunidad de aprender que funcionó y decidir cuál es el próximo proyecto más importante. Las organizaciones necesitan adaptarse rápidamente para aprovechar nuevas oportunidades con ventanas de tiempos cada vez más cortos. Esto no es posible cuando los proyectos se demoran demasiado.
Si los proyectos se demoran, la organización pierde su capacidad de entregar valor y adaptarse.
Si bien de forma aislada cada causa de demora hace su aporte en el problema, lo realmente alarmante está en los efectos sistémicos de los ciclos reforzadores.
Causa #2: Estimaciones demasiado optimistas que se tratan como compromisos
El Cono de la Incertidumbre4 es un modelo que describe que al inicio de un proyecto de software, el error de estimación oscila en un factor de entre 0.25x y 4x. La brecha se va reduciendo a medida que se avanza en el proyecto y solo se cierra cuando el proyecto se termina. Es decir, que los proyectos donde hay incertidumbre y variabilidad, intentar predecir desde el comienzo el alcance total y la fecha de entrega es una estimación que tiene demasiado margen de error para ser de utilidad o para coordinar compromisos con otros equipos.
En ocasiones los proyectos comienzan con el pie izquierdo: cuando los equipos estiman plazos demasiado optimistas. Ya sea por presión externa o por el fenómeno conocido como “wishful-thinking” -un sesgo cognitivo de pensamiento optimista que nos hace asumir que no habrá imprevistos.
He visto innumerables veces como las estimaciones son tratadas como fechas certeras y compromisos firmados con sangre y en base a esto los gerentes coordinan, a su vez, otras actividades y asumen nuevos compromisos con clientes y stakeholders. Así los plazos y compromisos quedan atados a las estimaciones originales de los equipos.
Muchas veces estos gerentes son la cara visible hacia el resto de la organización y hacia los clientes, y cuando los planes no se cumplen responsabilizan a los equipos. Los gerentes tradicionales gestionan a las personas buscando incrementar la presión por entregar, asumiendo que el problema raíz es la falta de interés y fallan en “ver el sistema completo”. Es decir, es como la organización está diseñada para favorecer los resultados que se obtienen.
Las conversaciones tensas que resultan de estas situaciones reducen la confianza en ambos sentidos de la relación, lo que a su vez impacta negativamente en la motivación y en el compromiso emocional que los equipos están dispuestas a invertir en la empresa, empeorando la situación una vez más con otro bucle reforzador.
En otras empresas encontré una variante de este factor: un tercero es quien define las fechas de entrega de manera unilateral. Por ejemplo, un vendedor cierra una venta y firma un contrato con un cliente prometiendo una fecha que no fue validada con los equipos que van a desarrollar el producto. Si bien la situación es distinta, el impacto en este análisis es similar.
Causa #3: La deuda técnica desatendida
El término “deuda técnica” 5 fue acuñado en 1992 por Ward Cunningham-uno de los co-autores del manifiesto ágil. Es una metáfora que describe la decisión de postergar ciertas actividades, generalmente relacionadas con la calidad del producto, para acelerar la entrega de software en el corto plazo. Pero como en toda deuda, se debe pagar luego con intereses. En el caso de software, implica un retrabajo en el futuro para atender la calidad del producto y hacerlo sostenible.
El problema mayor ocurre cuando la pagar la deuda técnica se posterga indefinidamente. Así es como la presión por entregar influye negativamente en la calidad de los productos, lo que a su vez genera consecuencias que impactan en los tiempos de entrega. Por ejemplo, no se automatizan las pruebas, no se revisa ni mejora el código, los controles de calidad se hacen a las apuradas con pruebas superficiales. Eventualmente se produce defectos y el tiempo es usado en la gestión de los mismos, la gestión de reclamos, retrabajo para solucionar los problemas, mantenimientos y mayor esfuerzo para hacer cambios sobre un producto mal construido. La “deuda técnica” son grandes causantes de demoras. Como se puede ver en el siguiente gráfico, aquí también se genera otro ciclo vicioso. Tanto por el retrabajo de pagar la deuda técnica como el retrabajo por los defectos.
Causa #4: Fragmentación del tiempo
Este factor describe la situación en donde el tiempo disponible para trabajar en el desarrollo del producto está dividido en porciones pequeñas de tiempo durante la jornada laboral. Cuando los equipos estiman el tiempo requerido, muchas veces suponen que tendrán el día libre para trabajar en un solo bloque. Sin embargo, rara vez esto ocurre.
En el caso analizado, luego de cada fecha incumplida, se debía hacer un nuevo acuerdo de plazos. Se efectuaba una re-planificación y re-estimación del trabajo pendiente, esta vez con un mayor nivel de detalle. Debido a la confianza reducida se introducían más mecanismos de control: reuniones de estado, actualización de reportes de avance, documentar los compromisos en E-mails, control de horas e interrumpir continuamente al equipo para preguntas de seguimiento.
Hay dos impactos negativos que se producen con estas actividades. El más evidente es que se insume tiempo valioso que podría dedicarse al desarrollo del proyecto. El proyecto está en pausa cada vez que el equipo o personas clave están en una reunión de seguimiento o completando planillas y reportes. Paradójicamente, las personas con mayor expertise y que más podrían aportar al avance de los proyectos son quienes más ocupan su día de reunión en reunión porque son también quienes tienen las respuestas que los gerentes necesitan.
Por otra parte, las interrupciones durante un proceso de pensamiento creativo tienen un gran impacto en la productividad, ya que luego de una interrupción -por más corta que ésta sea- se requiere tiempo y energía para retomar el tren de pensamiento. En un análisis realizado por el Georgia Institute of Technology en 20106 sobre 10 mil programadores se encontró que en promedio lleva entre 10 y 15 minutos para volver a escribir código luego de una interrupción.
Producto también de la optimización de costos y maximización de la utilización de las personas, y la cantidad de trabajo en curso, los integrantes del equipo debían repartir su tiempo entre distintos proyectos. Con lo cual, se generaba un gran desperdicio de tiempo en el cambio del contexto y en las dependencias (cuando una persona necesita de otra, no puede atenderla porque está en una reunión por otro proyecto.
Cuando las personas están asignadas a múltiples equipos y proyectos se pierde el sentido de pertenencia y cohesión del equipo, lo que también reduce la motivación y compromiso que las personas están dispuestas a invertir en el equipo.
Causa #5: Agregar más personas
Otro factor que genera interrupciones y distracciones es incorporar más personas al proyecto. La ley de Brooks (1975) 7 señala que cuando un proyecto de software se encuentra demorado, asignar más personas lo retrasa aún más. Esto es debido a que la nueva incorporación debe aprender sobre el contexto del proyecto, los requerimientos, las herramientas que se emplean y adaptarse a las dinámicas del equipo. Situación que insume tiempo a las personas que ya tenían sus horas asignadas al desarrollo.
En el caso analizado, para optimizar costos se contrataron estudiantes a través de un acuerdo de pasantías con dos universidades. La falta de experiencia insumió más tiempo de capacitación y entrenamiento. Luego de no tener resultados favorables, se hizo un reclamo a una de las universidades para que los reemplacen por otras personas más experimentadas; la capacitación tuvo que volver a comenzar.
Otro impacto adicional, es que un equipo más grande conlleva más complejidad. Las líneas de comunicación entre personas aumentan exponencialmente siguiendo la fórmula N(N-1)/2, donde N representa el número de personas. Por ejemplo en un equipo de 10 personas hay 10(10-1)/2 = 45 canales de comunicación, mientras que con 14 personas hay 91 canales de comunicación entre los integrantes del equipo. El tamaño del equipo influye notablemente en la duración de las reuniones y en la cohesión del equipo.
Causa #6: Las dependencias entre equipos.
Hay un motivo por el cual las organizaciones ágiles promueven equipos autónomos: para que puedan avanzar en los proyectos sin depender de otros.
Cuando un proyecto que está a cargo de un equipo requiere colaboración de otro, es posible que exista un conflicto de prioridades. Como resultado, el proyecto nuevamente cae en tiempos muertos. Usualmente, ante la imposibilidad de avanzar con el trabajo priorizado, el equipo decide abrir una nueva tarea, incrementando aún más la cantidad de trabajo en curso.
Por ejemplo, en una empresa donde trabajé, el equipo “A” debía utilizar un servicio desarrollado y mantenido por el equipo “B”. Sin embargo el sistema presentaba un defecto de calidad, que para el equipo “B” no era para nada relevante y por lo tanto lo iban a solucionar porque tenían otras prioridades que atender. Sin embargo, para el equipo “A” resultaba bloqueante para un proyecto prioritario.
La existencia de dependencias entre equipos muchas veces responde a una decisión de diseño organizacional que busca optimizar costos y maximizar la ocupación a costas del flujo de trabajo y la velocidad de entrega.
Las Demoras Sistémicas
Las demoras son el factor que más dificulta ver las correlaciones sistémicas. Muchas veces en los sistemas, transcurre un tiempo indeterminado entre una causa y sus efectos sistémicos, haciendo muy difícil relacionar ambos factores. El análisis sistémico nos permite ver el sistema completo para identificar estas correlaciones más allá de la variable del tiempo. En el diagrama se representa con una línea de relación causal interrumpida.
El modelo completo
Aquí es donde se ve lo realmente interesante: cuando conjugamos estas causas aisladas y análisis parciales y diagramamos el modelo sistémico completo nos encontramos con una situación muy compleja, ya que cada uno de estas causas se refuerza con las demás y se generan múltiples bucles reforzadores que potencian los efectos descriptos.
Así, los nuevos proyectos quedarán bloqueados cada vez más rápido. Los proyectos pasan más tiempo en “espera” que en progreso, a pesar de que todas las personas se encuentren trabajando a su máxima capacidad o incluso estresadas con horas extras. Los tiempos muertos y los cuellos de botellas hacen que la organización se estanque por completo.
El diagrama del sistema analizado queda así:
La solución en cuatro pasos: Palancas Sistémicas
Resolver esta situación requiere una estrategia de liderazgo de la organización con una mirada sistémica. Los equipos por sí solos no pueden resolver el problema, necesitan del apoyo del liderazgo. Los siguientes cuatro pasos pueden llevar a la organización a un mejor contexto.
Paso 1) Identificar la situación para hacerla visible. El análisis sistémico nos sirve para esto. Si no vemos el problema no podremos actuar sobre él.
Paso 2) El liderazgo de la organización debe tomar la decisión de optimizar los resultados de la organización. Es decir, una optimización global por sobre una local. Optimizar el flujo por sobre la ocupación de las personas.
- La optimización local se refiere a la eficiencia recursos y la productividad de lo que produce cada equipo (o peor aún, cada individuo). Métricas relacionadas son generalmente de «output»: horas trabajadas, story points, cantidad de software producido, nivel de ocupación.
- La optimización global se refiere a lo que la organización logra entregar al cliente. Las métricas relacionadas son generalmente de «outcomes»: cantidad de proyectos completados, tiempo total de entrega al cliente, y métricas que reflejan la satisfacción del usuario o del cliente y los resultados del negocio logrados.
Paso 3) Identificar las Palancas Sistémicas y actuar sobre ellas.
Las palancas son los puntos en donde podemos intervenir el sistema para lograr resultados. Para este caso en particular, podrás encontrar en el diagrama variables de color azul, estos son los puntos clave de apalancamiento que identifiqué.
Todas ellas están allí por decisión de alguien, por lo tanto están dentro del ámbito del control del liderazgo. Como toda palanca, con un poco esfuerzo, se puede lograr grandes resultados.
Con esta información se puede armar un plan estratégico de mejora global que revierta la situación problemática de forma definitiva.
Paso 4) Mejora continua para optimizar el flujo en la organización.
La estrategia de liderazgo debe priorizar que los proyectos fluyan, minimizando los tiempos de espera, dependencias, cuellos de botella y otros impedimentos organizacionales. Siendo esto más importante que maximizar la ocupación de las personas.
Henrik Kniberg lo llama “escapar a la trampa de la utilización de recursos” y lo demuestra con una simple metáfora en este video. Al igual que Niklas Modig en su libro This is Lean 8
Conclusiones
Una de las frases famosas en el método Kanban es “stop starting, start finishing” (“dejar de comenzar, comenzar a terminar”). Para esto se propone como práctica central limitar la cantidad de trabajo en curso para gestionar la capacidad limitada y preservar el flujo.
Un dicho popular dice: “si estás en un pozo, deja de cavar”. En una organización que se encuentra con demoras en los proyectos, lo mejor es dejar de asumir nuevos compromisos para dar lugar a que los proyectos en curso se completen.
Al limitar el trabajo en curso, los impedimentos se hacen visibles y eso es el primer paso para resolverlos. Sin este límite es más fácil trabajar en «lo que se puede», en lugar de «en lo que realmente se debe» y los problemas se esconden dentro de la alta ocupación.
En Lean este concepto se ilustra con una metáfora, en la que el agua (la cantidad de trabajo) tapa los problemas.
Esta regla nos lleva a priorizar a conciencia los proyectos que más valor tienen para el negocio y ayuda a que los equipos mantengan foco en completarlos.
Una vez logrado el flujo de trabajo, estaremos en condiciones de ajustar la cantidad de proyectos en curso. El objetivo será buscar cuántos proyectos puede gestionar la organización sin perjudicar los tiempos de entrega.
Sin tiempos de espera, los proyectos se completan tanto más rápido que será más fácil evitar que los proyectos se acumulen.
Estos cuatro pasos, no son simples de implementar, pero al hacerlo estaremos generando una transformación importante en la organización, llevándola a una forma más lean y agile de gestionar el trabajo.
Tal vez un paso más pequeño para comenzar, puedes utilizar estas 10 estrategias para agilizar cualquier proyecto.http://www.caminoagil.com/2019/11/27/como-agilizar-cualquier-proyecto-10-estrategias-clave/
Este es un ejemplo muy ilustrador de cómo puedes aplicar el pensamiento sistémico en un problema organizacional para hacer visible los impedimentos a quienes lideran la organización.
El liderazgo ágil debe trabajar sobre el sistema, es decir, ver todos los factores y las relaciones causales para realizar intervenciones sistémicas. Si se falla en ver el sistema, se interviene solamente en las partes que se ven y como vimos en el ejemplo, esto puede empeorar la situación. La solución debe ser sistémica. Se deben abordar todos los factores mencionados en simultáneo para lograr un diseño organizacional más efectivo.
Si bien, vemos cómo múltiples factores se interrelacionan, también podemos ver que los seis factores que describimos en este análisis están dentro del control del liderazgo y de los equipos si trabajan en conjunto.
El problema se resuelve si se decide disponer de equipos dedicados, atención a la calidad, limitar el trabajo en curso para maximizar el flujo y cambiar el estilo de gestión en torno a los plazos y estimaciones. Una solución sistémica aborda múltiples factores en simultáneo.
Te invito a compartir este artículo con el próximo manager que diga que los equipos deben aprender a estimar mejor, cuando en realidad sabes que hay un problema mayor de fondo.
¿Qué te pareció? Sigamos la conversación en LinkedIn
Este contenido se distribuye de manera libre y gratuita. Si te gustó o te resultó de utilidad puedes considerar hacer una pequeña contribución (desde 5 dólares) para reconocer las horas invertidas. Es fácil y seguro con tu tarjeta.
¡Muchas gracias por leer hasta aquí y muchos éxitos en tu camino ágil!
Referencias:
- https://en.wikipedia.org/wiki/Little%27s_law ↩︎
- https://en.wikipedia.org/wiki/Sunk_cost ↩︎
- https://less.works/less/principles/systems-thinking ↩︎
- https://en.wikipedia.org/wiki/Cone_of_uncertainty ↩︎
- https://martinfowler.com/bliki/TechnicalDebt.html ↩︎
- https://sites.cc.gatech.edu/fac/Spencer.Rugaber/vita/vita.pdf ↩︎
- https://es.wikipedia.org/wiki/Ley_de_Brooks ↩︎
- https://thisislean.com/ ↩︎
Actualización: Enero 2025
Camino Agil - Tu camino a la Agilidad 
Debe estar conectado para enviar un comentario.