anti patrones Scrum
¿Qué es un patrón?
“Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno y luego describe el núcleo de la solución a ese problema; de tal manera que puedes usar esta solución un millón de veces, sin hacerlo dos veces de la misma manera”.
📖 Christopher Alexander, Un lenguaje de patrones (A Pattern Language).
¿Qué es un antipatrón?
Los antipatrones ocurren cuando creemos que la solución que estamos planteando al problema parece ser la correcta y la más fácil de implementar, pero termina siendo un problema o causando más problemas de los que soluciona. Los antipatrones se ocultan dentro de las buenas prácticas y parecen parte del sistema.
Los antipatrones de #Scrum describen cualquier solución atractiva y fácil de implementar que, en última instancia, empeora un problema.
Por lo tanto, estas son las prácticas que no se deben seguir para evitar que surjan problemas.
Algunos ejemplos clásicos de antipatrones de scrum
- Propietarios de productos ausentes: Los propietarios de productos no participaron activamente durante el sprint, lo que provocó malentendidos y retrasos en la toma de decisiones.
- Pre-asignación de tareas: Asignar tareas individualmente dificulta la colaboración y crecimiento; Las tareas deben determinarse en colaboración.
- Minimizar las retrospectivas: Ignorar o socavar las reuniones retrospectivas lleva a perder oportunidades de mejora.
- Falta de participación activa: Los miembros del equipo no participan activamente en las discusiones y la toma de decisiones, lo que limita la colaboración.
- Reuniones retrospectivas ineficaces: Seguir un formato estandarizado en retrospectivas sin discusiones significativas.
- Ignorar la mejora continua: No implementar mejoras basadas en comentarios y conocimientos de retrospectivas.
- Sprints sobrecargados: Intentar incluir demasiado trabajo en un sprint, comprometer la calidad y estresar al equipo.
- Falta de empoderamiento: No permitir que los miembros del equipo tomen decisiones y se apropien, lo que reduce la motivación.
- Microgestión: Controlar demasiado las tareas sofoca la creatividad y la autonomía, contrarrestando los principios ágiles.
- Ignorar los principios ágiles: No cumplir con valores ágiles como la autoorganización y la colaboración con el cliente disminuye la eficacia.
Puntos clave:
- Los antipatrones de Scrum parecen soluciones fáciles pero perjudican los principios ágiles y a la empresa crecimiento.
- Todos los miembros del equipo, incluidos los propietarios de productos y Scrum Masters, pueden exhibir un comportamiento antipatrón.
- Ejemplos de antipatrones incluyen propietarios de productos ausentes, tickets preasignados y retrospectivas descuidadas.
anti patrones Scrum Máster
Algunos anti patrones de un Scrum Master que pueden no ayudar a ser un líder servicial.
Un Scrum Máster que le dice al equipo de desarrollo y al Product Owner que según alguna experiencia cada miembro del equipo de desarrollo solo puede desarrollar como máximo hasta una capacidad de X puntos de historia por Sprint, este tipo de Scrum Master también aclara que intentar que el equipo haga más puntos de historia implicaría exceder la capacidad promedio de los desarrolladores.
La realidad: En Scrum lo que importa es la entrega de valor y el impacto en los clientes. La velocidad en puntos de historia no representa una métrica que refleje la entrega de valor. La velocidad en puntos de historia no representa una predicción del futuro y tampoco representa la capacidad de lo que los desarrolladores pueden entregar en cada Sprint.
- Un Scrum Máster que dirige el Daily Scrumy establece que cada desarrollador debe seguir las tres preguntas como son, que tareas hizo ayer, que tareas va a hacer el día de hoy y que impedimentos tiene para culminar sus tareas. En este evento el Scrum Master enfatiza a ese desarrollador que tiene que cumplir con las tareas que se ha comprometido porque si no no tiene compromiso.
La realidad: Los valores de Scrum fomentan un entorno cultural que fomenta el empoderamiento y la creatividad. El Scrum Master no es el policía de Scrum ni tampoco existen preguntas obligatorias que se deben seguir.
- Un Scrum Master que cee proteger a los desarrolladores estableciendo que como están sumamente ocupados no hay tiempo para interrumpirlos y por ello el Product Owner tiene que entregar los requerimientos refinados y listos para que los desarrolladores lo estimen. Además, este Scrum Master establece que no se debe interrumpir a los desarrollaores con actividades de refinamiento porque esa es labor del Product Owner.
La realidad: La colaboración y cocreación son importantes para mejorar y fomentar la transparencia, el refinamiento es una actividad que debe ser abordada como un trabajo de equipo.
- Un Scrum Master que enfatiza al Product Owner y al equipo de desarrollo que si el equipo ha venido produciendo X puntos de historia de velocidad entonces no pueden hacer más puntos de historia o en última instancia podrían aumentar ligeramente los puntos de historia, pero en ningún caso se debe presionar al equipo porque podrían sentirse mal. En un entorno empírico se planifica para lo impredecible.
La realidad: La velocidad en puntos de historia no es una métrica que mide la productividad del equipo ni tampoco el objetivo a lograr.
- Un Scrum Master que establece con claridad que es responsabilidad del Product Owner ingresar todas las historias de usuario y criterios de aceptación en la herramienta X, también que el Product Owner tiene que dar todo el detalle necesario porque los desarrolladores solo harán aquello que el Product Owner les dice que haga, además si el Product Owner omite algo será de responsabilidad única y exclusiva del Product Owner.
La realidad: La responsabilidad del Product Owner es maximizar la entrega de valor y el aporte a la entrega de valor es todo el equipo Scrum, todos son responsables de colaborar para realizar todas las actividades en el desarrollo de producto.
- Un Scrum Máster que le dice al Product Owner que la única reunión donde se va a inspeccionar el incremento de producto es en el “Sprint Review” por ello debe tener paciencia y esperar a esa reunión. Antes de eso los desarrolladores no pueden entregar incrementos porque tiene que terminarse el tiempo del Sprint según lo establece Scrum.
La realidad: La inspección y adaptación es continua durante el Sprint y no solamente al final del Sprint Review.
- Un Scrum Máster que mapea los puntos de historia a horas. De esta manera obtiene un plan detallado de horas que todos pueden seguir para monitorear el avance.
La realidad: Scrum se basa en el empirismo, la adaptación ocurre en cualquier momento, los planes se adaptan según se requiera y el avance hacia el objetivo del Sprint se consigue a través del incremento de producto terminado con valor. El empirismo se basa en aceptar los cambios y no en tratar de controlarlos o limitarlos.
anti patrones Product Owner
➡️ Un #ProductOwner que no transmite la visión del Producto a los desarrolladores, solamente le entrega historias de usuario a desarrollar, convirtiendo a los Desarrolladores en tomadores de pedidos. 🤯😠Esto no fomenta la transparencia lo cual hace más difícil crear el Sprint Goal y darles un propósito.
➡️ Un Product Owner que ordena a los Desarrolladores lo que tienen que desarrollar en cada Sprint y que además les impone 🤯😠 el Sprint Goal atentando contra la autoorganización.
➡️ Un Product Owner que cancela el “Sprint Review” para evitar que la organización no conozca lo que no se ha terminado o realiza un “Sprint Demo” con un incremento que no está completamente terminado. Este Product Owner evita que el progreso del incremento del producto sea transparente🤯😠.
➡️ Un Product Owner que no involucra a los Desarrolladores 🤯😠en el refinamiento del Product Backlog durante el Sprint. Este tipo de comportamiento hace que el Product Backlog no sea transparente e ignora el punto de vista que pueden aportar los Desarrolladores.
➡️ Un Product Owner que no favorece la calidad del producto 🤯😠debido a que no participa de la definición de los criterios de terminado dejando que el equipo los defina. Este Product Owner luego exige que el equipo cumpla con entregar los Product Backlog Itens comprometidos durante el Sprint Planning aun cuando eso significa sacrificar calidad y no usar los criterios de terminado. Este escenario puede generar deuda técnica que reduce la entrega de valor.
➡️ Un Product Owner que participa del Daily Scrum para controlar🤯😠 las tareas que han hecho y tienen que hacer los Desarrolladores. Esto lleva a limitar la creatividad, reducir el foco hacia el Sprint Goal y la entrega de valor, evitando además promover soluciones a los impedimentos.
➡️ Un Product Owner que cree que su mayor responsabilidad es registrar en alguna herramienta las historias de usuario y los criterios de aceptación para luego entregar la documentación y el alcance definido a los Desarrolladores para que lo implementen🤯😠. ¿𝐐𝐮𝐞́ 𝐩𝐚𝐬𝐚 𝐞𝐧𝐭𝐨𝐧𝐜𝐞𝐬 𝐬𝐢 𝐞𝐥 𝐏𝐫𝐨𝐝𝐮𝐜𝐭 𝐎𝐰𝐧𝐞𝐫 𝐧𝐨 𝐡𝐚𝐜𝐞 𝐬𝐮 𝐭𝐫𝐚𝐛𝐚𝐣𝐨?😉💡🚀
➡️ El peligro es la pérdida del trabajo en equipo para elaborar el Product Backlog, también se puede perder la visión del producto, contacto con el mercado, clientes y el contexto de negocio que ayuda a la inspección y adaptación para mejorar la entrega de valor en #Scrum.
Creer que por usar SCRUM estamos siendo ágiles
Constantemente me encuentro esto, las organizaciones llevan varios años haciendo scrum y por consiguiente creen que están siendo ágiles; sin embargo, siguen teniendo las mismas prácticas tradicionales.
Para hacer la transición es necesario reforzar el “mindset ágil”, volver a las raíces, al manifiesto ágil, abrazar los 4 valores y los 12 principios.
La agilidad la podemos visualizar como una sombrilla bajo la cual están las prácticas y los marcos de trabajo. Si solo hacemos las prácticas (hay muchas) y no lo hacemos alineados con los valores y los principios tendremos un fake-agile
SCRUM nos permite terminar los proyectos/productos antes
¿Usamos SCRUM para poder terminar más rápido? Muchas empresas lo asumen así, pero la verdad es que SCRUM nos permite fallar más rápido, evaluar más rápido, cambiar nuestro rumbo más rápido, abandonar más rápido, generar valor más rápido para todo lo anterior.
Pero, si no se genera este valor y lo sometemos a revisión, pruebas y escrutinio de nuestros clientes, no va a servir para nada.
🚀💡 ¿Quieres aprender SCRUM ?
Consulta nuestras formaciones posibilidad individual o formato inCompany profesional en Organizaciones bonificando por FUNDAE.
Etiqueta:SCRUM
