Formación Scrum Masters Online alumnos.pptx

1. Scrum Master

2. Nombre Experiencia con Agile / Scrum Expectativas del curso Scrum Master Antes de empezar...

3. ¿Cada cuanto descansamos? Normas

4. Scrum & el papel del Scrum Master Agile Empirismo Roles Eventos Artefactos DoD People & Teams SM & Organización Índice

5. ¿Héroe o Mago?

6. Montemos nuestro propio Scrum Master Scrum Master I

7. Las frases como ‘aquí no se puede’, ‘es que este proyecto es especial ’… quedan como excusas y se usan como escudo para no cambiar y seguir como estamos.

8. ¡Abracemos el cambio!

9. Agile

10. En agile no existen planificaciones Un Scrum Master debe programar Todo equipo debe contar con un especialista QA Los desarrolladores no necesitan habilidades de trato con el cliente Los equipos Ágiles no hacen documentación Debemos tener a alguien que nos diga lo que tenemos que hacer ¿Verdad o Mentira?

11. PRINCIPIOS VALORES CONFIANZA SCRUM XP Pirámide Ágil

12. Manifiesto Ágil Individuos y sus interacciones Procesos y Herramientas Software funcionando Documentación exhaustiva Colaboración con el cliente Negociación contractual Respuesta ante el cambio Seguir un plan

13. Trabajo juntos 12 Principios Ágiles Satisfacer al cliente Bienvenida al Cambio Entrega frecuente Individuos motivados Conversación cara a cara Software Funcionando Desarrollo Sostenible Atención a la excelencia Mantener la simplicidad Equipos auto-organizados Reflexionar para mejorar

14. Arreglemos la temperatura Agile

15. Sois el nuevo Scrum Master para un equipo que quiere solucionar un problema con la temperatura de la Satélite Jose, facilitador, necesita programar la bomba de calor, el aire acondicionado, ventilación y persianas para todos los días. Reúnes al equipo para para desarrollar un listado de las variables que influyen en la temperatura de la satélite. Durante el día no se pueden aplicar ajustes y queremos una temperatura constante de 22ºC Arreglemos la temperatura

16. Materiales de construcción del edificio Número de personas Actividad de cada persona Metabolismo de cada persona El tiempo exterior (sol, lluvia, etc) Horarios de comida Temperatura de otras oficinas Puertas abiertas o cerradas Temperatura de la comida Otras Algunas variables

17. Podemos ignorar las variables con un proceso EMPÍRICO INSPECCIONAR la temperatura adecuada ADAPTAR el sistema que controla la temperatura (frío - calor) poníendonos de acuerdo TRANSPARENCIA es necesaria que la temperatura sea inspeccionada Solución empírica

18. Predictivo Empírico El trabajo y los resultados son entendidos antes que la ejecución A medida que se trabaja se realizan frecuentes inspecciones y adaptaciones Dado un conjunto de entradas bien definidas, se generan las mismas salidas. Siguiendo unos pasos predeterminados se obtienen los resultados conocidos Se acepta que los procesos estén imperfectamente definidos. Los resultados a veces son impredecibles e irrepetibles. Ej: fábrica, trabajo de construcción Ej: ventas, marketing, teatro o escritura creativa. El proceso adecuado para el problema adecuado

19. Fomentar el incremento de los niveles de interacción y comunicación Acotar el ambiente de acción Liderazgo sirviente Ayudar a probar, sentir y responder Promover la generación de ideas El trabajo del líder

20. Transparencia Inspección Proceso empírico Adaptación

21. Definición de Agilidad La habilidad para responder rápidamente y deliberadamente a los cambios demandados, controlando los riesgos. Flexibilidad, la capacidad para adaptarse rápida y eficientemente. La habilidad para innovar.

22. Scrum implementa los 3 pilares de un proceso empírico Transparencia Inspección Adaptación Todos sabemos lo que está pasando Revisión del trabajo realizado Ok al cambio de dirección

23. Iterativo e incremental Waterfall Scrum Tiempo Tiempo Tiempo Tiempo Habilidad para el cambio Valor de negocio Visibilidad Riesgo

24. Waterfall Scrum Riesgo Tiempo Tiempo Tiempo Tiempo Habilidad para el cambio Valor de negocio Visibilidad Iterativo e incremental (solución)

25. Scrum

26. Scrum es un framework

27. Investigar e identificar mercados viables, tecnologías y capacidades de productos Liberar productos y mejoras tantas veces como sea posible durante el día Mantener y renovar productos. Desarrollar productos y mejoras Desarrollar y mantener ambientes en la Nube (en línea, seguros, bajo demanda) y otros entornos operacionales para el uso de productos; Propósito de Scrum

28. Roles Artefactos Eventos PRODUCT OWNER DEVELOPMENT TEAM SCRUM MASTER PRODUCT BACKLOG SPRINT BACKLOG INCREMENTO SPRINT SPRINT PLANNING DAILY SCRUM REVIEW RETROSPECTIVE Scrum es un framework PRODUCT GOAL SPRINT GOAL DoD

29. Scrum values

30. Estás facilitando una retrospectiva y de pronto uno de los desarrolladores se queja de que sus ideas no se están teniendo en cuenta. ¿Qué valores de Scrum se están manifestando aquí?

31. Roles de Scrum

32. The Scrum Team User Community Customers & Stakeholders Management Product Owner Scrum Master Development Team Resumen de Roles

33. Product Owner Roles

34. Rebecca es la nueva Product Owner del equipo. Es su primera experiencia en Scrum y no tiene claro a qué se dedica un Product Owner. Ella ha leído que el Product Owner es el analista del equipo pero la ves discutiendo con un compañero que asegura que el Product Owner es un priorizador de tareas. ¿Cómo definirías a un Product Owner?

35. Labores de un PO Maximizar el valor del Producto & del Trabajo del Equipo Gestionar el Product Backlog

36. Labores de un PO en la Scrum Guide Puede delegar, pero sigue siendo el responsable Expresar los Items con claridad Optimizar el valor del trabajo Priorizar los items Asegurarse que el equipo de desarrollo entiende los items No debe ser un equipo, debe actuar como una sola voz Centralizar todas las peticiones (stakeholders) Asegurarse que el Product Backlog es visible, claro y transparente

37. Development Team Roles

38. ¿Qué es un Development Team?

39. Labores y Características del Development Team Crear incrementos de producto “terminados” que puedan subir a producción Autoorganizarse Multifuncionales Todos son desarrolladores (no hay etiquetas) No hay subequipos Puede haber especialistas, pero la responsabilidad es compartida Tamaño 3 a 9 personas (recomendado)

