METODOLOGÍA SCRUM PARA UNA GESTIÓN ÁGIL … · JOSE ANTONIO CALVO MAGUREGI Acorde Consulting...

JOSE ANTONIO CALVO MAGUREGIAcorde [email protected]

METODOLOGÍA SCRUM PARA UNA GESTIÓN ÁGIL Y EFICAZ EN

TODO TIPO DE ORGANIZACIONES

Logroño, 15 de junio de 2016

Planificación vs Agilidad

SCRUM: piezas clave

SCRUM: pasos para la implementación

Aplicación de SCRUM en entornos empresariales

SCRUM: principios básicos

Planificación vs Agilidad

AGILIDAD EMPRESARIAL

Agilidad:

Capacidad de la organización para adaptarse rápida y eficientemente a Ios

cambios.

Agilidad de la organización:

Capacidad para responder y adaptarse oportunamente a cualquier amenaza u

oportunidad que surja.

EFQM (glosario 2013)

“No es el grande quien se come al chico…..

Es el rápido el que se come al lento”

EFICACIA + EFICIENCIA

eficacia.(Del lat. efficacĭa).

1. f. Capacidad de lograr el efecto que se desea o se espera.

eficiencia.(Del lat. efficientĭa).

1. f. Capacidad de disponer de alguien o de algo para conseguir un efecto determinado.

Real Academia Española ©

La Organización EFICAZ: Consigue sus objetivos dando respuesta a sus grupos de

interés.

La Organización EFICIENTE: Lo hace de forma rentable y sostenible.

EFICACIA + EFICIENCIA

La Organización EXCELENTE conjuga la Eficacia y la Eficiencia

¿EXCELENCIA VS AGILIDAD?

CONCEPTOS FUNDAMENTALES DE LA EXCELENCIA (EFQM 2013)

Aspectos críticos de la planificación

Tanto en la planificación estratégica como en la planificación de un proyecto….

o La clave está en el proceso y la herramienta, no en el plan en sí

o Surgirán necesidades no previstas…

o En ocasiones el cliente no sabe qué quiere exactamente al inicio del proyecto

o Pueden modificarse los plazos de ejecución, el alcance del proyecto

o Se debe buscar el logro del objetivo redefiniendo la ruta a cada paso

o “Observar, orientarse, decidir y actuar”

El error de la multitarea

Se tarda la mitad de tiempo completando las tareas una por una, en lugar de pasar de un contexto a otro.

Puede llevar horas de trabajo volver al mismo estado de concentración.

Experiencia Toyota: “cuando un fallo se corregía el mismo día que había sido originado, se tardaba una hora en

arreglarlo; tres semanas más tarde se tardaban 24 horas. Daba igual que el error fuera grande o pequeño,

complicado o sencillo, siempre se tardaba 24 veces más si se corregía tres semanas después”

Puede requerir más esfuerzo corregir que

crear.

“A medio hacer no significa hecho. Hacer algoa medias es, esencialmente, no hacer nada”

De la cascada a la fluidez

Asumiendo los principios anteriores…..

.... Contando con una planificación dinámica, buscando el máximo rendimiento por tarea a través de la fluidez de los procesos y contando con equipos multifuncionales y orientados a resultado…..

La clave es sustituir “el despliegue secuencial” o en “cascada”(ir cubriendo fases cada vez que una está terminada, entregando valor al final)

Por: La entrega de valor incremental

De la cascada a la fluidezCASCADA VS. SCRUM

Visión

Análisis de

requisitos

Diseño

Pruebas

Desarrollo

Producción

Entregable

CASCADA

SCRUMSPRINT 1 SPRINT 2 SPRINT N

EntregableEntregable Entregable

Planificación detallada

y seguimiento a ciegas

Inspección y

adaptación

SCRUM: Principios básicos

o El mapa no es el territorio

o Planificar es útil… seguir los planes a ciegas es absurdo

o Observar, orientarse, decidir y actuar

o Equipos: trascendentes (orientados al objetivo), autónomos, multidisciplinares

o Hacer las cosas de una en una

o Mejor crear que corregir

o Planificar en tiempos cortos, priorizar y replanificar

o Valor incremental a partir del “producto terminado”

SCRUM: Piezas clave

