PROGRAMA DE CERTIFICACIÓN EXIN AGILE SCRUM MASTER

Based on EXIN Agile Scrum Master Issue: June 2017

Agille Scrum FoundationTraining Material Issue: July 2016
© EXIN 2017 All rights reserved
EQUIPOS DISTRIBUIDOS
Diferencias Culturales Significativas
 Pasos para crear Cohesión en el equipo

1.- Entender las diferencias culturales significativas

3.- Reforzar la cultura del equipo
• Distribución de poder
• • Establecer una visión compartida
Individualismo
• • Establecer acuerdos de trabajo
Orientación al logro
• Incertidumbre
• Visión a Largo Plazo Vs Corto Plazo 4.- Construir confianza a través del progreso logrado

• Al dirigir las actividades de integración del equipo, los primeros

2.- Entender las diferencias culturales pequeñas esfuerzos deben enfocarse en temas superficiales
• Diferir las actividades de integración hasta que el equipo haya
• Feriados aprendido mas sobre ellos mismos
• Horarios de Trabajo
ARTEFACTOS & ROLES
3.5.1 Como manejar issues, bugs, y como informar a personas fuera del
equipo
Seguimiento de errores en una pizarra de tareas:

Muchos equipos, cuando comienzan la transición a un proceso de desarrollo Ágil, se

enfrentan a un gran número de errores heredados. No sólo hay un gran lista de errores que
deben ser arreglados "algún día", también los errores siguen llegando a a un ritmo rápido. Un
desafío común para los equipos que se mueven a un proceso ágil es cómo tratar con estos
Bugs. La pizarra de tareas proporciona un mecanismo conveniente para comenzar a corregir
este problema.
Supongamos que el propietario del producto incluye "Corregir diez" errores "altos" en la
nueva iteración. El propietario del producto selecciona los diez errores y los desarrolladores
escriben una tarjeta de tarea (con una estimación) para cada uno. Las tarjetas se graban en la
columna “To do” de una fila en la pizarra de tareas. A medida que avanza la iteración, los
desarrolladores trabajan en los diez bugs de la misma manera en que trabajan en otras tarjetas
de tareas. Supongamos ahora que un usuario encuentra un nuevo error a mitad de camino en
la iteración. Si el nuevo error se considera una prioridad más alta que uno o más errores
restantes en la columna Tareas, el propietario del producto puede intercambiar una cantidad
equivalente de trabajo de corrección de errores en favor de corregir el nuevo error.
 2.1.3 Como el Scrum master puede facilitar al equipo

Responsabilidad
• Un buen Scrum master debe asumir la responsabilidad
• Responsable de Maximizar los resultados del equipo

Humildad
• Debe sentir orgullo por los logros, no por su propio
ego
• Sentido de equipo “Mira lo que he ayudado a lograr”
en ves de “Mira lo que he hecho”
• Hace lo que sea necesario por el bienestar del equipo
• Reconoce el valor de cada uno en el equipo
 2.1.3 Como el Scrum master puede facilitar al equipo

Colaborativo
• Asegurar que exista una cultura de colaboración en el equipo
• Asegurar que los miembros del equipo se sientan cómodos al
discutir los problemas que enfrenta el equipo
• Cuando existen discrepancias, alentar al equipo a pensar de forma
que todos ganen
Comprometido
• Debe estar comprometido con el Rol y con el proyecto tanto
como los demás en el equipo
• No debe dejar problemas pendientes de solución por muchos días
• Una forma de demostrar compromiso es permanecer el rol hasta
el término del proyecto
 2.1.3 Como el Scrum master puede facilitar al equipo

Influyente
• Un Scrum master exitoso influencia tanto al equipo como al resto de la
organización
• Los miembros del equipo pueden necesitar ser persuadidos para darle una
oportunidad a Scrum e incluso para trabajar en forma colaborativa
• Debe convencer al equipo para utilizar nuevas técnicas de programación