40. Dinámica online – El bolígrafo Se tienen 4 iteraciones Todos tienen 1 bolígrafo visible Pantalla encendida tengo el bolígrafo Se pasa el bólígrafo en un orden Pantalla apagada no tengo el bolígrafo Debe de dar una vuelta completa con un bolígrafo a la vez Todos son parte de un equipo 2 minutos de planificación ESTIMACIÓN ¿Cuántos bolis pasaremos? SPRINT Duración de 1 minuto RETROSPECTIVA Duración de 1 minuto

41. Scrum Master Roles

42. The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.”

43. Propósito del Scrum Master

44. Habilidades del Scrum Master

45. Funciones Generales del Scrum Master Scrum sea entendido y adoptado ajustándose a la teoría, prácticas y reglas de Scrum Líder al servicio del Equipo Scrum Gestión para superar los impedimentos ¿Cuál falta?

46. El SM al servicio del PO Encontrar técnicas para gestionar la Lista de Producto de manera efectiva Entender la planificación del producto en un entorno empírico; Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Lista de Producto claros y concisos Asegurar que el Dueño de Producto conozca cómo ordenar la Lista de Producto para maximizar el valor Entender y practicar la agilidad y facilitar los eventos de Scrum según se requiera o necesite.

47. El SM al servicio del Dev. Team Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional Gestionar para solventar impedimentos para el progreso del Equipo de Desarrollo Ayudar al Equipo de Desarrollo a crear productos de alto valor Facilitar los eventos de Scrum según se requiera o necesite Guiar al Equipo de Desarrollo en el entorno de organizaciones en las que Scrum aún no ha sido adoptado y entendido por completo

48. Actualmente estás trabajando como Scrum Master para un producto de Grandes Cuentas de un banco inversor, al llegar a la oficina ves problemas de comunicación entre el Product Owner y el Development Team. El Product Owner no entiende la parte técnica ya que hay microservicios y no sabe bien que son. El Development Team nunca ha trabajado con bancos de inversión y se lían con los términos funcionales y piden que hables tú con él. ¿Debería el Product Owner aprender tecnología? ¿Debería el Development Team aprender sobre el negocio? ¿Qué acción debes tomar?

49. Durante la formación del equipo y el inicio, descubres que el Scrum Team tiene que mantenerse trabajando en otros proyectos para que lleguen a tiempo. La presión de la organización y la sabiduría nos dicen que el equipo podrá trabajar en todos los proyectos a la vez ¿Qué podría ocurrir? Tu eres el Scrum Master Múltiples proyectos con un equipo

50. Dinámica de multitarea

51. Cuando cambiamos de tarea...

52. Una empresa decide que un equipo pase de 8 a 12 horas de trabajo Cuando trabajamos 12 horas la tasa de incidencias se dispara un 60% El tiempo para arreglar eso es de 4 horas diarias No hemos mejorado nada… ¿Aumentamos las horas de trabajo? Se trabaja 8 horas al día máximo

53. Liderar y guiar a la organización en la adopción de Scrum Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo empírico de producto Planificar las implementaciones de Scrum en la organización Motivar cambios que incrementen la productividad del Equipo Scrum Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la organización El SM al servicio de la Organización

56. Eventos

57. Development Team Scrum Master Product Owner Sprint planning Sprint backlog Daily scrum Sprint review Sprint Retrospective Product backlog Sprint Increment Idea < 30 días

58. El Sprint Eventos

59. La Scrum Master está trabajando en un equipo que va a comenzar pronto. Su jefe le ha planteado que van a trabajar 10 Sprints, siendo el 10º el Sprint de Release, para a continuación tener el Hardening Sprint donde mantendrán la aplicación. ¿Está entendido su jefe lo que es un Sprint?

60. Sprint planning Sprint backlog Daily scrum Sprint review Desarrollo terminado listo para release Sprint Retrospective Sprint Goal Time-boxed events Duración constante (<30 días) No es una fase Estable, sin cambios en lo posible

61. No llegamos a tiempo El equipo de desarrollo está trabajando bien durante el Sprint actual... Sin embargo, 3 días antes del fin del Sprint, el equipo pide más tiempo ¿Extenderías el Sprint? . 1 o 2 días podrían ser suficientes y con ello tener los tests completados

62. Tarea del Product Owner El objetivo del Sprint queda obsoleto Cambio de dirección de la compañía Cambio del mercado Condiciones Tecnológicas Hacer un nuevo planning Se acepta el trabajo “done” Cancelar un Sprint

63. El mes que viene vais a comenzar un nuevo Producto Software y estáis estudiando cómo organizar los próximos Sprints. El Development Team habla contigo porque quiere que el primer Sprint se dedique a construir una arquitectura completa. ¿Qué les dirías?

64. Estimación y velocidad ¿Qué opináis?

65. Sprint Planning Eventos

66. Eres el Scrum Master de un nuevo equipo que está desarrollando una aplicación muy innovadora a nivel tecnológico en el mercado. El equipo de desarrollo tiene que tomar una decisión tecnológica en mitad del Sprint que marcará el mismo. El Product Owner insiste en que quiere saber todo lo que se va a entregar y cuantos puntos se van a comprometer en este Sprint. ¿Por qué hay que tener todo el Sprint completo? ¿Qué les recomiendas?

67. Product Backlog Velocidad & Capacidad Definition of Done Tareas Retrospectiva Sprint Backlog Objetivo para este Sprint Previsión Resumen Analizar, evaluar y seleccionar “Product Backlog to Sprint” ¿Qué? Descomponer en un plan de acción ¿Cómo?

68. Alcance Objetivo Backlog fuera del Sprint Es un pronóstico Se actualiza con el avance Se puede renegociar a medida que avanza el Sprint Es una guía Se actualiza en todo momento Aporta flexibilidad en el cómo se implementa No se puede cambiar Objetivo del Sprint y alcance

69. ¿Qué vamos a hacer y cómo? Product Owner Expone la idea de objetivo para este Sprint & Alcance esperado Development Team Realizan preguntas para aclarar las tareas. Determinan el alcance realista que podrán abarcar Product Owner Development Team Acuerdan el objetivo final para este Sprint Development Team Descomponen el alcance en elementos pequeños (técnicos) Crear un plan para garantizar que consiguen el objetivo Presentar dicho plan al PO y al SM

70. Eres el Scrum Master para un equipo que lleva varios Sprints trabajando en nuevo producto. En este Sprint el Product Owner ha pedido una gran cantidad de items porque quiere lanzar una buena imagen a los stakeholders. El Development Team se ha venido arriba y está incluyendo una cantidad muy grande de items que posiblemente no puedan abordar durante el Sprint. ¿Qué deberían hacer?

71. Daily Scrum Eventos

