devictoribero / scrum-antipatterns--rituals-es

Rituales de SCRUM🧙. Los anti-patrones o errors más comunes🙅 y consejos de como evitarlos👨‍🏫

🤷 Anti patrones de los Rituales de Scrum

La idea detrás de este repositorio es la de explicar los Rituales de Scrum, los errores más típicos que hace la gente y como evitarlos. Hice una Presentación de Introducción a Agile donde algunas de las parte que expliqué incluyen esto que voy a explicar a continuación. Espero que lo disfrutéis 🤗.

🧙 Rituales de SCRUM

Como dice la Guía Oficial de SCRUM:

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

🏁 Sprint Planning

🗣️ Daily Meeting

📝 Product Backlog Refinement

🎉 Sprint Review

🛡️ Retrospective

🏁 Sprint Planning

En la Sprint planning el Equipo decide cuanto trabajo (Elementos del Product Backlog cononcidos como PBI) va a realizar. Este acuerdo define el Sprint Backlog, que será más o menos exhaustivo en relación a la capacidad y/o velocidad del Equipo como también de la duración del Sprint. En la Sprint Planning responderemos las siguiente preguntas

• ¿Qué se puede entregar como Incremento de Producto para el siguiente Sprint?

Es importante recordar que SOLO el Equipo de Desarrollo puede decidir cuánto trabajo se va a intentar conseguir en el siguiente Sprint.

🙅 Malas Prácticas

• El Equipo no tiene una Definición de Preparado o Definition of Ready
• Te crees que se ha pedido X pero se ha pedido Y
• Fijarse metas poco reales
• No tener el Product Backlog priorizado
• El Product Owner o Propietario de Producto decide cuánto trabajo hacer
• No se notifican las vacations o absencias

👨‍🏫 Consejos

• Establecer una Definición de Preparado o Definition of Ready
• Preguntar tanto como sea necesario para saber todas las especificaciones y detalles de lo que se pide
• Desmenuzar las tareas en otras de más pequeñas. Dicidi e vinci
• Guardar capacidad durante el Sprint actual para ver detalles y especificaciones de las Historias de Usuario del próximo
• Pedir que el Product Backlog esté siempre priorizado
• Ser claros con vuestra capacidad
• Notificar las vacaciones o absencias para que la capacidad del equipo se adapte

🗣️ Daily Meeting

La Daily Meeting es una reunión informal de 15 minutos como máximo, aunque se puede adpaptar para equipos grandes. Para asegurar de que la reunión sea breve, todos los tópicos que empiecen una conversación deberían cortarse al momento y añadidos a "la lista de cosas que después de la Daily aquellas personas que estén involucradas deberán hablar".

Cada Miembro del Equipo deberá responder a las preguntas:

• ¿Qué hice ayer?
• ¿Qué haré hoy?
• ¿Hay algo que me bloquea o me lo impide?

🙅 Malas Prácticas

• Conversaciones que no tienen nada que ver
• Conversacionens técnicas para solucionar problemas
• Detalles de Implementación. (Explicaciones a bajo nivel). Alert!!
• Se reporta al Product Owner
• Cruce de conversaciones
• Monólogos
• Hay gente que no da visiblidad

👨‍🏫 Consejos

• Incentivar a la gente a que interrumpa conversaciones si es necesario
• Cortar las cosas rápido. Romper malos hábitos
• Estar levantados durante la reunión así más facilmente será breve
• ¿Tenemos que hablar de algo? Hagámoslo depués
• Hacer un círculo para combatir el problema de reportes al Product Owner
• Si un Miembro de Equipos se extiende demasiado, usar temporizadores
• Pedir a los compañeros de Equipo que se preparen la Daily Meeting

📝 Refinamiento del Product Backlog

El Refinamiento del Product Backlog, también conocido como Grooming aunque recomiendo no usar este término porque tiene implicaciones negativas, es un método para mantener el Product Backlog actualizado, limpio y ordenado.

Esta reunión es el sitio ideal para clarificar detalles de tareas y hacer que éstas, cumplan la Definición de Preparado o Definition of Ready que el propio equipo decidió.

Una buena práctica es tener el trabajo preparado de los próximos 2 Sprint

🙅 Malas Prácticas

• Las tareas de arriba de todo del Product Backlog tienen estimaciones muy grandes
• Hay tareas sinn estimar
• El Product Backlog contiene elementos desde hace más de 2 meses
• El DEV Team no hace challenge al Product Owner en cuanto cuales pueden ser las Historias de Usuario que más valor dan
• Largos debates en cada Elemento del Product Backlog

👨‍🏫 Consejos

• Utilizar temporizadores para cada historia de usuario.
• Dedicar un máximo de 5 minutos por Historia de Usuario
• Si el debate es sano, dar 3 minutos extras a esa Historia de Usuario
• El Palo de las Preguntas. Usar cualquier objeto y pasarlo entre compañeros. Quien lo tenga, deberá preguntar algo para resolver dudas de esa Historia de Usuario
• Eliminar los Elementos del Product Backlog que lleven más de dos meses en la lista

🎉 Sprint Review

La Revisión del Sprint o Sprint Review se organiza para inspeccionar el Incremento de Producto y adaptar el Product Backlog en caso de ser necesario. Durante la reunión, el Equipo de Scrum o Scrum Team explica a las partes interesadas o Stakeholders que ha sido completado, que no lo ha sido y qué dificultades o impedimentos ha tenido el Equipo y cómo los ha superado en caso de haberlo hecho.

🙅 Malas Prácticas

• Product Owner egoísta. Se refiere como 'yo'en vez de 'nosotros'
• Engaños. Se muestra software que no está terminado o tiene errores
• El Equipo no explica las dificultades encontradas
• La reunión se trata como una DEMO
• Sólo el Product Owner presenta todos los resultados, nadie más del equipo habla

👨‍🏫 Consejos

• Cada Miembro del Equipo debe presentar sus User Stories
• Todo el mundo debería explicar sus dificultades
• User temporizadores para no pasaros del tiempo
• El Equipo debería únicamente presentar el software que funciona

🛡️ Retrospective

La Retrospectiva o Retrospective es una oportunidad para el Equipo de inspeccionarse y crear planes de mejora con las acciones que hayan salido de esta reunión. El objetivo de la Retrospectiva es discutir qué fue bien, qué podría ser mejorado y a qué se compromete el Equipo a mejorar durante el siguiente Sprint

🙅 Malas Prácticas

• Tomarse los comentarios o las críticas como algo personal
• Un Miembro del Equipo explica a alguien fuera de éste, lo que se comenta en las retrospectivas. Esto impide crear un vínculo de confianza
• Las acciones no tienen un responsable/propietario al final de la Retrospectiva
• Jefes o gente fuera del equipo asiste a la Retrospectiva
• El Equipo no revisa acciones pasadas
• Las conversaciones están dominadas por una o dos personas

👨‍🏫 Consejos

• Tomarse la Retrospectiva seriamente
• Ser honesto con tus compañeros de Equipo. Todo el mundo debería entender que la reunión sirve para mejorar
• Anima la gente a participar. Haz que todo el mundo hable y de una opinión constructiva
• Si no se comentan tópicas para mejorar como equipo, pregunta individualmente: ¿Que te ayudaría a ir más rápido? ¿Que no te gusta?
• Materializa las opiniones en papeles o una pizarra para hacerlas más obvias
• Hacer la técnica de la Votación del Punto para decidir las acciones del siguiente Sprint
• Asignar responsables o propietarios a estas acciones