¿Scrum o PMBOK?

La gente más afín a Scrum te dirá que si no practicas una metodología dentro del marco Agile estás anclado en el pasado, que para software es mucho más efectivo, y que es una metodología que aplican las grandes tecnológicas como Google, Yahoo, etc. Si te interesa Scrum y Agile, hace poco publiqué un post de introducción sobre ello.

Por otro lado, la gente que utiliza PMBOK te dirá que no hay nada como el desarrollo en cascada o Waterfall, con toda la información y requerimientos antes de iniciar el desarrollo, y que Scrum es una perdida de tiempo, sobretodo en España.

Personalmente, creo que todos tienen parte de razón. No hay una opción buena o mala, mejor o peor. Ambas opciones son bien válidas, hay que saber aplicar la metodología adecuada para cada situación.

El objetivo, la fecha, y el entregable

En un mundo ideal, bajo un PMBOK tienes muy claro cual es el objetivo final porque todo el proceso está descrito al detalle, mientras en Scrum tienes la idea del objetivo y el desarrollo se lleva a cabo sobre la marcha.

En un desarrollo en Waterfall tienes una fecha final de desarrollo medianamente realista porque está completamente planificado, teniendo siempre presente que cualquier desvío en las tareas retrasa la salida porque no tienes un producto entregable.

En Scrum te vas acercando poco a poco y de forma incremental a esa idea final, pero siempre acabando el ciclo de la iteración con un producto entregable. Es decir, que una vez llegada una supuesta fecha final, puede que no tengas el proyecto finalizado, pero puedes realizar una entrega totalmente funcional de un porcentaje avanzado del mismo.

Entonces diréis… Scrum es mejor, porque puedes entregar el 80-90% del proyecto en la fecha de entrega. Pero la verdad es que, ¿Cuando os habéis encontrado un proyecto donde os dejen entregar una parte y no os pidan el producto completo? Aunque se puedan fasear cierto aspectos o detalles, la mayoría de las veces os pedirán todo o nada.

Información y elementos disponibles

La diferencia principal entre Scrum y PMBOK es que éste último necesita de una toma de requerimientos previa a la planificación, un análisis tanto funcional como técnico, y una vez todo está firmado y planificado hasta el mínimo detalle, entonces arranca el ciclo de desarrollo.

En cambio Scrum juega con el Caos, es decir, no tiene porque existir un funcional, solo un rol que tenga la idea clara del desarrollo que se encargará de guiar al equipo hacia su objetivo priorizando las tareas y dando feedback continuo. Cada iteración constituye en sí una toma de requerimientos, análisis, planificación, ciclo de desarrollo, y entrega de producto.

Esta es la diferencia que determina el porque Scrum es mas abierto a cambios, porque desarrollar en ciclos cortos permite que una idea pueda ser maleable, mientras en PMBOK cualquier cambio de requerimiento supone para el proyecto, revisar los funcionales, y replanificar. Esto último en el mundo ideal, en el mundo real te comes el cambio y te callas :)

El Equipo

Un equipo en Waterfall sigue unas indicaciones, mientras que en scrum el equipo se auto-organiza en base a unas prioridades. Para llevar a cabo el trabajo Scrum dice que necesita de un equipo maduro.

¿Y eso que significa? Pues que en Scrum se necesita un equipo que haga suyas las tareas y responsabilidades, y se comprometa a cumplirlas en el plazo que el mismo equipo ha considerado. En cierto modo en PMBOK el equipo vive más tranquilo por no ejercer ese conjunto de responsabilidades, aunque se acaba trabajando igual.

Adquirir tanta responsabilidad no es algo que quiera todo miembro de un equipo. Muchas veces te encontrarás que hay gente que necesita que le detalles las cosas, y que prefiere no coger la iniciativa a la hora de resolver los problemas que surjan a lo largo del desarrollo.

Debes estar seguro de que tu equipo está preparado antes de aplicar Scrum. El equipo es fundamental para el éxito en Scrum.

Si pensabas que no afecta al equipo, estabas bien equivocado.

Reuniones y seguimiento

En el caso de PMBOK, se realizan reuniones para el inicio del proyecto, reuniones de seguimiento del proyecto, y reuniones de fin de proyecto con carácter de revisión de errores y aprendizaje de los mismos. Por supuesto, las reuniones están ya fijadas antes de iniciar el ciclo de desarrollo, y según el avance del mismo, se pueden llegar a establecer más reuniones de seguimiento si es necesario.

En el caso de Scrum, es un concepto bastante parecido pero aplicado a la iteración corta y con más seguimiento por la falta de detalle del proyecto. Tenemos las reuniones diarias para revisar en equipo el compromiso de cada uno, las reuniones de planificación, las de review del producto y feedback de Product Owners, y por último las de retrospectiva, también para analizar problemas y errores, y aprender de ellos de cara a la siguiente iteración.

