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.

• Acerca de
• Últimas entradas

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.

Últimas entradas de jgarzas (ver todo)

• Las 3 matrices de priorización Ágil - 19 octubre, 2023
• Etapas del Agile Product Management - 12 octubre, 2023
• Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023