72. Hay que hacer 3 preguntas Asiste PO, SM y DT Tiempo en función de las personas Se hace todos los días (es la daily!) Lugar lo determinamos cada día La hora se determina cada día ¿Qué hice ayer? ¿Qué voy a hacer hoy? ¿Tengo algún impedimento? De pié Es de reporte Sprint Backlog opcional Es de coordinación Se decide qué días hacerla Misma hora Mismo Lugar Sentado o de pié, no hay regla Asiste DT, el resto observadores Formato libre enfocado al Sprint Goal Reunión para fomentar la comunicación y autogestión con el objetivo puesto en el sprint goal Sprint Backlog obligatorio Discusiones detalladas son buenas Discusiones detalladas después 15 minutos Mito vs Realidad

73. Daily Scrum y el Scrum Master Dirigida por el equipo de Desarrollo SM enseña para que dure 15 minutos

74. Un SM está trabajando con su equipo cuando de repente su equipo les dice que si pueden hacer la Daily sólo los martes y jueves ya que no necesitan hacerlo diariamente. ¿Cómo debería actuar el SM si el equipo es autoorganizado y el evento es del Development Team?

75. Sprint Review Eventos

76. Sprint Review exitosa Durante el Sprint Review, el CEO y el Project Manager animan al equipo de desarrollo durante toda la reunión Al finalizar, incluso realizan un aplauso al equipo de desarrollo. ¿Qué les aconsejarías? Tú como Scrum Master...

77. Review vs Retrospectiva Sprint Retrospective Sprint Review Inspeccionar el incremento Ninguno El PO informa de la velocidad requerida para el siguiente Sprint Descubrir cómo hacer el siguiente Sprint más agradable El equipo Scrum se inspecciona a sí mismo Se actualiza el DoD para incrementar la calidad del producto Inspeccionar el Product Backlog y las fechas probables de entrega Una demo para enseñar el producto a los interesados Inspeccionar cómo fue el Sprint con respecto a personas y relaciones Inspeccionar los cambios del mercado y potencial uso del producto Actualizar el Product Backlog Reunión del estado para el “steering committee” Inspeccionar el incremento El PO informa de la velocidad requerida para el siguiente Sprint Descubrir cómo hacer el siguiente Sprint más agradable El equipo Scrum se inspecciona a sí mismo Se actualiza el DoD para incrementar la calidad del producto Inspeccionar el Product Backlog y las fechas probables de entrega Una demo para enseñar el producto a los interesados Inspeccionar cómo fue el Sprint con respecto a personas y relaciones Inspeccionar los cambios del mercado y potencial uso del producto Actualizar el Product Backlog Reunión del estado para el “steering committee”

78. Equipo Scrum + Interesados invitados por el PO Máximo 4 horas para Sprints de 1 mes Debatir cómo dar más valor No es una demostración Es una sesión de colaboración Sprint Review: Características Características de Sprint Review

79. El PO invita a los stakeholder que considere clave para la sesión Product Backlog Incremento Estado del Mercado El PO habla sobre estado del Product Backlog Product Backlog Actualizado El PO Expone qué elementos terminados y qué elementos no. El DT Habla sobre que estuvo bien en el Sprint, qué problemas se dieron y cómo se resolvieron. A continuación, se enseña el trabajo finalizado y responde dudas sobre el incremento. (Opcional) el PO podrá hacer proyecciones de posibles fechas de entrega en función de la velocidad del DT. El grupo colabora sobre qué hacer a continuación. Revisión del mercado o el uso potencial del producto para saber qué es lo más valioso Revisión de la línea de tiempo, presupuestos, capacidades potenciales y mercado para la próxima entrega

80. Eres el Scrum Master de un equipo que tiene Sprints de 3 semanas. Durante la Sprint Review el Product Owner decide que el incremento va a subir a producción al inicio del siguiente Sprint. Los stakeholders sugieren que ya no se hagan más Sprints para poder reaccionar más rápido al feedback del usuario (y las incidencias) que se producirán al subir a producción. El Product Owner prefiere seguir haciendo Sprints para progresar hacia la siguiente Release. Tu facilitas la discusión. ¿Qué resultados aceptables podrían salir de la discusión?

81. Sprint Retrospective Eventos

82. Eres Scrum Master para un nuevo cliente que es nuevo en Scrum. Es la retrospectiva del 4º Sprint y la Product Owner no ha venido a ninguna. Hablas con ella y afirma que solo debe ir si la invitan y que por eso no ha ido nunca. ¿Qué topics saldrán en la retrospectiva? ¿Debe ir un Product Owner a la Retrospectiva?

83. Inspeccionarse a sí mismo Scrum Master es un miembro más Plan de mejoras para el siguiente Sprint 3 horas por Sprint de un mes Sprint Retrospective: Características

84. Propósitos Inspeccionar: personas relaciones procesos herramientas Adaptar la Definition of Done para mejorar la calidad Enfocado para inspección y adaptación Crear un plan de mejoras Sprint Retrospective: Propósitos

86. Roles Artefactos Eventos Scrum es un framework

88. Artefactos

89. Product Backlog Artefactos

90. Te acaban de asignar como Scrum Master para un producto en el que hay 2 equipos Scrums. Pides acceder al Product Backlog para estudiar el producto y la respuesta del equipo te sorprende ¡Tenemos dos Product Backlog! ¿Qué problema se podría presentar? ¿Cómo son las prioridades en este equipo?

91. Compuesto por items: características, funcionalidades, requisitos y mejoras Backlog existe mientras exista el producto Dueño es el Product Owner Dinámico: evoluciona con lo que necesita el producto Puede haber varios equipos pero solo 1 backlog Incompleto: refleja los requisitos conocidos y mejor entendidos Product Backlog

92. Product backlog Sprint 1 Sprint 2+3 Sprint 4 + Requisitos más claros y mejor entendidos Continuamente “refinado” Product Backlog

93. Estás trabajando como Scrum Master para un nuevo portal web. Has enseñado a tu Product Owner el Product Backlog y le has ayudado a definir los items. Sin embargo, descubres que no tiene claro cómo priorizar y observas que está teniendo problemas. ¿Qué acción debes tomar?

94. Product backlog 5 20 High Low Priority Eliminar Insertar item Estimar & Ajustar Repriorizar Dividir Refinement

95. Sprint backlog Sprint Backlog Artefactos

96. Eres el Scrum Master de un nuevo equipo en Scrum. Durante el Sprint detectas que el Development Team no está actualizando el Sprint Backlog. Cuando hablamos con el equipo ellos dicen que no es su trabajo. ¿Quién es el responsable del seguimiento del Sprint?

97. Product backlog Dueño: equipo de desarrollo Predicción del próximo incremento “terminado” Nivel de detalle suficiente para el Dev. Team Muestra el progreso y se actualiza a medida que tenemos más conocimientos Sprint Backlog, el Cómo Plan sobre CÓMO se conseguirá el objetivo del Sprint Sprint Board Product Backlog TODO DOING DONE ITEM 1 ITEM 2 ITEM 3 ITEM 4 Mejora de proceso de alta prioridad de la retrospectiva anterior

