Van a cumplirse 5 años, como pasa el tiempo, desde la publicación en 2012 de aquel post, que algunos aman, y por el que otros me odian, de Diagramas Gantt cómo arma de destrucción masiva de proyectos. Maneras de usar un Gantt para matar un proyecto (puedes tomar el post de hoy como complemento al anterior, que te recomiendo leer).
Creo que hay post, o más bien temas que han sido escritos en post, sobre los que conviene volver a reflexionar habiendo pasado el tiempo necesario.
Así que voy a volver a dedicarle un post (de nuevo) a los Gantt, cosa que esperaba no tener que volver a hacer después de aquel de hace 5 años. Pero aquí estoy, por varias razones, siendo la principal el que siguen siendo una herramienta HOY muy usada y aún HOY tengo mis “duros” debates con mucha gente sobre las razones que hacen que su uso sea inútil (ya no te cuento si usas Scrum o similar) y aún mucha gente sigue sin entender las verdaderas y profundas razones que los hacen inapropiados, quedándose sólo en la parte más superficial del debate.
Para defender su eliminación debiera bastar el alto ratio de fracaso que tienen (y curiosamente los muchos años que se siguen intentando usar sin éxito, fallando en su mayoría una y otra vez) cuando se utilizan en “proyectos” de base tecnológica, basados en software, etc., pero profundicemos un poco más y esto te lo cuenta uno que tuvo que estudiar Gantts y que durante muchos años tuvo que usar Gantts (muchos, me hinche a hacer, y quizá por eso ahora soy como los exfumadores cuando ven a alguien fumando) en proyectos…
Muy breve historia de los Gantt, para que entiendas de dónde vienen
¿Quién inventó el Gráfico de Gantt? El padre es Henry Gantt, de ahí el nombre, que nació en Maryland en 1861 (hace más de 150 años).
Desde casi el comienzo de su carrera profesional Gantt tuvo un mentor, adivina… Taylor, cuyas ideas por desgracia arrastramos en la “gestión” de muchas empresas de hoy (si no lo leíste yo me leería aquí El origen del management, el Taylorismo y su maligna herencia en tecnología).
Y ambos trabajaron juntos. De hecho, Taylor recomendó a Gantt como una de las personas más preparadas para llevar a cabo su “gestión científica” (aunque, cierto es que Gantt fue más “light” en sus pensamientos), si esa, de separar a los que piensan de los que hacen, crear jerarquías, etc.
El 1917 Gantt crea su famoso diagrama para, ojo…mejorar la construcción de barcos (allá durante la I guerra mundial). Así que, curioso, estamos hablando de algo de hace ahora 100 años.
¿Por qué no van bien los Gantt en la gestión actual (ágil)?
Por razones que ya hemos comentado muchas veces, y no aplica volver a justificar, hay, de muchos, varios objetivos perseguidos (o logrados en el mejor de los casos), por aquellos que quieren gestionar productos – servicios – negocios (no hablaría ya ni de proyectos) basados en software, voy a destacar algunos: innovación – «»»requisitos»»» cambiantes – hypotesis – “adaptación al cambio más que seguir un plan” y la auto-organización de los equipos (mirate, por poner alguna referencia, aquello de La Teoría X (gestión industrial) y la Y sobre la motivación).
Y para los anteriores, entre otros, por destacar algunos, los Gantt no ayudan nada, es como poner clavos con un destornillador, si, no sé quizá se pueda, pero es como pasar un rato en la “Wheel of Pain”.
Para la auto-organización y para los “planes” cambiantes los backlog, los tableros (gestión visual) y los gráficos burn, típicos en gestión ágil, se adecuan muchísimo mejor, por varias razones que hacen que no sean comparables a los Gantt:
- La gestión visual y los tableros son más simples que el Gantt… y eso da acceso a más gente a la auto-organización.
- La gestión visual y los tableros están pensados para que lo vea todo el mundo (radiador de información) sin pedirlo… el Gantt tienes que ir al Project o lo que sea y abrirlo. O te lo imprimes y lo pegas en la pared, y lo imprimes cada vez que cambia… raro.
- Y por ello, el tablero da “feedback” constante a mucha gente (potencia la transparencia), el Gantt no está pensado para eso.
- El tablero casi obliga al flujo continuo… en el Gantt puedes olvidarte de ello.
- El Gantt lleva implícito gestión predictiva, no adaptativa, e idea de cerrar un plan y que no cambie.
- Aunque uses Sprints, no tiene sentido usar un Gantt dentro del Sprint porque eso no sería un Sprint, porque eso metería predictivilidad, olería a fases en vez de tareas, etc.
Y seguro que me dejaré más motivos.
El Gantt, por naturaleza, no está pensado ni para potenciar la auto-organización de los equipos ni para los planes cambiantes, es decir, la adaptación al cambio, innovación, etc.
Para más datos… “Los Gantt están prohibidos en Scrum”
Así que, sí, puedes usar Gantts y te puede ir genial con ellos, puedes haber encontrado una maravillosa manera de usarlos con Scrum, raro es, pero bueno, pero entonces lo que haces es… un “Scrum-but”, un «Scrum con peros» (de dejo más Scrum con peros aquí), algo que no es Scrum, porque en Scrum los Gantts fueron “deprecated”. Y no es que lo diga yo, lo dicen los que inventaron Scrum.
Te resumo y cito casi literal del anterior enlace…
Los diagramas de GANTT tienen alguna utilidad cuando un Product Owner tiene que presentárselos a los ingenuos usuarios para obtener financiación para un proyecto. Cuando la guerra comienza, todos los planes se rompen y la primera línea debe auto-organizarse para ganar.
Usar Gantt en los Sprint es hacer uso de un documento de planificación que está absolutamente equivocado después del primer día. Consume recursos inútiles en mantener el gráfico actualizado.
Los GANTT fueron prohibidos por estas razones cuando lideré la implementación inicial de Scrum en 1993. 13 años (a fecha de hoy serían 24) después no veo ninguna razón para cambiar esto. De hecho, después de consultar con las principales empresas en Silicon Valley y en otras partes del mundo este año pasado, actualizar los gráficos burndown es la prioridad. Cualquier distracción que venga del GANTT es inútil.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Hola Javier,
Como «scrum-but» master, me gustaría saber tu opinión respecto a lo siguiente: Usamos Scrum de una manera más o menos correcta, excepto por el hecho de que establecemos fechas límite para los proyectos, es decir, iteramos continuamente pero establecemos un tiempo máximo estimado para dedicar para cada proyecto. Lo hacemos porque algunos de nuestros product owners, principalmente de la propia empresa, tienen tendencia a sacarse requisitos continuamente de la manga, ya que piensan que una vez se cambia de proyecto es muy difícil que las mejoras se implementen a corto/medio plazo. Es una medida que tomamos para asegurar que los proyectos van saliendo, y para no encontrarnos que un proyecto pequeño se convierte en uno grande únicamente por el criterio de quién representa al cliente.
Si no estableces tiempos, cuándo acaba un proyecto si un product owner decide que todos los requisitos, por irrelevantes que sean, son imprescindibles? Es un tema que viene dado desde fuera de Scrum, por criterios comerciales, por ejemplo?
Gracias
Hola,
El tema es que los proyectos siempre tienen fecha fin pero los productos no, los productos no dejan de evolucionarse salvo que muera el negocio la que dan soporte…
Saludos