Conocedor
• Debe tener solidos conocimientos técnicos, del mercado, o otros
conocimientos especializados
• No debe ser experto, pero debe tener conocimientos suficientes para ser
un líder efectivo del equipo
2.2 Coaching the Team and Mediating
 2.2.1 Explicar como y cuando mediar en conflictos

Fortalecer Subculturas Funcionales y de Equipo

Comunicar y Establecer una Visión Compartida
• Sin una visión compartida, será casi imposible desarrollar una sólida cultura de equipo desarrollar.
• Esto hace que una visión compartida sea especialmente importante para un equipo distribuido.

Establecer Acuerdos
• Parte de la cultura de un equipo deriva de los acuerdos que los miembros del equipo hacen entre sí.
• Algunos acuerdos son explícitos: llegar a tiempo para el Scrum diario y hacer check-in de software con
error son ejemplos.

Construir confianza al enfatizar el progreso temprano

• Crítico para la creación de un equipo coherente es la creación de confianza entre los miembros del equipo.
• Esto es mucho más difícil en un equipo distribuido.
 2.2.3 Importancia del Entrenamiento

• En un equipo que es nuevo en Scrum, el trabajo del Scrum

Master puede consumir mucho tiempo. El Scrum Master
estará ocupado entrenando a los miembros del equipo en
Scrum, y alentándolos a pensar de diferentes maneras sobre
los problemas que encuentran, eliminando impedimentos para
el progreso del equipo, etc.
• Al principio, esto podría ser un trabajo a tiempo completo,
dependiendo que tan nuevo es el equipo y los tipos de
impedimentos que enfrentan los miembros del equipo. Con el
tiempo, sin embargo, las cosas mejoran.
• Eventualmente el Scrum Master ha eliminado muchos
impedimentos recurrentes, y el propio equipo ha comenzado a
dominar Scrum y ha abrazado su naturaleza auto-
organizadora. A medida que estos cambios ocurren, el equipo
necesita cada vez menos tiempo del Scrum Master.
Adopción de Scrum Prácticas Ágiles

• Split and Seed

• Grow and Seed

 2.2.2 Explain how to coach and challenge the team

Los Coaches tienen responsabilidades específicas, como asistir a la planificación de sprints, reuniones
de revisión y retrospectiva del sprint; asistir a un Daily Scrum cada semana; y estar disponible durante
dos horas cada semana para proporcionar asistencia al equipo según sea necesario.

• Coaches para nuevos equipos: Un enfoque como split and seed (dividir y sembrar) toma un
enfoque de todo el equipo para el coaching: El nuevo equipo es entrenado colectivamente por los
miembros del equipo de siembra. Algunas de esas personas serán buenas en ese rol; algunos no lo
serán. Con el coaching interno, se selecciona al entrenador mas apropiado para cada nuevo equipo.

• Los entrenadores se pueden mover de un equipo a otro: Después de un tiempo un equipo y su

entrenador pueden volverse obsoleto. Un nuevo par de ojos puede ser útil para identificar nuevas
formas de mejorar. Cuando los entrenadores internos se mueven de un equipo a otro actúan como
abejas, polinizando a cada equipo con nuevas ideas.
 2.2.2 Explain how to coach and challenge the team

Coaching interno: razones para preferir el coaching interno

El enfoque de coaching interno es generalmente el enfoque preferido. No es de sorprender que haya un gran conjunto
de ventajas, incluidas las siguientes:

• Los equipos que funcionan bien no necesitan dividirse. Un inconveniente de los patrones anteriores es que los
equipos en funcionamiento se dividen para formar los cimientos de los nuevos equipos. Cuando se utiliza entrenadores
internos, los equipos se mantienen intactos con solo la interrupción menor de un extraño ocasional (el entrenador) que
se une al equipo.