98. Billy es miembro de un Development Team y está discutiendo con un compañero. Él asegura que cuando un miembro del equipo mueve una tarea a Doing en el “Jira” entonces se asigna la tarea y pasa a ser responsable de la misma. Su compañero asegura que el reparto de tareas se debería hacer en la Daily Scrum. ¿Cuando los miembros del Development Team son propietarios de una tarea del Sprint Backlog?

99. Estás en mitad de un Sprint conversando con un miembro del Development Team. Esta compañera te indica que ha detectado un nuevo trabajo que habrá que realizar para alcanzar el Sprint Goal. Tu le preguntas el motivo de porqué aún no lo ha añadido al Sprint Backlog a lo que contesta “Mañana en la Daily Scrum cuando mis compañeros lo aprueben” ¿Es correcto este comportamiento?

100. Incremento Artefactos

101. Suma de todos los elementos del Backlog completados Suma del VALOR de los elementos del backlog completados El incremento es sobre elementos “terminados” (cumplen la DoD) El incremento debe estar en condiciones de ser usable (aunque el PO decida no subirlo) El incremento

102. Done || Undone

103. Durante el Sprint Review, el equipo de desarrollo discute una nueva feature. La feature funciona bien, pero no pasó los criterios de rendimiento fijados en la Definition of Done. El equipo considera que puede realizar este reto técnico durante el siguiente Sprint, y confía en que el Sistema soportará la carga durante los próximos 2 Sprints. ¿Qué harías? Dado que es una feature por la que nuestros clientes están dispuestos a pagar, el Product Owner decide liberarla. Principios

104. Trabajo sin terminar es deuda técnica Tiempo para realizar nuevas “features” Tiempo destinado a la deuda técnica y a la complejidad

105. Deuda técnica es un problema grave Clientes demandan y esperan que esté en fecha Desarrolladores consciente o inconscientemente recortar la calidad Clientes y desarrolladores se resienten de la profesión Fallan los productos y fallan las compañías

106. Defectos Falta de tests unitarios Pocos tests de aceptación Falta de automatización en la construcción y despliegue Código muy dependiente Código duplicado Código muy complejo Lógica de negocio en mal sitio Errores en la nomenclatura Ejemplos de Deuda Técnica

107. La empresa XYZ está construyendo productos para salvar la vida de sus usuarios. Tu equipo Scrum está trabajando en una versión del firmware de un producto ¿Qué contendría tu definition of done? ¿Es suficiente? Hacéis 2 semanas de Sprint. El equipo tiene todas las skills para desarrollar incrementos de producto terminados. Definiendo “hecho”

108. Pruebas de Rendimiento Test de respuesta inmunológica Pruebas de Estabilidad Refactorización Notas de la versión Internacionalizado en seis culturas donde el producto podría ser vendido Test de Regresión Test de aceptación de usuarios Documentación de Usuario Revisión de código ¿Contenía tu DoD estos casos?

109. DoD = Listo para Subida DoD completo: - Sostenibilidad - Cohesión - Mantenibilidad Incremento en cada Sprint & evitar sorpresas Done para todo el producto (no solo el incremento) Definition of Done proporciona transparencia

110. El Product Owner de un nuevo producto que se va a desarrollar durante la primera Sprint Planning comenta que le gustaría que la aplicación funcionara rápidamente. El Development Team responde que lo construirán lo mejor posible para que vaya lo más rápido posible. Además, proponen que el último Sprint antes de la entrega acometerán las pruebas. ¿Qué problema se podrían encontrar? ¿Cómo gestionamos los requisitos no funcionales?

111. No tendremos una velocidad estable sobre la que estimar El Product Backlog probablemente no estará en buena forma Nuestro burn-down será incorrecto Nuestro PO no conocerá el progreso o el estado El equipo de desarrollo no sabrá cuanto alcance seleccionar En la review el PO no sabe que está siendo inspeccionado Sin Definition of Done

112. Estás trabajando en un Scrum Team al que le queda poco para subir a Producción. El PO dice que cuando acabe el presente Sprint le gustaría subir porque su jefe le está presionando. Durante la planning el PO manifiesta que necesita 30 PBIs pero el Dev Team asegura que cumpliendo la DoD solo podrán alcanzar unos 15. El Product Owner les pide que no cumplan la DoD, ya lo arreglarán más adelante. ¿Qué podría ocasionar esta decisión?

113. Sprint Burndown Chart

114. El Sprint actual termina mañana. Estás ayudando al Product Owner a preparar la Sprint Review cuando un miembro del equipo te llama. Ha estado trabajando en una Historia de Usuario muy grande (40 puntos). Él dice que ya está terminada aunque no cumpla los test y que considera que se debe presentar la funcionalidad y contabilizar los puntos en la velocidad, de lo contrario habría un trabajo invisible que se ha realizado que no se estaría teniendo en cuenta. ¿Qué hacemos con los PBIs que no cumplen la DoD? ¿Cómo afectan estos PBIs a la velocidad?

116. Peoples & Teams

117. Cierto Falso Un equipo debe estar sentados juntos Un equipo de desarrollo no puede ser menor de 3 personas Un equipo de desarrollo no puede ser mayor de 9 personas Cada miembro del equipo de desarrollo debe ser capaz de abordar cualquier tipo de tarea Si un equipo Scrum consulta a personas externas o recursos, entonces ellos no están autoorganizados Todos los miembros del equipo de desarrollo necesitan estar presentes en el equipo “full time” Un equipo Scrum debe tener claro los subroles (coder, tester, analyst, etc) y rendir cuentas Un equipo de componentes (back, front, etc) no es Scrum Cierto o Falso

118. Cierto Falso Un equipo debe estar sentados juntos Un equipo de desarrollo no puede ser menor de 3 personas Un equipo de desarrollo no puede ser mayor de 9 personas Cada miembro del equipo de desarrollo debe ser capaz de abordar cualquier tipo de tarea Si un equipo Scrum consulta a personas externas o recursos, entonces ellos no están autoorganizados Todos los miembros del equipo de desarrollo necesitan estar presentes en el equipo “full time” Un equipo Scrum debe tener claro los subroles (coder, tester, analyst, etc) y rendir cuentas Un equipo de componentes (back, front, etc) no es Scrum Cierto o Falso

119. Algunas ideas para motivar ¿Cómo conseguir motivar?

120. El dinero es importante pero es un “carrot and stick” solo funciona para trabajos mecánicos No funciona para trabajos complejos o creativos... ¿Cómo conseguir motivar de verdad? ¿Cómo conseguir motivar?