�El equipo

�El Product Backlog

�El Sprint

EL EQUIPO SCRUM: VALORES

El desarrollo de un proyecto Scrum debe guiarse por los siguientes valores que deben estar presentes

en las personas que forman el equipo Scrum:

� FOCO: el equipo se enfoca en sólo unas pocas cosas a la vez, de este modo se consiguen

entregas de producto mucho antes.

� TRANSPARENCIA: durante el trabajo conjunto se expresa todos los días cómo nos ha ido y qué

previsiones de trabajo tenemos.

� CORAJE: no se ocultan los problemas sino que se manifiestan abiertamente. Cuanto antes se

resuelvan antes se avanzará hacia el objetivo.

� COMPROMISO: nos comprometemos con un objetivo compartido que va más allá de los

intereses individuales.

¿LOS VALORES SURGEN DE CADA INDIVIDUO O HAY SISTEMAS QUE LOS POTENCIAN?

“No busque personas que lo hacen mal; busque sistemas malos, aquellos que incentivan

la mala conducta y premian el bajo rendimiento”

� Equipo de desarrollo

� Responsable de Producto o ProductOwner

� Scrum Master

Se comprometen con los

objetivos a lograr

Aportan feedback e

información sobre los

requisitos del producto finalUsuarios y otro tipo de

stakeholders

EL EQUIPO SCRUM: ¿QUIÉN LO COMPONE?


1. EQUIPO DE DESARROLLO: personas que ejecutan el proyecto

• Autónomo: se autogestionan y tienen la libertad de tomar decisiones que

afectan a su trabajo

• Multidisciplinar: cada equipo cuenta con todas las personas para desarrollar

todo el proyecto de principio a fin

• Trascendente: tienen un propósito que está por encima del individuo

Es preferible crear equipos pequeños (de entre 5 y 9 personas), ya que al aumentar de

tamaño la velocidad de trabajo se reduce.


2. RESPONSABLE DE PRODUCTO: es el responsable de maximizar el valor del producto

final.

• Mantiene la lista de requisitos del producto junto con el equipo de desarrollo y

la prioriza según el valor que aporte al cliente

• Está presente en las reuniones de planificación y revisión del sprint

• Es el representante del cliente dentro del proyecto y, como tal, estará

disponible siempre para aclarar las dudas del equipo


3. SCRUM MASTER: es la persona que ayuda al equipo a que su desempeño sea el

mejor posible. ¿Cómo?

• Elimina los impedimentos que puedan frenar el trabajo del equipo

• Ayuda al equipo y a la organización a hacer el mejor uso de SCRUM

Se trata de un facilitador, no distribuye tareas ni hace un seguimiento del trabajo.

Lo recomendable es que no coincida con el Product Owner, pero según los recursos y

estructura de la organización puede ser la misma persona que desempeña ambos roles.

EL PRODUCT BACKLOG

Es una lista de requisitos (“historias de usuario” en Scrum) que incorporará el producto final

ordenados por orden de prioridad:

• Es el Product Owner (Responsable de Producto) el responsable de generar esta lista inicial, de

mantenerla actualizada y de priorizar los ítems.

• Los ítems del Product Backlog están estimados por el equipo.

¿Qué campos puede incluir el Product Backlog?

• ID: identificador del requisitos o historia

• Nombre: título identificativo

• Definición: descripción del requisito o historia. Puede utilizarse el esquema: COMO (tipo de

usuario), QUIERO (qué necesito), PARA (beneficio)

• Prioridad: un número que sirva para identificar su importancia respecto al resto de historias

• Estimación: cuánto trabajo es necesario para terminar la historia

EL PRODUCT BACKLOG: PRIORIZACIÓN

PRIORIZACIÓN: “El 80% del valor de cualquier producto de software no reside más

que en el 20% de sus características, hacer que el equipo priorice en función del

valor les obliga a producir ese 20% primero”

EL PRODUCT BACKLOG: ESTIMACIÓN

Los ítems del Product Backlog se ESTIMAN para tener una aproximación al grado de

esfuerzo que van a requerir por parte del equipo.

� Es necesaria una estimación antes de comenzar con su ejecución

� Es responsabilidad conjunta de todo el equipo