Si quieres saber más, hace un tiempo publique un post sobre Los Scrum Meetings.

Resistencia al cambio

Aquí no vamos a diferenciar entre ambas metodologías, ambas se encuentran con el mismo problema: La resistencia al cambio.

Por una parte PMBOK es muy estricta en cuanto a sus necesidades y organización, pero no encontraras empresas en España (o casi) que cumpla religiosamente con lo que dicta la PMO y la guía de PMBOK. Siempre hay problemas en la toma de requerimientos, no siempre se espera a tenerlos cerrados y firmados para empezar el desarrollo. Por otro lado, cuando no se ha cambiado un requerimiento cuando el desarrollo está en marcha…

En Scrum no es necesario tener un funcional en mente, pero eso no significa que no se deba realizar un esfuerzo de síntesis para tener la idea del proyecto clara con todas las implicaciones posibles. Ese acaba siendo un problema, porque no se realiza ese esfuerzo. Y por otro lado, la gente tiene puestos de trabajo que les mantienen demasiado ocupados como para dar el feedback continuo que requiere un desarrollo incremental sin el nivel de especificación de PMBOK.

La aplicación de cualquier metodología ya sea PMBOK o Scrum no requiere un cambio de chip del equipo de desarrollo y responsables, sino que requiere una implantación y cambio de filosofía que aplica a prácticamente toda la empresa, o por lo menos todas aquellas áreas implicadas en proyectos de desarrollo.

Si esto no se lleva a cabo correctamente y la empresa no se toma en serio la organización y apoyo necesario para su funcionamiento, el fracaso (retraso de fechas, producto erróneo, etc.) está más que asegurado.

¿Alguna conclusión?

Al final, cualquier opción es buena si te ayuda a alcanzan los objetivos marcados.

No te dejes llevar por modas, o influencias. Debes seleccionar como afrontarás el proyecto teniendo en cuenta donde trabajas y como se trabaja, los elementos con los que cuentas, el equipo, y la libertad que te dejarán. Acabas adecuando la metodología a la forma de trabajar de tu empresa. No es obligatorio utilizar una u otra de forma estricta (aunque sería lo ideal), puedes utilizar sus detalles según tus necesidades: desarrollo en ciclos cortos, reuniones diarias, requerimientos funcionales, reviews, dar más responsabilidades al equipo, etc.

Aplicar cualquier metodología de proyectos, ya sea utilizando un clásico Waterfall bajo PMBOK, o bajo el marco Agile como Scrum,  y aplicarlo en el desarrollo, puede ser un poco frustrante. Especialmente en España. Lo primero que te puedo aconsejarte es que tengas paciencia, y lo primero que puedo decirte es: Ánimo! :)

Me gusta la filosofía de Scrum, pero en España no es fácil encontrar empresas que realmente se vuelquen en su aplicación, responsables que confíen y tengan la paciencia para llevar a cabo la adaptación, y que además se den las condiciones necesarias. Los casos de éxito son lamentablemente escasos. Ojalá me equivoque y sea cosa mía.

Si consideras que me equivoco en algo, quieres añadir detalles que he omitido, o simplemente quieres compartir tu experiencia, por favor ¡No dudes en hacerlo!

Related Post

Desarrollo Ágil y Scrum Antes de centrarnos en Scrum, comenzaremos centrándonos en el desarrollo y manifiesto Ágil. Citando a Wikipedia: El desarrollo ágil de software...
Retrospectiva Cuando terminamos un ciclo o proyecto, llega el momento de echar una mirada retrospectiva. Es independiente a la metodología de proyectos que s...
The Project Manager The main idea is to start a serie of posts about Project Management, and I'll start talking about the role of the Project Manager. But before, we s...

4 thoughts on “¿Scrum o PMBOK?

  1. Cuando la empresa ya tiene procesos de dirección de proyectos ya definidos y verificados ya sea con CMMI, ISO o MoProSoft (que es el caso de México), es un tanto complicado elegir lo mejor de entre todos los métodos y herramientas.

    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.

  2. Scrum no le llega ni a los talones al PMBOK… ambos no son lo mismo para la gestión de proyectos… scrum se integra pero dudo que reemplace… ademas para aprender scrum solo necesitas 3 días :s

  3. Estimados, pertenezco al grupo de quienes afirman que los proyectos deben planificarse previo a su ejecución. Hay múltiples estándares predictivos (Plan-Do-Check-ACt) y no solo PMI (IPMA, Prince-2, y más actualmente la norma ISO:21.500:2013).

    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

Leave a Reply

Your email address will not be published. Required fields are marked *