121. Maestría ser cada vez mejor en mi trabajo Autonomía 0rganizar mi propio trabajo Propósito ser trascendente ¿Cómo conseguir motivar de verdad? ¿Cómo conseguir motivar de verdad?

122. Casos de éxito: El desfile militar: Trascendencia

123. WestPointg 1963 Westpoint 1963

124. 24 compañías desfilaban cada dos semanas Al finalizar los responsables de cada grupo se votaban entre ellos Había cierto “pique” tras 2 siglos de desfiles La compañía L2 llevaba 1 siglo quedando la última Características

125. Poner en sitios visibles los errores cometidos No había culpa, no había castigo. Solo información sacada de las evaluaciones “Charlie lleva la espada arrastrando” “Jim no se giró en sincronía” “El saludo de Dave fue bastante chapucero” El plan

126. “ ustedes son la levadura que une todo tejido de nuestro sistema nacional de defensa. De entre sus filas han salido los grandes capitanes que tienen en sus manos el destino de la nación cuando suenan las campanas de la guerra La larga línea gris nunca nos ha fallado. Si ustedes lo hicieran, un millón de espectros de color verde olivo, caqui pardo, azul y gris, se levantarían de sus blancas tumbas, haciendo resonar aquellas palabras mágicas: Deber, honor y patria La trascendencia

127. Eres el Scrum Master de 3 equipos. Los 3 equipos tienen el mismo Product Backlog, tiene el mismo Product Owner y comparten el código. Los equipos de desarrollo comentan que en los próximos 3 Sprints quieren trabajar en el mismo área de la Base de Datos ¿Qué sugerirías? Sólo hay una persona DBA que conoce ese subesquema bien. Los 3 equipos necesitan a Cindy Full- Time. Problema

128. El equipo sigue órdenes El equipo decide sobre su trabajo diario y gestiona su progreso El equipo gestiona su entorno de trabajo El equipo decide sobre producto, visión y requisitos El equipo decide en qué productos trabajar El equipo decide sobre su composición El equipo decide sobre incentivos y recompensas El equipo decide sobre su misión, objetivos y dirección. El equipo decide sobre maneras de conseguir sus objetivos Company Team Product Work None Algunas áreas de autoorganización

129. Te acaban de asignar a un gran producto que está desarrollando la empresa XYZ. Es producto va a contener unos 100 desarrolladores que van a ser agrupados en equipos. El Manager de contratación te convoca a una reunión llamada “Organización de equipos”. En la reunión un manager propone hacer una matriz de habilidades entre todo el mundo para cuadrar a las personas. Otra persona propone que se hagan rotaciones entre equipos. El tercero propone estudiar quienes han trabajado antes y tratar de agruparlos. ¿Cómo deberían gestionarse el reparto de personas en los equipos?

130. No se queda trabajo sin acabar y sin saber Un equipo de desarrollo debe tener todas las skill (habilidades) para llevar al Product Backlog en un incremento de trabajo Con una visión vertical el trabajo se orienta a completar funcionalidad Cada Sprint se entrega incremento (no hay que esperar) Composición de equipos

131. Comportamientos que promueven el trabajo en equipo y la cohesión entre los miembros Comportamientos contraproducentes para el trabajo en equipo y la cohesión Green Zone Red Zone Comportamientos de Equipo

132. Green Zone Red Zone - Escuchar, responder - Habla no defensiva - Abierto, sin amenazar - Firme, pero no rígido - Da la bienvenida al feedback - Éxito compartido - Colaboración - Transmiten, no reciben - Responden defensivamente - Sensación de agravio - Batallas y antagonismos - Toman todo a lo personal - Perspectiva de un enemigo - Auto promoción Pensamiento compartido

133. Forming Storming Norming Performing ● Construir rutinas ● Centrados en las formalidades ● Observación ● Evitar el conflicto ● Aparecen las diferencias ● Crece la interdependencia ● Conflictos ● Objetivos de equipo ● Planes en común ● Estándares ● Compromiso ● Autónomos ● No necesitan supervisión ● Se puede disentir para mejorar Las 4 etapas de un grupo de desarrollo (Bruce Tuckman)

134. Eres el Scrum Master de un equipo que lleva 10 Sprints. Casi todo el Development Team está quejándose del trabajo de un miembro de equipo. Parece que no colabora con el grupo, se salta los eventos de Scrum y tiene poco interés por el equipo. ¿Quién debe sacar a personas del Development Team?

135. War Contienda Fortificación Disentimiento Productivo Armonía total ¿En qué nivel estamos? Niveles de conflicto

136. Modos de respuesta ante el conflicto (Thomas Killman)

137. Ausencia de confianza Miedo al Conflicto Evitar rendir cuentas Falta de atención a los resultados Equipo Falta de compromiso Las 5 disfunciones de un equipo (Jossey-Bass)

138. Te encuentras en el Sprint 7 de un producto de medios de pago. Un desarrollador te busca para contarte que ha encontrado una incidencia grave que afecta a la seguridad de la aplicación. ¿Qué haces a continuación?

139. Scrum Master influye de manera indirecta

140. Scrum Master Líder desde el Ejemplo

141. Crear un entorno seguro para el debate: mantenerlo y hacerlo productivo mediante el coaching

142. Mantener la claridad en las decisiones en las reuniones de equipo

143. Aprender a leer la sala, estar conectado sin estar presente.

144. Recordad al equipo que el conflicto puede ser sano y beneficioso

145. Muestra paciencia y silencio, deja que el equipo entre en acción.

146. No resuelvas, deja que el equipo aprenda y enseñarles a aprender y desarrollar positivamente conflictos.

147. Siéntete confortable con el resultado de una decisión (no anticipes sus efectos)

148. Cuída de las personas

149. Scrum Master Muéstrate poco tolerante con los impedimentos de la organización.

150. Estás trabajando para un cliente que es nuevo en Scrum. Este cliente no entiende la dedicación que tiene que tener el Scrum Master y el Product Owner ya que piensa que están duplicadas la funciones. Además, uno de los miembros dice que ha leído que los equipos más avanzados pueden trabajar sin Scrum Master ¿Qué % de dedicación tienen que tener el Product Owner y el Scrum Mäster? ¿Podemos prescindir del Scrum Master?

151. Scrum & el papel del Scrum Master Agile Empirismo Roles Eventos Artefactos DoD People & Teams SM & Organizaci ón Índice

152. SM y Managers: Cómo educarlos

153. Eres el Scrum Master de un equipo y el Product Owner se reúne contigo porque cree que el Development Team no va a entregar los puntos comprometidos en este Sprint y te pide ayuda. Ella sugiere añadir recursos al proyecto cuanto antes. ¿Cómo deberías actuar?

154. Scrum Master Asumir compromisos de la cantidad de trabajo que el equipo hará en una fecha concreta