Proporcionar entrenamiento. Más allá de capacitar a las personas, el coaching individual y en grupos pequeños es
increíblemente útil. En una clase de entrenamiento, el instructor dice: "Así es como se hace una reunión de
planificación de sprints", por ejemplo, y tal vez ejecuta la clase a través de un ejercicio para practicarla. Con el
coaching, alguien con experiencia se sienta con el equipo y los ayuda a en su propia reunión de planificación de sprint
real (o cualquier otra habilidad que se esté entrenando). Desde el principio, los miembros de la PMO pueden no tener
estas habilidades por sí mismos, pero deben centrarse en adquirirlos de entrenadores externos y luego hacer el
entrenamiento práctico ellos mismos.
Waterfall Tandem
Caves and Commons
Product Owner & Scrum Master
Product Owner & Scrum Master

Example of Multipliers for Velocity

 Release Plan

Example of a Release Plan

 3.4.3 Explicar como utilizar e interpretar los
métodos de seguimiento más comunes (Burn-
Down Chart, Velocidad, etc)

Example of Multipliers for Velocity

CRUD (CREATE – READ – UPDATE –DELETE)
 1.1.2 ADAPT - Transición a Ágil
Awareness: Conciencia de que el proceso actual no esta
entregando resultados aceptables

Desire: Deseo de adoptar Scrum como una forma de

enfrentar problemas actuales

Ability: Habilidad para tener éxito con Scrum

Promotion: Promoción de Scrum compartiendo

experiencias, de modo tal que nosotros recordemos y otros
puedan ver nuestro éxito

Transfer: Transferir las implicancias de usar Scrum a

través de toda la empresa
1.1.2 ADAPT - Transición a Ágil
 1.1.2 ADAPT - Transición a Ágil | Awareness
Conciencia: El cambio comienza cuando se toma conciencia de que el status quo ya no es
deseable. Sin embargo, tomar conciencia de que la forma en que hemos trabajado en
el pasado ya no funciona es extremadamente dificil.

Razones comunes por las que las personas demoran en tomar conciencia pueden ser:

• Falta de exposición a la figura completa

• Negativa a ver lo que esta junto en frente de nosotros
• Confundir movimiento con progreso
• Escuchar nuestra propia propaganda
 1.1.2 ADAPT - Transición a Ágil | Awareness
Herramientas para desarrollar Awareness :

• Comunicar que hay un problema

• Usar métricas

• Proveer exposición a nuevas personas y experiencias

• Ejecutar proyectos piloto

• Enfocarse en las razones mas importantes para el cambio

 1.1.2 ADAPT - Transición a Ágil | Desire
Deseo: Además de la conciencia de la necesidad de cambio, uno debe tener
el deseo del cambio. A pesar de que podemos estar inconformes con
algunos elementos del proyecto, nos aferramos al status qou o
simplemente no es el momento

La buena noticia es que el mismo mensaje enviado en otro

momento, puede ser suficiente para mover a alguien de la
conciencia de la necesidad del cambio al deseo del cambio
 1.1.2 ADAPT - Transición a Ágil | Desire
Herramientas para generar deseo

• Comunicar que hay una manera mejor

• Crear una sensación de urgencia
• Crear el momento
• Permitir que el equipo pruebe Scrum (Test Drive)
• Alinear incentivos
• Enfocarse en manejar el miedo
• Ayudar a las personas a dejar atrás el pasado
• No desacreditar el pasado
• Comprometer a los colaboradores en el esfuerzo
 1.1.2 ADAPT - Transición a Ágil | Ability
Habilidad: Toda la conciencia y el deseo del mundo no basta si el equipo no
logra adquirir habilidad de ser Ágil.

Tener éxito con Scrum requiere que el equipo de trabajo no solo aprenda nuevas
habilidades, sino también que desaprenda habilidades antiguas. Algunos de los
retos de Scrum son:

• Aprender nuevas habilidades técnicas