� La metodología SCRUM recomienda realizar estimaciones calculando el

valor relativo de cada ítem mediante la secuencia de Fibonacci

Una vez aclarado el

significado de cada historia

(requisito), cada miembro

del equipo selecciona la

carta que más se aproxima

a su estimación y la coloca

hacia abajo. Cuando todos

han terminado, se giran las

cartas

EL SPRINT

Periodos de trabajo cortos para los cuales se planifican tareas concretas que se

deben cerrar con “entregables” parciales del producto (incremento de producto

terminado).

• También se denomina “caja de tiempo” o “Timebox”

• Fijar un tiempo máximo para conseguir un objetivo ayuda a priorizar y

fuerza la toma de decisiones

• Una vez que el equipo se compromete con lo que tiene que conseguir,

queda cerrado el cupo de tareas para ese periodo.

EL SPRINT: EL CICLO DE UN SPRINT

Reunión de

planificación

del Sprint

Ejecución del

SPRINT

Revisión del

SPRINT

Retrospectiva

Reunión diaria (15 min)Trabajo visible

Refinado del Product Backlog

Máximo 4 horas para un

sprint de 1 mes


sprint de 1 mes

Máximo 1 mes


sprint de 1 mes

EL SPRINT: PLANIFICACIÓN DEL SPRINT

El equipo, Scrum Master y Product Owner se reúnen para decidir qué parte del Product Backlog se

aborda en el periodo siguiente.

� El Product Owner explica las primeras historias/elementos o ítems del Backlog y responde

a las dudas del equipo

� El equipo estima los elementos

� El Product Owner reprioriza o no las historias en base a la estimación

� Se seleccionan las historias que van a incluirse en el sprint y el equipo se compromete a

tenerlo listo para el día de la revisión del sprint

Resultados de la planificación del sprint:

�Un entendimiento compartido del trabajo que se va a realizar en el sprint

� Un compromiso grupal para entregar cierta cantidad de valor, expresada como elemento

del backlog

� Fecha y lugar para celebrar la reunión de revisión del sprint

La Pizarrra Scrum: principal herramienta para la autogestión del equipo de desarrollo que

apoya la transparencia y gestión visual.

EL SPRINT: EJECUCIÓN DEL SPRINT. TRABAJANDO DE MANERA VISIBLE

Formatos posibles:

� Software especializado (version one,

pivotal tracker, etc.)

� Aplicaciones gratuitas (Trello)

� Hoja Excel

� Panel físico


PANEL FÍSICO


HOJA EXCEL


APLICACIÓN TRELLO


EL GRÁFICO BURN-DOWN

Se actualiza diariamente (durante la reunión diaria) según el trabajo realmente

realizado

Si la línea de trabajo

realizado está por

encima del ideal,

indica que el equipo

va retrasado

Días del sprint

Puntos historia o tiempo necesario

La reunión diaria sirve para que todo el equipo sepa claramente en qué situación se

encuentra cada tarea y cuál es la situación global del sprint, y si existe algún obstáculo

que reduce la velocidad. Cada miembro del equipo responde a las siguientes preguntas:

�¿Qué hiciste ayer para ayudar al equipo a terminar el sprint?

�¿Qué vas a hacer mañana para ayudar al equipo a terminar el sprint?

�¿Qué obstáculos se interponen en el camino del equipo?

Cualquier otra discusión que pueda surgir, se saca de la reunión diaria y se comenta en

una reunión aparte.

No es una rendición de cuentas, es intercambiar información y opiniones sobre cómo avanzar para completar el sprint.

EL SPRINT: EJECUCIÓN DEL SPRINT. LA REUNIÓN DIARIA

� Reunión de pie de 15 minutos

de duración.

� Todos los días a la misma hora

y todo el mundo presente

� Participación activa. No

rendición de cuentas

EL SPRINT: EJECUCIÓN DEL SPRINT. LA REUNIÓN DIARIA

CARACTERÍSTICAS

EL SPRINT: REVISIÓN DEL SPRINT

El equipo y el Product Owner/Product Backlog revisan si se han cumplido los objetivos del

sprint, si se han desarrollado todos los elementos del backlog seleccionados para el sprint.

� En el caso de que el proyecto consista en el desarrollo de un producto la revisión del