155. Tratar de convencer al equipo que los compromisos adquiridos en su nombre son posibles.

156. Darle dirección al equipo de cómo implementar los compromisos

157. Monitorizar el progreso del equipo y mantenerlo en una planificación

158. Intervenir y solucionar problemas si el equipo se atrasa o encuentra problemas

159. Actualizaciones semanales de estado

160. Reuniones 1 a 1 para ver problemas y marcar una dirección por parte del manager

161. Dar motivación a base de zanahoria/látigo para que trabajen duro

162. Asignar el trabajo y controlar el trabajo que ellos debían tener hecho

163. La compañía acaba de contratar a un Manager para una compañía que utiliza Scrum. Dicho Manager está discutiendo con su jefe sobre sus labores como manager respecto a los equipos. El manager propone encargarse de medir la productividad del equipo, darle indicaciones al Product Owner sobre las partes más importantes del producto, gestionar el personal de los equipos y encargarse de despedir a las personas con bajo rendimiento. ¿Qué te parecen las funciones del Manager? ¿Qué otras funciones podrían ser más interesantes?

164. El proyecto donde el equipo Scrum está trabajando lleva retraso. La presión por parte de la organización, sobre todo el CIO, se incrementa exponencialmente. Con el objetivo de ganar tiempo y ganar productividad el equipo decide parar de realizar la retrospectiva. ¿Qué les aconsejarías? Eliminando residuos para ganar tiempo

165. Rindiendo cuentas como Scrum Master

166. Asegurar que Scrum es entendido y promulgado

167. Facilitar los eventos de Scrum si son necesitados o requeridos

168. Ayudar a todo el mundo a interiorizar la teoría, prácticas y reglas de Scrum

169. Líder servicial para el Equipo Scrum

170. Provoca el cambio que genera calidad o productividad

171. Enseña técnicas

172. Personifica la agilidad para la organización ayudando a que cambie

173. El nuevo Scrum Master de un equipo que es nuevo en Scrum con una organización bastante tradicional, tras varios Sprint tiene una cantidad muy elevada de impedimentos sin resolver. ¿Cómo le recomendarías que gestione los impedimentos cuando son demasiados?

174. Acercarse a ... Coordinar individuos y sus contribuciones Proveer respuestas como experto en la materia Entrenar a personas en Scrum y en comportamientos positivos que gradualmente adquieren los valores de Scrum. Permitir la autoorganización dentro de los equipos Scrum Alejarse de... Invertir tiempo en resultados concretos (presupuesto o alcance) Ayudar a los Product Owners a gestionar el Product Backlog y a trabajar con los Stakeholders Plazos Preescribir soluciones técnicas Resolver problemas Centrarse en generar valor constante para el Product Owner Ayudar al Equipo de Desarrollo a entender y expandir la Definición de Hecho Guiar al equipo de desarrollo a descubrir maneras mejores de trabajar para ellos. Desde el controlador hacia el habilitador

175. Eres el Scrum Master de un Development Team que ha decidido usar Pair Programming como técnica de desarrollo. Todos los días los miembros se quejan sobre Frank. Al parecer cada persona que le toca trabajar con él acaba en discusiones interminables sobre la arquitectura que habían acordado entre todos. Frank siempre reabre el debate con su par y vuelve a la misma discusión ¿Cómo actuarías?

176. ¿Estamos preparados?

177. Un nuevo equipo Scrum están reunidos para decidir el tamaño del Sprint que van a utilizar cuando te invitan a la reunión. Unos dicen que quieren Sprints de una semana para poder ir rápido mientras que otros quieren Sprints de 4 semanas porque así seguro que cumplen la DoD y les sobrará tiempo de colchón. ¿Qué criterio(s) se debe(n) seguir para determinar el tamaño del Sprint?

178. Paso 1: Empezar con Scrum

179. ¿Hay un equipo Scrum con un Product Owner reconocido, un Equipo de desarrollo de 3 a 9 personas y un Scrum Master? Móntalo Continúa

180. ¿Hay un Product Backlog ordenado? Enseña a ordenar Continúa

181. ¿Hay un Sprint backlog que muestra el trabajo restante en el Sprint? Enseña a crearlo Continúa Prod uct backl og

182. ¿Cada Sprint dura 1 mes o menos? Enseña a ser constante Continúa Prod uct backl og

183. ¿Hay un entregable con un incremento del producto cada Sprint? Enseña la importancia de la entrega Continúa Prod uct backl og

184. ¿Crea el equipo de Scrum un plan para el Sprint en la Sprint Planning meeting? Enseña a planificar Continúa Prod uct backl og

185. ¿El Equipo de desarrollo replanifica cada día en la Daily? Enseña a hacer seguimiento Continúa Prod uct backl og

186. ¿El incremento es presentado a los stakeholders en la Sprint Review? Enseña a presentar Continúa Prod uct backl og

187. ¿El equipo Scrum realiza la Sprint Retrospective cada Sprint? Enseña a hacerlas Continúa Prod uct backl og

188. Prod uct backl og

189. Scrum con multiequipos Cuando múltiples equipos construyen un producto, ¿Qué elementos de Scrum podrían compartirse? ¿Qué elementos podrían ser diferentes por equipo? ¿Qué añadirías?

190. Roles Artefactos Eventos Product Owner Development Team Scrum Master Product Backlog Sprint Backlog Incremento Sprint Sprint Planning Daily Meeting Review Retrospective Scrum con multiequipos ¿Igual o diferente?

191. Actualmente trabajas en un equipo de 5 personas que están construyendo un nuevo producto. Tu Development Team te pregunta cómo les vas a ayudar a coordinar su trabajo con el otro Development Team. Ellos proponen que compongas un tablero común entre todas las tareas del equipo, o que visites lo que están haciendo sus compañeros y los mantengas informados. El Product Owner te pide que se nombre un Lead en cada equipo para trabajar con él en la coordinación de las tareas de cada equipo. ¿Qué deberías hacer como Scrum Master?

192. Actualmente trabajas con 3 equipos Scrum que desarrollan el mismo producto con un solo Product Owner. Ellos proponen que cada equipo presente su parte en una rama distinta del repositorio. ¿Qué está ocurriendo?

193. Eres el Scrum Master de un equipo que lleva 5 Sprints trabajando bien. Detectáis que el Product Owner está empezando a no colaborar con el Development Team. No les dedica tiempo, no les ayudar a definir bien y cuando hay problema no se lo transmite al Development Team. ¿Cómo deberías actuar?

194. Eventos Scrum en la práctica

195. Preparando la Planning Proporcionar una Estructura Asegurarse que el PO tiene listo el PB

