metodologÍa scrum para una gestiÓn Ágil … · jose antonio calvo maguregi acorde consulting...
TRANSCRIPT
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
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
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
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”
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?
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.
EL EQUIPO SCRUM: ¿QUIÉN LO COMPONE?
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
EL EQUIPO SCRUM: ¿QUIÉN LO COMPONE?
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
Máximo 3 horas para un
sprint de 1 mes
Máximo 1 mes
Máximo 8 horas para un
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
EL SPRINT: EJECUCIÓN DEL SPRINT. TRABAJANDO DE MANERA VISIBLE
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
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)
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