Metodología Agiles SCRUM

Objetivo: El objetivo de
esta clase dar las pautas Clase VI Gestión
necesarias para del Cambio
gestionar el cambio en
los proyectos SCRUM.

MA. Juan Carlos Reátegui Morales

jreategui@untels.edu.pe
MBA-ISO 27001-ISO 9001-ISO 22301
Viernes 16.20 – 19.40
Cambia tus pensamientos
y cambiarás tu mundo.
Norman Vincent Peale
 El Cambio en SCRUM
Cada proyecto, independientemente de su método o framework, está
expuesto al cambio.
Es importante que los miembros del equipo del proyecto entiendan que los
procesos de desarrollo de Scrum están diseñados para aceptar el
cambio.
Las organizaciones deben tratar de maximizar los beneficios que se derivan
de los cambios y disminuir los impactos negativos a través de los procesos
de gestión de cambio diligente según los principios de Scrum.
El cambio, es aplicable a:
• Portafolios, programas y/o proyectos en cualquier industria
• Productos, servicios o cualquier entregable para los stakeholders
• Proyectos de cualquier tamaño y complejidad
El término “producto” puede referirse a un producto, servicio, o cualquier
otro entregable.
Scrum puede aplicarse de manera efectiva a cualquier proyecto en
cualquier industria—desde proyectos o equipos pequeños, hasta proyectos
grandes y complejos con cientos de miembros por equipo.
 El Cambio en SCRUM
El cambio es inevitable en todos los proyectos.

En el mundo excesivamente competitivo de hoy en día, donde la tecnología,

las condiciones del mercado y los patrones de negocio están cambiando de
forma continua, el cambio es la única constante.

Un principio fundamental de Scrum es su reconocimiento de que:

a) los stakeholders (clientes, usuarios y patrocinadores) cambian de

opinión acerca de lo que quieren y lo que necesitan durante un proyecto (a
esto se le conoce en ocasiones como: “requisitos volátiles” o requirements
churn); y,

b) que es muy difícil, si no es que imposible, que los stakeholders definan

todos los requisitos al inicio del proyecto.
 El Cambio en SCRUM
Los proyectos Scrum aceptan los cambios mediante el uso de sprints
breves e iterativos que incorporan la retroalimentación del cliente sobre los
entregables del proyecto después de cada sprint. Esto permite que el
cliente interactúe regularmente con los miembros del Equipo Scrum, que
vea los entregables a medida que estén listos y que cambie los requisitos
tempranamente en el ciclo de desarrollo.
Asimismo, los equipos de administración del portafolio o el programa
pueden responder a las solicitudes de cambio relacionadas a proyectos de
Scrum que apliquen en su nivel.
Principio: “Responder al cambio, en vez de seguir un plan”.
La práctica de Scrum se basa en la aceptación del cambio y de convertirlo
en una ventaja competitiva.
Es más importante ser flexible que seguir un plan estricto y
predefinido.
Esto significa que es esencial abordar la gestión de proyectos de una
manera adaptativa que permita el cambio durante el desarrollo del
producto o de los ciclos rápidos de servicio.
 Justificacion del Solicitudes de cambio
aprobadas y no aprobadas
Las solicitudes para hacer cambios se presentan por lo general como
solicitudes de cambio o Change Requests.

Las solicitudes de cambio permanecen como no aprobadas hasta que se

obtiene una aprobación formal.

En ausencia de un proceso formal, se recomienda que los pequeños

cambios que no tienen un impacto significativo en el proyecto se aprueben
directamente por el Product Owner.

La tolerancia de estos pequeños cambios podría definirse a nivel

organizacional o por el patrocinador de un proyecto en particular.

En la mayoría de los proyectos, el 90 % de las solicitudes de cambio

podrían clasificarse como pequeños cambios que deben aprobarse por el
Product Owner.
 Justificacion del Solicitudes de cambio
aprobadas y no aprobadas
El Product Owner juega un papel muy importante en la gestión de los
cambios en un proyecto Scrum.

Los cambios que están más allá del nivel de tolerancia del Product Owner
pueden necesitar de la aprobación de los stakeholders que trabajan con él.

En ocasiones, si un cambio que se ha solicitado puede tener un impacto

sustancial en el proyecto u organización.