• Aprender a trabajar y pensar como equipo
• Aprender a crear software útil en periodos de tiempo cortos (short timeboxes)
 1.1.2 ADAPT - Transición a Ágil | Ability
Herramientas para generar habilidad:

• Proveer entrenamiento y coaching

• Responsabilidad de cada uno

• Compartir información

• Fijar objetivos razonables

• Solo hacerlo
 1.1.2 ADAPT - Transición a Ágil | Promotion
Objetivos de Promover:

• Promoviendo el éxito actual, se generara conciencia para el Nuevo ciclo de

mejoras

• Reforzar la conducta ágil en los equipos existentes, difundiendo las noticias

de las cosas buenas que se han logrado

• Crear conciencia e interés entre aquellos fuera de los grupos directamente

involucrados con Scrum.
 1.1.2 ADAPT - Transición a Ágil | Promotion
Herramientas para promover Scrum:

• Publicitar las historias de éxito

• Has un safari Ágil

• Atrae atención e interés

 1.1.2 ADAPT - Transición a Ágil | Transfer

Transferencia: Es imposible para un equipo Ágil mantenerse ágil por si mismos para
siempre. Si las implicancias de usar Scrum no se transfieren a otras áreas de la empresa,
la gravedad de estos departamentos eventualmente frenará los esfuerzos de la
transición. El resto de la organización debe ser compatible con Scrum.

Human resources
Facilities
Marketing
Finance
 1.3.1 Remember other frameworks and
methodologies: Waterfall, Crystal, Lean, XP, DSDM
– Atern, DevOps and CMM
XP (Extreme Programming) : Metodología ágil enfocado en
practices de desarrollo de software.
Promueve Entregas continuas llamadas Entregas Pequeñas (Lotes
Pequeños)

Prácticas comunes de XP:

• Test-Driven Development
• Collective Ownership
• Refactoring
• Continuous Integration
• Pair Programming
Adopción de Scrum Prácticas Ágiles

• Pair Programming
• Test-Driven Development
• Continuous Integration
• Continuous Refactoring
• Collective Code Ownership https://www.thoughtworks.com/insights/blog/effective-navigation-in-pair-programming

• Trabajo más divertido

• Aprendizaje
• Sentido de Equipo
• Menos defectos / Mayor
calidad
• Planificación de sucesión
Adopción de Scrum Prácticas Ágiles

Write test

• Pair Programming
• Test-Driven Development passed
Run test

• Continuous Integration failed

• Continuous Refactoring Write code

• Collective Code Ownership

Run test
failed

passed

Refactor
• Claridad en el trabajo a realizar
• La salida es simple
Adopción de Scrum Prácticas Ágiles

• Pair Programming
• Test-Driven Development
• Continuous Integration
• Continuous Refactoring
• Collective Code Ownership
http://www.360logica.com/blog/continuous-integration/

• Incrementos reales
• Alerta temprana
Adopción de Scrum Prácticas Ágiles

• Pair Programming
• Test-Driven Development
• Continuous Integration
• Continuous Refactoring
• Collective Code Ownership
https://www.pinterest.de/explore/desarrollo-guiado-por-pruebas/?lp=true

• Rápido y coherente
• Lecciones aprendidas
Adopción de Scrum Prácticas Ágiles

• Pair Programming
• Test-Driven Development
• Continuous Integration
• Continuous Refactoring
• Collective Code Ownership
https://www.slideshare.net/gsporar/peer-code-review-an-agile-process-2502327

• Colaboración
• Foco en el producto
Agilidad Agile Frameworks y Metodologías

Conectado con

 IT Service Management
Feedback Iteration

+ ROI
Agile
Incremental

Develop

ITIL® is a registered trade mark of AXELOS Limited, used under permission of AXELOS
Limited.
All rights reserved.
Agilidad Agile Frameworks y Metodologías | ITSM

