Un patrón contribuye en dar soluciones a problemas que son recurrentes y un antipatrón es cuando pensamos que la solución planteada al problema es la correcta y en definitiva, resulta siendo un problema que trae consecuencias negativas. 

Un antipatrón en Scrum se refiere a las malas prácticas utilizadas que obstaculizan el progreso hacia la entrega de valor y nos aleja de los beneficios que puede aportarnos Scrum como marco de trabajo.

Algunos de los antipatrones:

• Cuando en la daily participa el integrante más activo del equipo, no permite hablar al resto del equipo.
• Cuando el Product Owner (PO) en una planeación del sprint le cuenta al equipo que un stakeholder necesita una historia de manera prioritaria y la historia no está refinada, no tiene criterios de aceptación.
• Cuando el equipo no cuestiona lo que el PO les comparte y aceptan todo.
• Cuando el PO asigna los puntos de historia y asigna las historias al equipo.
• Iniciar el evento de planeación del sprint cuando el PO no se encuentra en el evento programado.
• Tener un backlog desactualizado.
• Desenfocar al equipo en lo que planeó durante el sprint, por apoyar en temas que no están relacionados con el objetivo del sprint.
• El equipo acepte historias que no cumplen el Definition Of Ready (DoR).
• No respetar el time box de los eventos.
• Poca comunicación del equipo, no esperar hasta el daily del otro día cuando tiene un impedimento.
• Daily como estado de updates.
• No realizar refinamiento de las historias.
• No profundizar en las historias sin tener claridad en la complejidad y las dependencias.
• En una review los equipos de desarrollo muestran resultados solo en una presentación y deben ser resultados prácticos con código funcional que se pueda probar.
• Planeación irreal donde el equipo acepta todo y el Scrum master no interviene.
• Interrupciones continuas durante el sprint perdiendo el foco del equipo.
• Siempre el mismo formato de retrospectiva.
• Poca asistencia al daily.
• Historias muy grandes por parte del PO.
• No existen criterios de aceptación definidos por cada historia.
• Falta de coaching del Scrum master.
• No se define un sprint gol.
• Posponer la retrospectiva porque el equipo está ocupado.
• Equipos que no tengan definido el Definition Of Ready (DoR) o Definition Of Done (DoD).
• Realizar historias que no generen valor.
• No promover los valores o pilares.
• No existe el sprint review, no hay feedback.
• En las daily nunca hay impedimentos, todo parece de maravilla hasta que llega la review y no se cumple.
• Creer que por usar Scrum estamos siendo ágiles, tener presente el mindset (valores, principios, prácticas) siendo importante el ser y el hacer.
• Los PO que aparecen en la planning y vuelven a aparecer en la review de un sprint.
• El equipo relaciona los puntos de historia a horas/esfuerzo.
• Retrospectivas donde no lleva accionables o donde salen mejoras, pero quedan en el papel.
• Sprints que no están regidos por el ritmo del equipo sino por el trabajo que hay que hacer.
• Los PO son los jefes del equipo.
• Llevar un cronograma por sprints.
• Confundir la review con la demo.
• El Scrum master es el nuevo gerente del proyecto.
• Realizar sprints en cascada. Ejemplo: Sprint1 front, sprint2 back y sprint3 pruebas.
• Creer que al aplicar Scrum estamos siendo ágiles.
• Como Scrum master evitar el conflicto hacia el equipo y hacia la organización.