En estos casos, la autorización de la alta gerencia (por ejemplo, el

patrocinador ejecutivo, el Portfolio Product Owner, el Program Product
Owner o el Chief Product Owner) puede ser necesaria.
Justificacion del Solicitudes de cambio
aprobadas y no aprobadas
Justificacion del Solicitudes de cambio
aprobadas y no aprobadas
 Equilibrio entre flexibilidad y estabilidad
Scrum ayuda a las organizaciones a ser más flexibles y receptivas al
cambio.
Sin embargo, es importante entender que, aunque el framework de Scrum
hace énfasis en la flexibilidad, también es importante mantener la
estabilidad durante todo el proceso de cambio.

De la misma manera que la rigidez extrema es ineficaz, la flexibilidad

extrema también es improductiva.

La clave es encontrar el equilibrio adecuado entre la flexibilidad y la

estabilidad, ya que la estabilidad se necesita a fin de realizar el trabajo. Por
lo tanto, Scrum utiliza el desarrollo iterativo y sus demás características y
principios para lograr dicho equilibrio.

Scrum mantiene la flexibilidad de que las solicitudes de cambio se pueden

crear y aprobar en cualquier momento durante el proyecto; sin embargo,
estas se priorizan cuando se crea o se actualiza el Backlog Priorizado del
Producto.

Al mismo tiempo, Scrum asegura que la estabilidad permanezca al refinar el

 Equilibrio entre flexibilidad y estabilidad
Al mismo tiempo, Scrum asegura que la estabilidad permanezca al refinar el
Sprint Backlog y al no permitir la interferencia con el Equipo Scrum durante
un sprint.

En Scrum, todos los requisitos relacionados con el sprint en curso se

suspenden durante el sprint.

Ningún cambio se introduce hasta que se termina el sprint, a menos que un

cambio se considere lo suficientemente importante como para detener el
sprint.

En el caso de un cambio urgente, el sprint se termina y el equipo se reúne

para planificar uno nuevo.

Es así como Scrum acepta los cambios sin crear problemas de cambio en
las fechas de lanzamiento o inestabilidad.
 Lograr la flexibilidad
Scrum facilita la flexibilidad a través de la transparencia, la inspección y la
adaptación para lograr los resultados de negocio más valiosos.

Scrum proporciona un mecanismo de adaptación para la gestión de

proyectos en el que un cambio en los requisitos se puede acomodar sin
afectar significativamente el progreso general del proyecto.

Es necesario adaptarse a las realidades de los negocios emergentes como

parte del ciclo de desarrollo.

La flexibilidad en Scrum se logra a través de cinco características claves:

• El desarrollo de productos iterativos.
• La asignación de un time-box.
• Los equipos interfuncionales.
• La priorización basada en el cliente.
• La integración continua.
Lograr la flexibilidad
Lograr la flexibilidad
Lograr la flexibilidad
 Integración del cambio
Dependiendo de la industria y del tipo de proyecto, la prioridad de las
características y los requisitos en un proyecto pueden permanecer fijos
durante periodos considerables de tiempo, o bien, pueden cambiar con
frecuencia.

Si los requisitos del proyecto son generalmente estables, normalmente hay

pequeños cambios realizados en el Backlog Priorizado del Producto en todo
el desarrollo, y los equipos Scrum pueden trabajar secuencialmente en
completar los requisitos que le proporcionan el valor máximo al cliente como
se priorizó en el Backlog Priorizado del Producto.

En entornos estables, la duración del sprint generalmente es más larga, de

4 a 6 semanas.
 Cambios a un sprint
Si hay una solicitud de cambio que puede tener un impacto considerable
sobre un sprint en curso, el Product Owner, después de consultar con
stakeholders relevantes, decide si el cambio puede esperar hasta el
próximo sprint o si representa una situación urgente que pueda requerir
finalizar el sprint actual y comenzar uno nuevo.

El framework de Scrum especifica claramente que el alcance de un sprint

no puede cambiarse una vez que este comience.

Si el cambio requerido es tan importante que los resultados del sprint no

tendrían ningún valor sin él, entonces el sprint debe terminarse.

De lo contrario, entonces el cambio se incorpora más adelante en un sprint

nuevo.
Cambios a un sprint
 Cambio en portafolios y programas
