Comparto en este post las ideas surgidas en una conversación en E-TIC 2011 (Sevilla) sobre la pregunta ¿con qué criterios se puede realizar una gestión de cambios en scrum.
QUÉ ES UN CAMBIO?
Digamos que una modificación en el alcance de una o varias piezas de un proyecto.
Entendamos por pieza del proyecto tanto las historias de usuario como las tareas que las conforman. Los cambios pueden afectar a lógica del proyecto, funcionalidad, tecnología empleada, entorno del proyecto, etc…
No debemos considerar cambios a las incidencias, bugs, etc.. que nos aparecen a lo largo de todo proyecto. Aunque a la hora de tratarlos podamos seguir en parte la forma en la que los tratamos.
TIPOS DE CAMBIOS
Me voy a basar en los tipos de cambios que dice ITIL sin tener en cuenta los cambios estándar o pre-autorizados. Nos quedaremos pues, con dos tipos, cambios Normales y de Emergencia.
De forma resumida:
- Los cambios Normales, son aquellos que tienen que ser revisados por el conjunto equipo-Scrum Manager (ScrumMaster)-Product Owner. Pueden llegar en cualquier momento pero no implican acción inmediata.
- Los cambios Emergencia, son aquellos tan inesperados como los Normales pero que nos implican acción en el mismo momento en el que llegan.
Además en ITIL hay un responsable de autorizar los cambios. Es el Gestor del proceso. En nuestro mundo ágil ese responsable será el Product Owner.
IMPACTO DE LOS CAMBIOS
Otro aspecto que tenemos que valorar es el impacto del cambio en nuestro proyecto/Sprint.
- Sin Impacto destacable. El cambio no afecta de forma sustancial al objetivo del proyecto o Sprint
- Impacto sustancial. El cambio afecta de forma sustancial o al proyecto o al Sprint.
……
Bueno tenemos las piezas, arranquemos la gestión de cambios.
CAMBIOS NORMALES
Los cambios Normales, llegan en cualquier momento y se han de ‘encolar’ hasta la próxima reunión de preparación de Sprint donde habrá que tratarlos y ver si se aceptan y entran a formar parte o modifican de alguna forma el Product Backlog.
Recordemos que el propietario del Product Backlog es el Product Owner y el será, como hemos dicho, el responsable de autorizar la modificación, eso sí, asesorado por el Equipo
Creo muy recomendable dejar claro al inicio del proyecto, entre Product Owner y el Equipo la forma en la que se van a tratar los cambios y evitar que esos cambios Normales nos interrumpan el Sprint. Lo digo porque seguro que si has estado en cualquier proyecto te han llegado esos cambios ‘Normales‘ que hacen que des la vuelta al proyecto cada semana 🙂
CAMBIOS DE EMERGENCIA
Ahora los difíciles, los de ‘Emergencia’, alguno pensará que el 90% de los cambios que le llegan son de ‘Emergencia’ 🙂 Si es tu caso, mal vamos :).
Los cambios de Emergencia, como los Normales, llegan en cualquier momento, pero estos implican que tenemos que actuar.
Debe estar prefijado entre Product Owner y Equipo, QUÉ SON cambios de Emergencia o al menos QUÉ NO SON cambios de Emergencia, que permita determinar si algo realmente es susceptible de ser tratado en cuanto llegue o puede esperar a la finalización del Sprint.
Hay dos tipos de Cambios de Emergencia según su impacto, los de bajo/sin impacto y los de Impacto sustancial.
CAMBIOS DE EMERGENCIA SIN IMPACTO SUSTANCIAL
Para los primeros (bajo o nulo impacto) debemos tener un procedimiento preparado para asumir la llegada de ellos sin que nos distorsione mucho el flujo del Sprint:
- Si usas Kanban quizás dejar un camino para estos cambios y preparar el WIP limit de la columna ready para asumir ese extra. Esto te permitirá asumir las tareas derivadas del cambio.
- Otra cosa es calcular la velocidad de tu equipo en función del % de esfuerzo que te vayan a requerir estas acciones extraordinarias. En lugar de 40 Puntos por semana, igual solo puedes tener 30 puntos y sabes que 10 los vas a dedicar a estos cambios… Analiza tu historia en el proyecto o en tu entorno. Esto es semejante a como podemos tratar incidencias, bugs, etc…
Cada conjunto product owner + equipo usará el proceso que mejor encaje.
CAMBIOS DE EMERGENCIA CON IMPACTO SUSTANCIAL
El problema son los cambios Urgentes con Impacto sustancial.Creo que este tipo de cambios deben tratarse y resolverse en la reunión de planificación del Sprint. Así que cuando llega un cambio así hay que:
- Preguntar si el cambio puede esperar ya que no afecta al Sprint.
- Si la respuesta es SI. Terminar el Sprint y en la reunión de planificación del siguiente Sprint tratarlo y construir el siguiente Sprint.
- Si la respuesta es NO (por su alto impacto en el proyecto o porque si que afecta al Sprint). La acción es fácil. Interrumpir el Sprint y volver a la planificación. La decisión de la interrupción del Sprint la ha de tomar el Product Owner. Debidamente informado por el equipo y valorando el impacto que trae dicha interrupción.
Una última cosa. Los cambios mejor al principio de los Sprints 🙂
Y tu? Gestionas los cambios? Cómo?
Es muy interesante esta perspectiva porque sigue permitiendo mantener la agilidad de todo el sistema sin necesidad de tratarlo aparte. Nosotros, hasta ahora, con una metodología que cada vez se ha ido acercando más a Scrum, tratábamos los cambios como proyectos evolutivos independientes, aunque asociados al proyecto principal, y lo aislábamos.
Esta estrategia que planteas parece más acertada porque tiene el beneficio de no duplicar la gestión, los códigos analíticos, etc.
Muchas gracias por tus consejos ;).
Saludos.