sprint suele ser la DEMO a través de la cual se comprueban de primera mano las

funcionalidades

� Puede estar el usuario u otros stakeholders

Después de la revisión del sprint puede haber un refinado del Product Backlog derivado del

feedback del cliente o de la experiencia adquirida por el equipo:

� Modificación de prioridades

� Inclusión de nuevos ítems

� Desagregación de ítems

� Eliminación de ítems

EL SPRINT: RETROSPECTIVA

El equipo y el Scrum Master analizan críticamente cómo ha ido el desarrollo del

sprint. Se responde a las siguientes preguntas:

� ¿Qué salió bien en el sprint? (aciertos)

� ¿Qué no salió bien en el sprint? (errores)

� ¿Qué mejoras vamos a implementar en la próxima iteración?

(recomendaciones de mejora continua)

No es el momento de buscar culpables o adoptar actitudes defensivas, sino de analizar el proceso, averiguar por qué ha

ocurrido lo que ha ocurrido y cómo se puede mejorar

EL SPRINT: INSPECCIÓN Y ADAPTACIÓN

La revisión del sprint y la retrospectiva representan la aplicación práctica del concepto de inspección y adaptación

Cada poco tiempo, dejamos de hacer lo que estamos haciendo,

revisamos lo que hemos hecho y vemos si sigue siendo lo que

deberíamos estar haciendo y cómo podríamos mejorar

Incorporando las mejoras identificadas

se planifica el siguiente sprint y se inicia

un nuevo ciclo

SCRUM: Pasos para la implementación

1. Elegir responsable de producto, equipo y Scrum Master

2. Elaborar el Product Backlog. Lista ordenada de ideas para el producto en el orden en

que esperamos llevarlas a cabo.

� La elabora el equipo junto al Responsable de producto

� La priorización la lleva a cabo el Responsable de producto

� Evoluciona a lo largo del proyecto

3. Estimar el tiempo de ejecución de las ideas para el producto incluidas en el Product

Backlog

4. Planificar los sprints: seleccionar las ideas para el producto que se estime pueden ser

desarrolladas en ese periodo de tiempo y acordar cómo se realizará el trabajo

5. Ejecutar el sprint trabajando de forma visible. Reunión diaria. La gestión visual del

trabajo se apoya en la pizarra scrum

6. Revisar el sprint: evaluar si se ha logrado el incremento de producto planificado y

tomar decisiones sobre la actualización del Product Backlog

7. Refinar el Product Backlog: desagregar / añadir / eliminar elementos del backlog y

realizar estimaciones.

8. Retrospectiva del sprint: revisar y mejorar el proceso, las relación entre las personas y

las herramientas utilizadas. Se realiza con el apoyo del Scrum Master

9. Siguiente ciclo de sprints: todos los elementos del ciclo scrum se repiten en cada

sprint (planificación, ejecución, revisión, refinamiento del backlog y retrospectiva)

Aplicación de Scrum en entornos empresariales

La lógica Scrum y el proceso de planificación estratégica

� Definición de objetivos finales y concreción en ciclos cortos.

� Revisión y redefinición continua.

� Proactividad causa - efecto

Gestión ágil de procesos con lógica Scrum

� Transversalidad, fluidez y orientación a la entrega de valor al cliente.

� Equipos multidisciplinares con objetivo común.

� Seguimiento y decisiones compartidas.

Cuestiones previas a considerar

En el día a día de nuestras empresas:

o Los equipos no son fijos. Por ejemplo: equipos de proceso, de mejora...

o Cada equipo o cada miembro de un equipo no se centra en un único proyecto.

o Las reuniones diarias no son siempre posibles ni convenientes (por distancia,

disponibilidad, coste…).

o Los proyectos pueden ser algo accesorio; no centrado en el día a día…

o No siempre va a ser posible la generación de producto completo y funcionando

como resultado final de cada fase. En ocasiones serán entregas parciales que

irán dirigidas a otras áreas de la organización.

o El cliente no siempre es flexible con el alcance del proyecto, se funciona con

presupuesto cerrado y no siempre se puede renegociar.

Ámbitos de aplicación de Scrum en entornos empresariales

o Proyectos pedido –entrega “a medida”

