Agile no se aprende en un día, para los de PMO, Agile va mas allá de lo que creen, ya que antepone la calidad del producto antes de que llegue la fecha de entrega, inmiscuye al cliente en todo el proceso lo cual no hacen los métodos de la PMO, Agile es TDD, CMDB, TEST, QA, XP, etc.

Si no se ha trabajado en conjunto con PMO y Agile, lo mejor sería no opinar.

Me sorprende leer la facilidad con que los cultores de los modelos Agile suelen desacreditar a todos ellos, siempre basados en múltiples lecciones aprendidas y recogiendo las mejores prácticas.

Después de leer este artículo y varios textos al respecto, me he formado una impresión, que equivocada o no, es refrendada por todos quienes dan su opinión y por la descripción formal de Scrum y otros modelos “ágiles”.

Si buscan el CHAOS Manifesto 2013 (Standish Chaos Report) podrán ver que los índices de fracaso y fallas en los proyectos tecnológicos se ha mantenido, salvo escasas excepciones, en forma casi inalterable, es decir, no evidencia empírica de un mejoramiento en los KPI de cualquier proyecto, en especial la sitisfacción del cliente (calidad) que sustente que los nuevos modelos hayan aportado “algo nuevo en el horizonte” de los proyectos TI. Consideren que la base de datos de CHAOS es de 50.000 proyectos y que sigue mostrando desviaciones importantes (considerablemente más que en cualquier otra industria) en los conceptos de plazos, costos y alcance.

Reconozco que las TI han revolucionado la forma de mirar el mundo. Soy de los que sostiene que eso lo han logrado sólo dos grandes inventos (imprenta e internet), pero no soy capaz de imaginarme como la falta de visión del todo puede lograrse a través de incrementos no planificados como una parte del total y menos que esto sólo esté en la visión de “unos pocos”.

El mayor problema de los proyectos TI sigue siendo la falta de una métrica de avance confiable. Todo esfuerzo por modelar un sistema de medición de avance ha fracasado, pero eso no justifica que debamos olvidarnos del rendimiento de los recursos, comprometer hasta tres o cuatro veces los mismos recursos en distintas propuestas (¿les suena familiar?).

Propongo que antes de seguir buscando soluciones “geniales” se discuta detenidamente sobre las causas de fracaso en los proyectos TI, especialmente en lo referido a la falta de definición y claridad del alcance del proyecto y de su producto, aspecto repetido en toda encuesta disponible y que Ágile desestima. Cualquier modelo no predictivo termina siempre en un “nunca termina”. Su cliente sigue pensando que lo puede cambiar todo, con o sin Scrum, y de facto sigue haciéndolo.

En mi opinión, la base del éxito sigue estando, como en cualquier otra industria, en la asertiva gestión de requerimientos y la de los cambios solicitados (formulación, entendimiento común, trazabilidad con los objetivos, verificación y validación de requerimientos).

Sin duda, estoy abierto al debate de las ideas.
Saludos desde Chile.
Edgardo

Sin embargo, sin afectar a esos procesos ya definidos, se pueden agregar, más no quitar, métodos o herramientas que te puedan ayudar al logro de los objetivos, a veces es cosa de las necesidades de negocio o del cliente que quiere ver avances cada semana.

En fin, a mi parecer, por eso somos PROFESIONALES, debemos ser capaces de aplicar aquello que nos va a llevar a lograr los objetivos del proyecto, eso si, asumiendo toda la responsabilidad del éxito o fracaso de lo que apliquemos.

Saludos desde México.