En vez de "un Scrum por proyecto" mejor un "Scrum por equipo"

En línea con aquel post de aléjate del concepto “Proyecto” si quieres usar bien Scrum: confundir “versión a entregar” al cliente con final de sprint, vamos con otro del estilo, ojo con esto, Scrum es una manera de trabajar de la que hace uso el equipo. Scrum marca la manera en la que trabaja un equipo y ese equipo hace proyectos (terminado en plural), productos y cosas.
Esto es súper importante, porque sino lo que pasa es que se hace “un Scrum” condicionado por cada proyecto y eso genera muchas complicaciones. Es la peligrosa orientación a proyectos. Scrum marca la manera de trabajar del equipo. Ponemos el foco en el «equipo» más que en el «proyecto» (fecha inicio – fecha fin).
Vuelvo a hacer uso de la guía de Scrum y cito literal, para evitar mal entendidos:
«Scrum no es un proceso o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varias técnicas y procesos»
La visión “de proyectos” genera unas complicaciones enormes. Por ejemplo, pensar en que tengo 2 proyectos en este mismo momento me lleva a pensar en un equipo por cada proyecto, un Scrum para cada proyecto y ahora encajo ahí a las personas. A Pepe lo meto 4 días en el proyecto A y luego 8 en el B… vamos que te sale un Gantt muy bonito.
Trabajando así Scrum no encaja por ningún lado. La pieza fundamental es el equipo y Scrum es su manera de trabajar que no varía (sólo se mejora retrospectiva tras retrospectiva).
Fijada la manera de trabajar, el equipo es estable, Pepe no sale del equipo para ir a otro equipo a hacer no sé qué del otro proyecto. El equipo es estable, conoce su capacidad de trabajo en cada Sprint, la velocidad (y de ahí, además, que todos los sprints sean de la misma duración), los puntos historia o lo que uses.
Ahora comienza el Sprint y lo que hacemos es planificar qué se va a hacer. Y lo que se va a hacer durante el Sprint pueden ser ítems, historias o tareas de un proyecto o de 50, mientras el equipo tenga capacidad y conocimiento para ello.
Así de simple. Si quieres experiencias, 233 Grados de TI lleva haciendolo así desde hace mucho tiempo, sprints fijos y durante el sprint tareas de muchos proyectos. Y nos va muy bien. No sabemos trabajar de otra manera.

Terminando…

Si tu cliente sólo entiende los proyectos de toda la vida y es imposible que vea otras maneras de trabajar… pues mándale un roadmap de proyecto o lo que quieras, pero no dejes que eso te arrastre y condiciones tu manera interna de trabajar. Tú sigue trabajando, si lo consideras útil, en Scrum.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “En vez de "un Scrum por proyecto" mejor un "Scrum por equipo"”

  1. Lo que no entiendo es como creas el sprint backlog, ¿como se ordena un product backlog entre diferentes proyectos? ¿necesitas un product owner unico para todos los proyectos? ¿como avanzan los dos proyectos a la vez?

  2. Muy buen artículo Don Javier.
    En el supuesto caso de que un equipo de 10 personas tenga 10 proyectos y cada proyecto tenga 50 tareas me asalta la siguiente cuestión:
    ¿cómo lidia el scrum master con un backlog de 500 tareas para planificar el siguiente sprint (semanal o bisemanal)?
    Un saludo cordial

    1. Muchos temas da el comentario…
      Realmente el equipo no ve 10 proyectos, ve un backlog priorizado.
      El que «lidia» es el Product Owner realmente, no el Scrum Master
      En el planning el equipo decide cuántas historias hace…
      Un tema demasiado grande para explicarlo en un comentario…

Dejar un comentario

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