¿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!

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 should clarify what is the Project Management, and above all, what is a Project.

The Project Management is the discipline of planning, organizing, securing and coordinating resources and people to meet the objectives, deliverables and success criteria of projects.

And a Project is a unique sequence of complex and interconnected activities that have a goal or purpose to be achieved within a given time, within a budget, and according to specifications.

A Project has a beginning and an end, and each project produces a unique product. (Not to confuse Project with Process).

“A project is a problem scheduled for solution” J.M. Juran

According to the PMBOK Guide, from Project Management Institute (PMI), a Project Manager or Project Leader is the person who has full responsibility for the successful planning and execution of any project.

Assuming that the most of projects (around 90% in Spain) are carried out poorly, we can deduce that the task of a Project Manager is not easy at all. In fact, it can even be frustrating. Some would say that being PM is vocational.

A Project Manager manages a portfolio of projects. It is important to manage the correct number of projects, recommended 4 (depending on the size of projects). Too many may mean not taking the proper monitoring of a project, and its following failure.

Can get a more friendly environment for project management following these practices:

  • Develop a strategy for project portfolio management.
  • Before starting, build or establish solid best practices / protocols.
  • Depending on the duration or scope of a project, you must divide it in manageable stages.
  • It is always good to determine the “Deliverables”.
  • Define an information system at a functional and enterprise level.
  • On large organizations, with needs in coordination, it is important to establish a Project Management Office or PMO.

In general, we could summarize the responsibilities of the Project Manager on the following points:

  • A PM must develop and control the timing to milestones with times and costs.
  • A PM must manage and lead the team under his command.
  • A PM should conduct meetings with internal clients.
  • A PM should develop planning schedules, once you have the project requirements and resources identified and replanning (if necessary).
  • A PM should carry a continuous and efficient communication with the team (the engine of the project) and those associated with the project.
  • A PM must keep track of the project, detect incidents and deviations, arranging follow-up meetings.
  • A PM must perform project status reports.
  • A PM must declare the closure of the project, verify the correct operation and prepare a monitoring plan (or guarantee).
  • A PM must conduct retrospective meetings for learning after the close of the project to carry out changes in procedures or ways of working, identify bottlenecks, etc.

Surely there are more things that could be said about the Project Manager, and specially on the Project Management, or life cycle of a project, etc..

I will add all the information that you think could fit this post. In any case, I hope you’ll find it interesting.