¿Qué es Ágil?
Existen muchos frameworks ágiles que en esencia tratan de la entrega de
valor al cliente en el menor tiempo posible. En muchos casos, en el mundo
ITIL, Ágil significa entregar Servicios que cumplan con la funcionalidad
solicitada por el cliente (fit for purpose) en el plazo y costo establecidos.

¿Qué es ITIL?
ITIL es parte de las Mejores Prácticas de Gestión (BMP), familia de
frameworks, una familia de frameworks de gestión y entrega (delivery)
hechos para aprender las mejores practicas, cubriendo temas
complementarios como la gestión de Servicios, proyectos, programas y
portafolios.

ITIL provee un excelente framework o “cubo de conocimiento”, que habilita http://www.dinangreek.net/itil/

la entrega y operación de un portafolio efectivo de valor añadido al cliente
que continuamente evoluciona.

ITIL® is a registered trade mark of AXELOS Limited, used under permission of AXELOS Limited.
All rights reserved.
 1.4.1 Explain how to apply Agile Principles within IT Service
Management
Agile focuses on producing ITIL®-shaped services within short lead times, or ‘vertical slices’ as they are known. Vertical
slicing is the art of decomposing really big problems into smaller ones so that they can be focused on and tackled. Within an
Agile environment, we aim to produce services (or digestible service vertical slices) within weeks at best and months at
worst. Agile thinking can and should be applied across the whole of the ITIL® framework to ensure that the lead time from
the customer’s perspective is as short as possible. In other words, apply Agile excellence to improve the whole service
delivery system, not parts of the service delivery system.

However, a typical place to start integrating Agile and ITIL® is within Service Design and Service Transition; in
essence, delivering the changed service in an Agile way. Only focusing Agile into one part of ITIL® in this way does run
the risk that, from the customers perspective, the overall service delivery chain (gathering business requirements through to
making the service operational) may still take too long - even though the delivery capability within Service Design and
Transition is Agile and delivers ‘vertical slices’ very quickly. In other words, just changing one part of the delivery chain
may or may not benefit the customer. If we do focus the initial Agile transformation into the service delivery area between
Design and Transition, then the projects, programs and portfolios that deliver changed services can all be focused and
improved by using Agile.

Un buen punto de partida para integrar Ágil & ITIL es el Diseño del Servicio y la Transición del Servicio
Integracion ITIL
 5.1.3 Resistencia al cambio

The top reasons for resisting change, as given by employees and managers.
5.1.3 Resistencia al cambio
 5.1.3 Resistencia al cambio

Considere las siguientes actividades para ayudar a llevar a los pragmáticos a Scrum:

• Ejecutar un proyecto piloto e incluir pragmáticos en el equipo.

• Asegúrese de que los pragmáticos que no están en el equipo piloto vean los resultados.
• Proporcionar capacitación a pragmáticos.
• Exponer a los pragmáticos a los éxitos de otras empresas a través de conferencias,
Grupos regionales de interés ágil, y así sucesivamente.
• Esté abierto a los inconvenientes y desafíos de Scrum en lugar de venderlo como algo
perfecto (silver bullet).
• Involucrar a los pragmáticos en las comunidades de mejora.
5.1.3 Resistencia al cambio

• La resistencia activa se produce cuando alguien

toma una acción específica destinada a impedir o
hacer descarrilar la transición a Scrum.
• La resistencia pasiva se produce cuando alguien
no puede tomar una acción específica,
generalmente después de decir que lo hará.
 5.1.3 Resistencia al cambio
Obstinados
Escépticos

• Deje que el tiempo siga su curso.

• Alinear los incentivos.
• Proporcionar capacitación. • Crear insatisfacción con el status quo.
• Solicitar anécdotas de compañeros. • Reconocer y enfrentar el miedo.
• Nombrar un escéptico campeón.
• Empuje el problema.
• Crear conciencia.
Seguidores

• Cambiar la composición del equipo.

