En la gestión predictiva, la "bola de cristal" con visión global de proyecto es el diagrama de Gantt. ¿Y en la gestión ágil?.
El modelo ortodoxo de Scrum trabaja con el Gráfico Burn-Down, pero es una bola de cristal que alumbra con "cortas": sólo al sprint actual.  Para vaticinar el proyecto "con largas", apuntando más lejos en la dirección de la visión del cliente, es muy útil el gráfico Burn-Up.
 

La tesis (ISO 12207, 15504, CMMI…) ha identificado y definido las cosas QUE hay que hacer.
La antítesis (XP, Scrum, FDD...) ha mostrado formas de trabajar que funcionan bien: CÓMO hacer determinados "qués".
Posiblemente la síntesis , la moraleja de ambos sea cuestionar los "POR QUÉs"

¿Qué hacer para que los proyectos de software salgan bien?

¿Que cuál es el modelo de negocio?. No, no hay modelo de negocio. Es muy pronto para definirlo. No trabajamos con un modelo de negocio, sino con un modelo de valor.

En cierto modo a la estrategia de negocio le ocurre lo que a la gestión de proyectos. Nos hemos acostumbrado a un modelo predictivo:
 

¿Por qué no aplicar Scrum en toda la empresa considerando a la organización en su conjunto, como un todo sistémicamente relacionado?

¿Por qué acomodar la empresa a la "forma" del modelo?: Sea la forma de Scrum o de DSDM o de CMMI. ¿Por qué no considerar a las formas como lo que son, y emplear los fondos de conocimiento que hay tras ellas para componer un modo de trabajo apropiado a las características de la empresa y de sus proyectos?

Scrum puede "implantarse" (forma) o "institucionalizarse" (fondo); y proporciona mayores cotas de agilidad cuanto más ágil es la empresa en su conjunto.

Poner un ScrumMaster en el departamento de programación de una empresa con visión y cultura apuntando en otra dirección, o sencillamente sin visión; con un área de RR.HH. no alineada hacia una gestión de personal ágil (gestión del conocimiento); con un departamento de marketing o de producto sin implicación en roles de propietario de producto; con áreas administrativas y comerciales trabajando sobre patrones de contratos de planificaciones cerradas... es una combinación peligrosa que suele producir empresas fragmentadas.

No todo lo que etiquetamos como procesos es la misma cosa. En algunos las personas ayudan al proceso, y en otros son los procesos los que ayudan a las personas.
En el primer caso el proceso es el protagonista, el que sabe cómo hacer el trabajo y la persona se integra en el sistema como instrumento, como operario de apoyo. En el segundo el artífice es la persona y el proceso una ayuda, una herramienta que simplifica aspectos rutinarios para que pueda lograr más eficiencia y no diluir el esfuerzo en rutinas mecánicas.

La firma argentina de consultoría Horus MS ha decidido adoptar los criterios de "síntesis de conocimiento " en sus servicios de formación y asesoría para desarrollo de software. De esta forma tomarán en cuenta la perspectiva general y sistémica de cada empresa y el tipo de proyectos que desarrolla, para diseñar así la estrategia y las pácticas ágiles y formales más adecuadas a cada caso .
 

SÍNTESIS
¿Qué es mejor, el yin o el yang?. ¿La tesis o la antítesis?. ¿Los procesos o la agilidad?.

Los gestores y modelos ágiles que dan la espalda a la gestión predictiva, emplean en su trabajo un fondo de conocimiento incompleto; y lo mismo ocurre con la gestión predictiva que ignora los valores y prácticas de los modelos ágiles.

GESTIÓN SISTÉMICA
Las empresas son sistemas inter-relacionados, y no departamentos separados conectados por procesos de negocio. Desde esta realidad sistémica, un gestor de proyectos trabajando con técnicas ágiles en una empresa cuyo departamento de personal, programadores, departamento comercial y directivos trabajan sobre supuestos predictivos, acabará con sensación de impotencia y ganas de tirar la toalla.

“Para que un esfuerzo de desarrollo de software tenga éxito, es esencial comprender perfectamente los requisitos del software. Independientemente de lo bien diseñado o codificado que esté un programa, si se ha analizado y especificado pobremente, decepcionará al usuario y desprestigiará al que lo ha desarrollado”.

Roger S. Pressman. Ingeniería del Software. Mc Graw Hill 1995.

Parece lógico suponer que antes de empezar a construir algo, lo mejor es conocer con detalle qué es lo que vamos a hacer. 

Cuestionar lo conocido genera la contradicción, la tensión entre contrarios que actúa de motor en la evolución del conocimiento.
No es nuevo. Lo afirmó Platón. En filosofía ha creado la escuela dialéctica , y Nonaka y Takeuchi, en su último líbro Hitotsubashi on Knowledge Management afirman también estár convencidos de que este patrón dialéctico de tesis, antítesis y síntesis dirige la evolución del conocimiento: antítesis que se oponen y cuestionan las tesis anteriores, y dan como resultado nuevas posturas de síntesis que a su vez harán el papel de tesis en el siguiente  ciclo evolutivo; formando así una espiral de evolución y perfeccionamiento continuo.

Estoy convencido de que los modelos basados en procesos han sido la "tesis" que inicia el conocimiento para desarrollar sistemas de software. Que la agilidad es su antítesis, y que estamos generando en estos años la síntesis; un resultado enriquecido de ambos, depurado y con mayor valor de conocimiento.

NUEVA SECCIÓN

ISO reconoce que los modelos de procesos tipo 12207 15504-CMMI son para organizaciones grandes y sistemas de software con niveles de integridad elevados; y mientras tanto muchas empresas pequeñas acuden a ellos buscando formas de mejorar su trabajo, o de abrillantar su imagen, o ambas cosas a la vez.

En el otro extremo surgen modelos y prácticas ágiles: AM, XP, FDD, Scrum, Crystal, DSDM, ASD, AD etc.
Prácticas que cubren en cada caso determinadas áreas técnicas (programación, diseño, modelado, datos...) o pautas para la gestión de los proyectos; Y modelos que dan cobertura a varias áreas de procesos como Crystal o DSDM.

Si en su empresa o en sus proyectos no trabajan más de 25 personas, y está pensando implantar modelos de procesos tipo CMMI o ISO 15504, le interesa mucho conocer las conclusiones a las que está llegando el comité ISO de estandarización para la Ingeniería del software (ISO/IEC JTC1 SC7):

"La industria del software reconoce la valiosa contribución de los productos y servicios aportados por las pequeñas empresas. Los estándares internacionales ISO no se han escrito para pequeños proyectos, organizaciones o empresas con menos de 25 personas".

En los años 50, 60 y 70, cuando se desarrollaban las bases de una gestión de proyectos basada en la planificación, los productos tardaban años en quedar obsoletos. Las empresas los concebían y diseñaban en un entorno relativamente estable, y luego se dedicaban a producirlos de forma constante durante años, introduciendo quizá algunas variaciones mínimas.

Apple ha desarrollado 6 generaciones de su popular iPod, en sólo 6 años.