196. Si el Sprint Goal fuera un titular ¿Cuál sería? Ejemplo Estructura ¿Cuál es la composición del equipo en este Sprint? ¿Cuál es la capacidad del equipo? ¿Cuáles son los PBIs de más valor? ¿Cuáles son los riesgos de los PBIs? (técnicos, políticos, culturales) ¿Qué otras preocupaciones tenéis? ¿Cuáles son las historias, condiciones de satisfacción, tareas y estimaciones de los items que conformarán el Sprint Backlog? Preparamos un flip chart con las siguientes preguntas…. Una vez que tenemos todo esto... Una vez que tenemos todo esto... ¿Han cambiado alguna historia? ¿Alguna ha vuelto al Product Backlog? ¿Cuál es el compromiso final del Development Team? ¿Esta el Sprint Goal bien identificado?

197. Ayudar al PO Compromiso del PO Trabajo duro Sabrás que has terminado cuando los PBIs de más valor estén en el top El PO ha hecho todo el trabajo relacionado con los items Los items tienen el tamaño bueno para entrar en un Sprint

198. Facilitando la Planning La presión del time-box debería ayudar a que funcione. Una vez se arranca la sesión déjales que hablen. Limítate a observar. Estate quieto, estás haciendo una cosa importante, estar callado. Escucha, mira y mira momentos donde puedas enseñarles. Haz preguntas ¿Cuántas de estas preguntas (del checklist) sabrías decir la respuesta? Presiona con el tiempo, “quedan 2 horas”, “queda 1 hora”.

199. Historia de Usuario 204 Características Historia Usuario: I Independent – Independiente. N Negotiable - Negociable. V Valuable – Valioso. E Estimable – Estimable. S Sized appropriately - Tamaño apropiado. T Testable – Testeable. <Rol> Quien realiza la acción o recibe el valor de la acción. Persona / Sistema. <Funcionalidad> Funcionalidad o actividad que representa la acción a realizar por el sistema. <Beneficio> Representa el valor de negocio que se espera generar. Visualización del consumo diario Como consumidor, (<rol>) quiero poder ver mi uso diario de energía (<funcionalidad>) de modo que pueda comenzar a entender cómo bajar mis costes con el tiempo (<beneficio>).

200. Ejemplos de Tareas de una Historia de Usuario 205 - Diseño de la historia de usuario - Implementación de la historia de usuario - Pruebas unitarias asociadas a la historia de usuario - Pruebas de aceptación asociadas a la historia de usuario - Requisitos no funcionales - Revisión de código - Refactorización de código - Mocks y emulaciones de código - Pruebas exploratorias - Corrección de errores - Verificación de errores - Demostración interna de la historia de usuario - Actualización de la wiki o info de la US - Documentación asociada Buenas prácticas: - El tamaño de las tareas ha de ser de entre medio día y 3 días de trabajo de 1 persona. - Crear tareas que una vez completadas generen un producto entregable (historia narrativa). - No dedicar excesivo tiempo a estudiar los detalles de cada tarea (no se estiman tareas!) Características Tareas: S Specific – Específico. M Measurable – Medible. A Achievable – Realizable. R Relevant – Relevante. T Time-boxed – Limitada.

201. Estimar todo lo que entra en el Sprint Backlog

202. El valor de las estimaciones en el Sprint Backlog El equipo trabaja 8 horas al día = 8 * 10 = 80 horas per/ Sprint. El total de horas = 10 * 9 * 8 = 720 horas por Sprint. 70 puntos de historia de media en los últimos 5 sprints ¿Cuál es el coste del punto de historia?

203. Teachable Moments ¿La US está bien construída? ¿Quién es el usuario real? etc… Estudiar las mejores historias. “Qué bonita es esta US… pero ¿Qué valor aporta? ¿Qué gana un usuario FINAL de esto?” Promociona la figura del Product Owner: uno es dueño del Qué otro del Cómo, crea límites A veces los roles se volverán borrosos: el PO exigirá al DT o el SM se meterá en mucho detalle técnico. En ese caso pídele al equipo que quieres volver a tu rol. El equipo a veces desea entrar ya a dividir en tareas. Cuidado!, hay que asegurarse que tienen el conocimiento de negocio. Usa un Mind-Map para asegurarse los conocimientos

204. Facilitando Sprint Review Tu papel en la Review es secundario. Deja que el PO y el DT muestren el producto a los stakeholders Cuidado con perder mucho tiempo maquillando las presentaciones. Es mejor invertir tiempo en hacer producto y no en mostrar el producto mejor de lo que es.

205. Recordar el propósito Hubo un compromiso por parte del DT, ¿Qué hemos cumplido? ¡Enseña el producto! No uses PPTs. Obtén feedback directo ¿Cómo de útil es el producto? ¿Cumple su propósito? Pregunta a stakeholders, customers y users. Ofrece ideas: dales a los stakeholders una ventana en la que dar ideas sobre cómo el equipo se organiza y actúa en la organización (úsalo de entrada para la retrospectiva) Pide ayuda: Muestra los problemas que el PO y el SM no pueden resolver y que los stakeholders ayuden.

206. El papel del SM Durante la reunión tu papel es insignificante. Lo hagan bien o mal, no es bueno intervenir, en vez de eso, observa y toma notas sobre... ¿Cómo están interactuando? ¿Cuándo alguien habla los demás observan? ¿Qué efecto provoca? ¿Cómo interactúa el DT y el PO? ¿Y los Customer/Stakeholders/Users? ¿Hacen peticiones? ¿El PO está usando el PB para anotar las peticiones? ¿Está mirando el valor? ¿Alguien fue intimidado? ¿La gente se pudo expresar? ¿Aparecieron problemas de Agile en la conversación? Consejo: Anota las palabras exactas para después!

207. Hacer Observaciones Ejemplos de observaciones que se pueden hacer después. “El Sponsor ha venido, ella está aquí, motivada y receptiva, ¡Esto es fantástico!” He notado un gran silencio cuando el Sponsor ha preguntado ¿Cómo hemos hecho Agile? ¿Qué pensasteis cada uno de vosotros? Un Stakeholders nos pedía más información. ¿Cuál creéis que es el origen de esa petición? ¿Qué preocupación tiene? He visto que nadie ha mandado emails o whatsapp durante la review. ¡Eso es fantástico! Seguro que esto ayudó a los stakeholders a que vieran lo mucho que os importa. PO han habido muchas peticiones de cambio. ¿Cómo gestionaremos el PB ahora para dar el máximo valor posible?