Saboteadores
• Elogiar el comportamiento correcto.
• Éxito. • Involucrarlos en el Diseño de la
• Reiterar y reforzar el compromiso. Solución.
• Muévalos. • Se el modelo de los comportamientos
• Despídalos adecuados tu mismo.
• Asegúrese de que las personas adecuadas estén • Identificar la verdadera barrera.
hablando.
 4.2.2 Identify the limits of a Scrum Team
What is the ideal team size for Scrum projects?

Generally accepted advice is that the ideal Scrum team size is five to nine individuals.

Large teams may include members with more diverse skills, experiences, and approaches. Large teams are not as much
at risk to the loss of a key person. They may also provide more opportunities for individuals to specialize in a
technology or a subset of the application.

On the other hand, there are even more advantages to small teams. These include the following:
There is less social loafing, - Constructive interaction is more likely to occur on a small team - Less time is spent
coordinating effort - No one can fade into the background - Small teams are more satisfying to their members
 4.2.2 Identify the limits of a Scrum Team
Ventajas de equipos Pequeños: (5 a 9)
• Hay menor distracción social
• Nadie se pierde en el grupo
• Menos tiempo para coordinar esfuerzos
• Mas satisfactorio para el equipo
• Menor probabilidad de que ocurra la sobre especialziación nosiva

Desventajas de equipos grandesd: (mas de 9)

• Son menos productivos
• Crean mas errores
 4.3.1 Explain which tools can help a Team to use or adopt Agile and
thereby increase the quality of the development process

Start Small or Go All In

Conventional, long-standing advice regarding transitioning to Scrum or any Agile process has
been to start with a pilot project, learn from it, and then spread Agile throughout the
organization. This approach is the frequently used start-small pattern in which an organization
selects typically one to three teams (of five to nine people each), gets them successful, and then
expands Scrum from there. As Scrum spreads through the organization, new teams benefit from
the lessons learned by the teams that have gone before. There are many variations of start small,
depending on how many people the organization wants to transition and how quickly they want
to do it. Start small can also be applied differently based on how risk-averse or uncertain about
the transition the organization is. For example, in some cases the first team or teams will finish
their projects before a second set of teams even begins. Other organizations will take an
overlapping approach, where the second set of teams starts only one or two sprints after the first.
 4.3.1 Explain which tools can help a Team to use or adopt Agile and
thereby increase the quality of the development process

Razones para preferir Starting Small

• Mas económico
• Éxito temprano garantizado (Quick wins)
• Evita el riesgo de una adopción going all in
• Menos estresante
• No require reestructurar la organización

Razones para preferir Going All In

• Reduce la Resistencia al cambio
• Evita problemas de coexistencia de scrum con otras metodologías
• La transición es más simple
 4.2.1 Explain in which cases it is not possible to use
Agile

Having Scrum temporarily coexist with a sequential process is often necessary in a

large organization. But it is important to remember that Agile is not a destination; being
Agile involves continuous improvement. As an organization attempts to become more
and more Agile, the conflicts between Scrum and sequential development will become
more painful. If the sources of these conflicts are not removed, organizational gravity
will pull the organization back to whatever software development process was in place
before adopting Scrum. A few nonthreatening Agile practices such as Daily Scrums or
continuous integration might remain, but the organization will have been unable to
achieve the compelling benefits of becoming Agile.
 4.2.1 Explain in which cases it is not possible to use
Agile

All change is hard. It’s not hard to see employees in an uproar over something so small as
a change in their company’s healthcare plan. Larger changes can be even more painful.
But there are certain attributes of transitioning to Scrum that make it more difficult than
most other changes. They are as follows:

• Successful change is not entirely top-down or bottom-up.

• The end state is unpredictable.
• Scrum is pervasive.
• Scrum is dramatically different.
• Change is coming more quickly than ever before.
• Best practices are dangerous.
End of Training
Resumen Final