Cualquier cambio que surja, ya sea en los programas o portafolios, puede
tener un efecto en cascada en todos los proyectos dependientes y sprints.

Por lo tanto, se recomienda minimizar los cambios en estos niveles más

altos.

Si se requiere un cambio, y todos los stakeholders están de acuerdo en

hacerlo a estos niveles, se debe tomar en cuenta lo siguiente si son en:

• En portafolios

• En programas
 Cambio en portafolios
1. No se recomienda hacer cambios entre dos reuniones de Portfolio
Backlog.

2. Si el cambio es menor, el Portfolio Product Owner debe contar con la

aprobación de los stakeholders correspondientes (por ejemplo, el
patrocinador, el cliente y el usuario meta) y después añadir los
requisitos al Portfolio Backlog. Los Product Owners y del programa y del
proyecto analizarán los requisitos para su inclusión en futuros sprints.

3. Si el cambio es importante, las actividades del portafolio, junto con los

programas asociados, los proyectos y los sprints tienen que detenerse y
se debe llevar a cabo una reunión del Portfolio Backlog para determinar
cuáles serán los siguientes pasos.

4. Las reuniones del Backlog Priorizado del Producto del Portfolio

(también conocidas como reuniones del Program Backlog), deben
llevarse a cabo en intervalos de 4 a 12 meses.
 Cambio en portafolios
La frecuencia y el impacto de los cambios en un portafolio determinan
en gran medida la duración de tiempo entre dos reuniones del
Portfolio Backlog.

Si son varios los cambios esperados en el portafolio, es preferible llevar a

cabo este tipo de reuniones en intervalos más frecuentes (por ejemplo, de
cuatro a seis meses); pero si hay menos cambios esperados, y si los
requisitos son estables, la duración entre dos reuniones podría aumentarse
(por ejemplo, de 9 a 12 meses).
 En programas
1. No se recomienda hacer cambios entre dos reuniones del Program
Backlog.

2. Si el cambio es menor, el Program Product Owner debe contar con

la aprobación de los stakeholders correspondientes (por ejemplo, el
patrocinador, el cliente y el usuario meta) y después añadir los
requisitos al Program Backlog. Los Product Owners y del programa y
del proyecto analizarán los requisitos para su inclusión en futuros
sprints.

3. Si el cambio es importante, las actividades del programa, así como

los proyectos y sprints relacionados deben detenerse y se debe llevar a
cabo una reunión del Product Backlog para determinar cuáles serán los
siguientes pasos.
 En programas
4. Las reuniones del Backlog Priorizado del Producto del programa (también
conocidas como reuniones del Program Backlog), deben llevarse a cabo,
de preferencia, en intervalos de dos a seis meses.

La frecuencia y el impacto de los cambios en un programa determinan

en gran medida la duración de tiempo entre dos reuniones del Program
Backlog.

Si hay varios cambios previstos en el programa, es preferible llevar a

cabo este tipo de reuniones en intervalos más regulares (por ejemplo,
de dos a tres meses); pero si hay menos cambios esperados y si los
requisitos son estables, la duración entre dos reuniones podría
aumentarse (por ejemplo, de cinco a seis meses).
En programas y portafolios
Responsabilidad de los cambios
 Control de Aprendizaje
Preguntas de Control:

¿Cómo se manejan los cambios en los proyectos SCRUM?. Explique.

¿Cómo son los cambios en un Sprint? ?. Explique.

¿Qué importancia significa que se tenga un eficiente manejo de los cambios

en un proyecto?. Explique.

¿Qué podría pasar si no se aceptan cambios en los proyectos, una vez

iniciados?.
 Metodología Agiles SCRUM
Clase VII Riesgos en SCRUM
Objetivo: El objetivo de
esta clase es definir los
riesgos, analizar la
gestión de riesgos en un
entorno de Scrum y
considerar las
herramientas que
facilitan la gestión de los
riesgos. MA. Juan Carlos Reátegui Morales
jreategui@untels.edu.pe
MBA-ISO 27001-ISO 9001-ISO 22301

Viernes 16.20 – 19.40

“En un mundo que cambia realmente rápido,
la única estrategia en la que el fracaso está
garantizado es no asumir riesgos”.
Mark Zuckerberg
Muchas gracias…