208. + Observaciones ¿Alguién se despistó durante la reunión? ¿Alguno se evadió mientras hablaba alguien? ¿Qué hacéis cuando eso ocurre? Se habla de meter a alguien en el equipo ¿Qué opina el equipo sobre esto y sobre quién debería ser? ¿Quién tomará la decisión? Hubo mucho silencio cuando se empezó a hablar sobre los pasos de la siguiente release ¿Es correcto? Había dos stakeholders que siempre hablaban del mismo topic. ¿Cómo reaccionasteis? He visto al Sponsor muy activo lanzando diferentes mensajes, he oído “tomate tiempo para que salga bien”, “hay que estar cerca del customer”. ¿Qué habéis oído vosotros?

209. Facilitando Retrospectives Objetivo es inspección & adaptación para tomar aire. Mirar hacia el cómo y no el qué. Hacer mejor las cosas la próxima vez.

210. ¿Cómo preparamos las retrospectivas?

211. Preparar la Retrospectiva El mejor consejo es observar el comportamiento del Scrum Team ¿Está usando el equipo alguna estructura de Agile? ¿Qué tolera el equipo? ¿Qué funciona bien? ¿Dónde se rompe la comunicación, la colaboración o la coordinación? ¿Dónde ocurren los momentos brillantes? ¿Cómo cambia el nivel de ansiedad del equipo durante el Sprint? ¿Están las personas presentes físicamente, mentalmente y emocionalmente?

212. Facilitar la Retrospectiva

213. Después de la retrospectiva Al finalizar la retrospectiva salen acciones. Si ves que se olvidan de las acciones, recuerdalas durante el Sprint varias veces. Si alguien realiza una acción relacionado con un acuerdo de la retro, felicitalo. Si alguien realiza una acción contraria a un acuerdo de la retro, no lo dejes pasar. Lanza la pregunta ¿Qué pasa con este acuerdo al que llegamos?

214. Estás trabajando como Scrum Master con un equipo que se encuentra en mitad del Sprint desarrollando un nuevo producto. El Development Team descubre que no entienden bien un requisito funcional que pone en peligro la entrega de valor. El equipo propone hacer solo lo que han entendido, dejar la parte que no entienden para debatir en la Review y desarrollarlo en el siguiente Sprint. ¿Qué les podrías recomendar?

215. Mediar en conflictos

216. Conflictos productivos. El conflicto existe en los equipos. Hay varios niveles. El conflicto puede ser productivo y sano.

217. Detectar el nivel de conflicto. Para detectarlo necesitas pasar mucho tiempo con el equipo. No es algo científico Escuchar las quejas del equipo Sentir la energía del ambiente Poniendo foco en el lenguaje

218. Nivel 1: Problema para resolver Este nivel es el guay, cuando aparecen problemas los resolvemos rápidamente. El equipo toma el conflicto de manera abierta y constructiva “Ok, te he escuchado pero yo creo que que se te ha olvidado este detalle…” “¡Parad! Ya discutimos esto, ¿Qué nueva información ha aparecido para que lo volvamos a debatir? “Ok, ya veo lo que dices ahora, Ok, yo sigo sin estar de acuerdo contigo porque…”

219. Nivel 2: Desacuerdo En este nivel el equipo se auto-protege. Las personas hablan en individual y no en equipo. No actúan de manera agresiva “Estás haciendo lo mismo que probamos la semana pasada y no funcionó” “Sabías que el equipo de soporte no nos ayudó cuando dijeron que lo harían. ¿Por qué no nos lo dijiste?” “Sí, yo rompí la subida, pero deberíamos de ver los fallos del equipo que son más importantes que una simple subida”

220. Nivel 3: Contienda El ánimo es de vencer, los problemas no se resuelven, aparecen conflictos políticos. Aparecen las generalizaciones “él SIEMPRE se olvida de …”. “Ella siempre evitar las conversaciones” “Hoy viene muy amable. ¿Me querrá pedir algo?” “Ya ni sé por qué estamos peleando. Simplemente no nos llevamos bien”

221. Nivel 4: Cruzada Resolver la situación no será suficiente. Las personas piensan que los demás no van a cambiar. Solo ven como solución sacar a personas del equipo. Se crean facciones la gente se ataca entre ellas en vez de hablar de ideas. “Él está equivocado, así de claro y simple” “Necesitamos a más personas en nuestro lado” “Nosotros estamos en lo correcto”

222. Nivel 5: Guerra No se trata de ganar, se trata de que el otro pierda. Aquí la única solución es separar a los combatientes para que no se hagan daño. “Tenemos que ganar, no hay otra opción” “O nosotros o ellos” “El mundo debe estar prevenido así esto nunca volverá a pasar”

223. ¿Cómo lo arreglamos? Primero… no hagas nada. Los equipos ágiles deben estar entre el nivel 1 y 3 y ser capaces de gestionarse. Analizar y Responder Usar Estructuras Revelación Mejor opción

224. Analizar Realiza las siguientes preguntas ¿Cuál es el nivel de conflicto? ¿Cuáles son los problemas? ¿Cómo responderías como lado A? ¿Cómo responderías como lado B? ¿Que debería hacer? ¿Qué opciones de resolución están abiertos?

225. Buscar la colaboración (win-win), buscar el consenso en las decisiones. Crear un entorno seguro en el equipo para poder resolver los conflictos. Dar soporte, empoderizar al equipo para que resuelvan los problemas. Negociar: hablar con ambas partes para tratar de resolverlos. Accomodar: hacer entender que es más importante la relación que resolver el problema. Establece una estructura de seguridad hasta que el conflicto desescale. Tendrás que usar la diplomacia entre un grupo y otro. Haz lo que haga falta para que no se hagan más daño N5: Guerra N4 : Cruzada N3: Contienda N2: Desacuerdo N1: Problema para Resolver Respuesta

226. Eres el nuevo Scrum Master para un equipo que desarrolla un importante producto para un banco inversor. Cuando llegas a la oficina, descubres al CEO hablando con el Development Team para solicitarles un item urgente que quiere que se haga en el Sprint. ¿Cómo debería reaccionar éste Development Team?

227. Te acaban de asignar como Scrum Master para un nuevo equipo que comenzará pronto. El Product Owner es Mark. Mark comenta el utilizar el Inception pero te pide ayuda porque no sabe cuál debe ser su papel en dicho Inception. Mark propone estudiar la viabilidad económica de todo el proyecto, construir un Product Backlog completo que vayamos a construir o estudiar la capacidad de los recursos que van a participar en cada Sprint para detallar un plan de recursos. ¿Qué papel juega un Product Owner en el Inception?

228. Motivación del equipo: Técnicas de visualización y mejoras

229. Tablero de ideas

230. Cajón de ideas

231. Estado del equipo

232. Niko Calendar

233. Kudos

234. Introducción a Scrum Repaso de expectativas...

Formación Scrum Masters Online alumnos.pptx

You are reading a preview.

Check these out next

Formación Scrum Masters Online alumnos.pptx

More Related Content

Similar to Formación Scrum Masters Online alumnos.pptx (20)

Recently uploaded (20)