Hace unas semanas, Standish Group puso a disposición de sus clientes el último informe Chaos (enlace de pago, no esta disponible gratuitamente). Hay varias novedades, entre ellas que esta tercera edición -las anteriores son de 2014 y 1994- cambia la manera de definir éxito en la resolución de proyectos y ahora tienen en cuenta la satisfacción del cliente, en lugar de medir solamente si el proyecto estuvo dentro de presupuesto, se consiguieron los objetivos y se entrego a tiempo. Otra de las novedades es que tienen en cuenta los cambios de alcance para evitar penalizar a aquellos proyectos que definen sus objetivos a lo largo del proyecto en lugar de al principio del proyecto.
Para elaborar este informe, Standish ha utilizado la base de datos CHAOS con los datos de los anos 2011 a 2015, durante el ano fiscal estadounidense.
Agile vs Waterfall
El informe Chaos deja claro la superioridad de las metodologias agiles de desarrollo de Software (Scrum, Kanban, XP, etc…) sobre las tradicionales en casacada (PMBOK, Prince2) y confirma el acercamiento que han tenido estas ultimas hacia métodos mas ágiles en los últimos anos.
En concreto, solo el 9% de los proyectos que se desarrollaron bajo metodologías ágiles se consideraron como un fracaso, siendo el 39% de ellos un éxito y el 52% problemáticos. Dentro del mismo segmento, los proyectos desarrollados con metodologías en cascada tuvieron una tasa de fracaso del 29%, problemas un 60% y solamente un 11% fueron considerados como un éxito.
Este dominio es aun mas claro cuando miramos el tamaño de los proyectos. En el caso de los proyectos pequeños, las metodologías ágiles tienen un 58% de éxito y solamente un 4% de fracaso. El informe también pone de manifiesto que los proyectos ágiles escalan mucho mejor, aunque no tan bien como cuando se trata de proyectos pequeños.
La Ley de los retornos disminuidos establece que cuando aumenta el tamaño de un sistema, añadir más elementos al sistema dará menos retornos hasta llegar a ceroEn el ano 2015, parece que el ganador de la batallas Waterfall vs Agile es claro. Pero todavía queda un problema todavía grande: el tamaño de los proyectos. Standish deja claro que el tamaño de los proyectos es el mayor indicador del fracaso de los mismos, y que mientras que los proyectos pequeños con equipos con talento tienen pequeñas tasas de fracaso, aquellos que tienen un alcance gigantesco con miles de personas alrededor, tienden a fallar.
Parece que casos como los del FBI, donde se paso de 400 desarrolladores a 40 y se saco el proyecto adelante, o el mas reciente de Healthcare.gov confirman estos datos. Equipos ágiles bien preparados son una garantia de éxito.
Ser agil no te salva, tienes que tener equipos competentes
Pero Agile no es la bala de plata que muchos piensan. Tal y como el informe pone de manifiesto, las diferencias entre equipos ágiles competentes y preparados con respecto a aquellos que no lo están es grande. Aquellos proyectos que no tenian personas competentes mostraron las tasas de fracaso (23%) y problemas (60%) mas grandes. Esto tiene una explicación muy sencilla. Los métodos ágiles de desarrollo de Software permiten optimizar el flujo de valor fácilmente, pero esa es solamente una parte. Después de optimizar el flujo de valor, es necesario llevar a cabo el proceso de desarrollo.
La ley de los retornos disminuidos dice que, en todos los procesos productivos, anadir uno o mas factores de producción manteniendo los otros constantes, dará menos retorno en algún punto. Un equipo ágil trabajando con Scrum que no tenga conocimientos técnicos, se beneficiara de la optimizaron del flujo de valor (en caso de que tenga un Product Owner competente) pero no sabra como aprovecharlo. Mientras que un equipo ágil que trabaje con las herramientas adecuadas y tenga conocimiento de dominio y competencia, sabra poner a su servicio todas las herramientas que necesita para llevar el proyecto adelante.
Aun así, muchas empresas siguen contratando nuevos ingenieros, mas senior y mas preparados sin darse cuenta de que solamente anaden mas complejidad a una situation mas complicada. He recomendado de-escalar a algunos de mis clientes porque, simplemente, les sobraba la mitad de la fuerza productiva. Esa es una de las razones por las que muchas empresas están descubriendo que hacer insourcing es mas barato que hacer outsourcing.
[…] cuando muchas personas no terminan de creer en la aplicabilidad de Scrum, los reportes de la industria dejan muy claro que la capacidad de incrementar la transparencia y las posibilidades de inspección […]