.

Equipos scrum multiproyecto

La mayoría de las veces que se presenta scrum, se hace en  un contexto de proyecto único. Sin embargo, es habitual que una organización necesite dedicar sus equipos a más de un proyecto, para satisfacer las necesidades de varios clientes.  ¿Puede en dichos casos emplearse scrum? ¿Cómo se aplicar scrum a esas situaciones multiproyecto?

platespinning

En primer lugar déjame decirte que la respuesta es tan compleja como al pregunta. Y que siguiendo el espíritu de scrum deberías iterar y probar de qué manera se alcanzan mejores resultados en tu caso. Lamentablemente no voy a darte una solución única, porque como siempre la mejor opción dependerá de cada caso en particular. A continuación te presento una serie de aspectos a considerar, que tal vez te ayuden a decidir qué hacer.

¿Que dice La guía scrum?

Antes de entrara en materia me gustaría repasar lo que dice La guía Scrum™ al respecto.

Respecto a la Guía, esta no establece de manera explícita que tenga que trabajarse en un único proyecto; simplemente establece unos roles que deberán llevar a cabo una serie de tareas. No hay nada que indique que el Backlog de Producto y el Backlog del Sprint tengan que ser del mismo proyecto.

Lo cierto es que incluso en el desarrollo de un único producto habrá unidades de trabajo que serán como proyectos independientes. Por ejemplo, en el caso del desarrollo de software: la interfaz de usuario, la capa de negocio, el esquema de la base de datos, etc. Al respecto scrum parece que pueda funcionar ya se trate de un único proyecto o de proyectos múltiples.

Trabajar con varios proyectos en scrum

A la hora de trabajar con varios proyectos  debemos de plantearnos algunas cuestiones:

  • Uno: la finalidad del sprint

Para muchos, entre los que yo me encuentro, uno de los elementos claves de scrum es mantener al equipo enfocado en un solo proyecto durante el sprint. Es de esa manera como lograremos obtener el máximo potencial del equipo y aumentar la productividad. En el caso de contar con especialistas que no puedan contribuir con todo el proceso de desarrollo, por ejemplo redactores de contenido, diseñadores, analistas de negocios, etc. Una vez concluido su parte del trabajo podrían salir del equipo. O mejor aún, podrían aprender otras habilidades para contribuir con el resto del proyecto.

  • Dos: los beneficios/necesidad de ejecutar proyectos en paralelo

Otra cosa a tener en cuenta es que ejecutar varios proyectos en paralelo no es algo que vaya a beneficiar tu calendario de entregas. Me explico con un sencillo ejemplo: imagina que tenemos que entregar 5 proyectos usando el mismo equipo y comenzamos en la misma fecha. Cada proyecto necesita en el mejor de los casos 3 meses de esfuerzo. Esto quiere decir, que si los ejecutamos en paralelo, en el mejor de los casos, necesitaremos 15 meses. Es decir; transcurridos 15 meses podríamos entregar los tres proyectos a la vez.

Sin embargo, si los mismos 5 proyectos los ejecutásemos de manera consecutiva, uno después del otro, también emplearíamos los mismos quinces meses. La diferencia está, en que el primer proyecto podríamos haberlo entregados transcurrido tan solo tres meses, el segundo transcurrido 6 meses, y así sucesivamente hasta concluir el quinto proyecto en el mes quince.

  • Tres: ¿Quién es el responsable de priorizar?

La cuestión está en que si cada proyecto tiene su propio responsable es probable que se produzcan algunas “situaciones” (problemas) en las que cada uno de los responsables, de manera más o menos consciente tratará de favorecer su  proyecto. Por ello, sería conveniente tener un único Dueño del Producto que resolviera las prioridades, o al menos un Dueño del Producto Jefe.

  • Cuatro: ¿hablamos de proyectos o de entregas (releases)?

Algunos profesionales opinan al respecto que en lugar de hablar y de focalizarse en los proyectos, debería hacerse en las releses o entregas.

En los entornos Ágiles el concepto de Proyecto podría ser contraproducente y por lo tanto eliminado. Es decir; de acuerdo con esta línea de pensamiento, la organización debe centrarse en las entregas en lugar de en los proyectos. ¿Por qué? Los Proyectos no dejan de ser unas “cajas artificiales” de trabajo que no producen valor hasta que se terminan. En este sentido son contrarios al enfoque Ágil que tiene como propósito una entrega frecuente de valor. Sin embargo, las releases o las entregas están más en línea con el enfoque Ágil. Las entregas están orientadas hacia la entrega de valor y su alcance se puede reducir o ampliar en base a lo que los equipos podrán ofrecer antes de la próxima entrega.

En definitiva se trata de que los productos desarrollados con Agile, incluso en el caso de múltiples productos construidos por un solo equipo, están acumulando constantemente valor a través de las distintas entregas. Por el contrario, los proyectos no valen nada hasta que terminan (y muchos ni si quiera lo hacen).

¿A ti que te parece?

Como habrás podido comprobar no es una cuestión compleja. ¿Tu que opinas? ¿Has tenido alguna experiencia al respecto? Por mi parte seguiré profundizando en esta cuestión en próximos posts.

Hasta pronto!!!

JLVG

Post relacionados

Implicaciones y significado de la auto-organización en los equipos Ági... Seguramente ya sabes que un equipo Ágil se caracteriza principalmente por dos cosas: 1) trabaja por iteraciones, y 2) ser auto-organizado. Ya he trata...
Gestionar el cambio con scrum La mayor parte de las organizaciones se interesan en scrum por sus potenciales beneficios en el nivel de entrega del producto. De igual modo, la mayor...
7 ventajas de gamificar la gestión de proyectos Las últimas estadísticas muestran que solo uno de cada tres proyectos se cumplen a tiempo y dentro del presupuesto acordado, sobre todo, por la falta ...

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

AUTOR:  Juan Luis Vila Grau

PRINCE2® practitioner, Scrum Master (PSMI), EXIN Agile Scrum Foundation, AgilePM® Foundation, Management_of_Risk (M_o_R®) Foundation. and an enthusiastic of Agile management. Especialistas en técnicas participativas para la gestión de proyectos, y en el Enfoque del Marco Lógico (EML). Faclilitador certificado en el método LEGO® Serious Play®

Utilizamos cookies de terceros para mejorar nuestros servicios. Si continúa navegando, considera que acepta su uso. Más información aquí.  CERRAR