o Gestión y priorización de proyectos estratégicos y operativos

o Equipos gestores de proceso

o Proyectos de mejora y resolución de problemas

o Proyectos de autoevaluación y avance en EFQM o Gestión Avanzada

1.- Equipo de Proceso Scrum

Las claves:

� El plan de acción asociado a los objetivos es el “backlog” y su priorización se realiza

en base al valor que aporta al proceso, definido a través de los objetivos de su cuadro

de mando

� Los equipos gestores de proceso se centran en el seguimiento de objetivos y cierre y

apertura de “sprints”

� Reuniones más frecuentes y cortas para el seguimiento del plan de acción y

condicionadas a la existencia de proyectos que justifiquen “sprints”

1.- Equipo de Proceso Scrum

Las herramientas:

� Cuadro de Mando de Proceso Scrum (incluye: cuadro de mando de proceso +

proyectos o acciones asociadas a objetivos de control + priorización de acciones +

pizarra scrum)

� Doble nivel de reuniones y revisiones:

o Estado básico: mensual

o Con proyectos scrum: semanal (presencial u online)

2. Gestión ágil de proyectos internos

Las claves:

� No existe cliente externo, pero igualmente los requisitos del proyecto pueden cambiar en

función a necesidades internas, por lo que el “backlog” del proyecto se irá refinando.

• Proyecto estratégico: implica a varias áreas y se destina un volumen de recursos

importante

• Proyecto de proceso: no son acciones asociadas a un objetivo de control de proceso y a

la gestión “habitual” del proceso, sino que introducen un cambio que supone una

mejora sustancial

� Equipos ad-hoc, coyunturales y con dedicación limitada

2. Gestión ágil de proyectos internos

Las herramientas:

Herramientas Scrum adaptadas

� Backlog y Pizarra Scrum por cada proyecto

� Reuniones dinámicas (no presenciales, no simultaneas, no diarias)

� Reuniones de validación de avances (cliente interno = Dirección)

3. Gestión ágil de proyectos pedido – entrega a medida

Las claves:

� En muchos casos, los equipos de proyecto no son estables ni están centrados en un

único proyecto, no pueden mantener reuniones diarias, están dispersos en diferentes

lugares, etc.

� Definición de herramientas específicas diferentes para cada proceso (gestión de

proyectos en cada proceso Pedido - Entrega)

� Las entregas no se realizan siempre al cliente final, sino a otras áreas internas o a

colaboradores externos

3. Gestión ágil de proyectos pedido – entrega a medida

Las herramientas:

En muchos casos, se pueden aplicar las herramientas 100% Scrum, si bien en algunos

casos, conviene definir:

� Plantilla para Backlog multiproyecto

� Definición y seguimiento de sprints multiproyecto y no presenciales o virtuales

CLAVES HERRAMIENTAS SCRUM

Equipo de Proceso Scrum Plan de acción = Backlog

Reuniones de seguimiento

más frecuentes y cortas

Cuadro de Mando de Proceso

Scrum

Reuniones Scrum

Gestión ágil de proyectos internos

No existe cliente externo

Equipos ad-hoc

Backlog y Pizarra Scrum

Reuniones Scrum

Gestión ágil de proyectos pedido – entrega a medida

Equipos de proyecto no

estables

Las entregas no se realizan

siempre al cliente final

Equipos multiproyecto

Backlog (multiproyecto)

Sprints (multiproyecto)

Reuniones Scrum

Ámbitos de aplicación de Scrum en entornos empresariales (Resumen)

Otras herramientas vinculadas con Scrum y la gestión ágil y excelente

Análisis “RADAR”

Kanban, Trello, …

Cuadros de Mando …

“Scrum transformations work best by starting small

and slowly scaling out. All at once Scrum is a lot

harder”(@jeffsutehrland) 12.05.2015

www.acordeconsulting.com

METODOLOGÍA SCRUM PARA UNA GESTIÓN ÁGIL … · JOSE ANTONIO CALVO MAGUREGI Acorde Consulting...

Documents

Transcript of METODOLOGÍA SCRUM PARA UNA GESTIÓN ÁGIL … · JOSE ANTONIO CALVO MAGUREGI Acorde Consulting...