Por qué la cascada no se adapta

Recientemente un grupo de profesores en línea me preguntó si Scrum a escala™
funciona. Estaban de acuerdo en que los enfoques ágiles funcionaban en equipos pequeños, pero se preguntaban por los proyectos grandes. Les dije que tenían que hacer los deberes y leer la bibliografía, además de hablar con las principales empresas del mundo que aplican Scrum.

Predictivo frente a empírico
Lo que Ken Schwaber y yo aprendimos del Prof. Oggunaike y Ray, autores de "Ingeniería y control de procesos" es que las plantas químicas de Dupont tienen dos tipos de procesos, los procesos predictivos, con menos de un pequeño porcentaje de variación durante la producción, y los procesos empíricos, que tienen una variación mayor. Todas las plantas químicas de Dupont que explotaron fueron el resultado de aplicar un sistema de control de procesos predictivo a un proceso empírico. Señalaron que la gestión tradicional de proyectos en cascada es un sistema de control de procesos predictivo que dará lugar a grandes tasas de fracaso siempre que los cambios en los requisitos superen unos pocos puntos porcentuales. Por eso la tasa de fracaso de los proyectos de software es de 89% en la gestión tradicional de proyectos. Es un mecanismo de control de procesos totalmente inadecuado en un entorno en el que 65% de los requisitos cambian durante el desarrollo. De hecho, los profesores se rieron de nosotros por ser tan estúpidos y seguir con la gestión de proyectos en cascada ante el abrumador fracaso de los proyectos. Nos dijeron: "leed el libro de control de procesos y haced Scrum un sistema empírico de control de procesos". Seguimos sus instrucciones.

Ejemplos de Scrum y equipos ágiles que rescatan proyectos fallidos en cascada
Puede leer cómo el FBI resolvió el problema de seguimiento del 11-S pasando de la cascada al Scrum en mi libro "Scrum: El arte de hacer el doble de trabajo en la mitad de tiempo." El primer capítulo describe los pormenores del proyecto de integración de todos los datos necesarios para rastrear a los terroristas. Tras muchos años con cientos de personas y $400M gastados, la Oficina General de Contabilidad de EE.UU. cerró el proyecto porque nada funcionaba y no se veía el final. El FBI contrató a un CIO y un CTO ágiles. Pusieron a unos 10% del personal original en el sótano del edificio del FBI haciendo Scrum y completaron el proyecto por menos de $50M. Este proyecto se utiliza hoy en día para llevar a cabo todas las operaciones del FBI. El sitio Obamacare healthcare.gov fue rescatado aún más rápido por un equipo ágil de seis personas de Silicon Valley en 6 semanas. Hay muchas experiencias de este tipo y esta es la razón por la que el Congreso aprobó hace unos años una ley por la que todos los proyectos de TI del Departamento de Defensa deben ser ágiles y por la que las normas de la Oficina de Correos de EE. UU. exigen Scrum o serás despedido.

Scrum ¿para proyectos más grandes? Sí Escalas Scrum

Puede leer cómo una agresiva empresa Scrum prospera dando soporte a 17.000 clientes en la nube echando un vistazo a un retrospectiva sobre Acquiaun socio de formación Scrum. Salesforce.com es aún mayor y cuenta con cientos de equipos Scrum. SAP, otro socio de formación, tiene 2.000 equipos Scrum. Amazon está trabajando con nuestro El hardware CSM entrena al Trainer cursos y tienen 1000 equipos Scrum.

¿Puede aplicarse el desarrollo ágil al desarrollo de productos tradicionales? - ResearchGate. Disponible en: https://www.researchgate.net/post/Can_agile_development_be_applicated_in_traditional_product_development#587e45fb4048543121791b6b [consultado el 17 de enero de 2017].