Scrum Level 3D: guía para evaluar y mejorar la agilidad de la empresa

Guía para evaluar y mejorar la agilidad de la empresa en las tres dimensiones a las que afecta: operativa, estructural y cultural.

Scrum Level analiza los principios y valores de la agilidad de forma coherente con la realidad de la organización, con sus circunstancias culturales y las características de los productos o servicios que realiza.

Scrum Level 3D

La gestión de proyectos ágil recorta el tiempo para la entrega de valor y mejora la satisfacción de los clientes, así como la implicación de los miembros del equipo, la productividad, calidad y aprendizaje (VersionOne – 2017 – 11 State of Agile Report).

Estos resultados atraen la atención de las empresas hacia la agilidad, deseosas de trasladar los mismos beneficios a toda su organización.

Continuar leyendo «Scrum Level 3D: guía para evaluar y mejorar la agilidad de la empresa»

Scrum Manager y Proyecto Universidad Empresa acercan la gestión ágil al mundo académico.

AulaEl conocimiento profesional de Scrum y de gestión ágil de proyectos es cada vez más demandado por las empresas del conocimiento, especialmente en el sector TIC.

Con la misión de proporcionar las mejores competencias a los jóvenes que preparan su carrera profesional, con un conocimiento tecnológico acorde a las necesidades del sector, Proyecto Universidad Empresa lleva al ámbito académico la formación y certificación profesional Scrum Manager.

La presentación tendrá lugar el próximo 7 de mayo en Madrid en el marco del PUE’s Tech Learning Day, en el que se dará a conocer a los centros de formación las últimas novedades y proyectos educativos en formación y certificación oficial.

 

 

 

Gestión de cambios en Scrum

El otro día me preguntaron en el evento E-TIC de Sevilla vía twitter (@emartos) por cómo podemos realizar una gestión de cambios desde Scrum. He creido que igual podíamos compartir la forma en que vemos la gestión de cambios desde la agilidad. Tomamos como partida mi contestación a @emartos 🙂

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?