Scrum es un framework fácil de entender y difícil de dominar. Scrum no intenta ser una herramienta para solucionar todos los problemas, no es tampoco una receta completa que prescribe paso a paso lo que se debe hacer. Scrum brinda límites para fomentar la auto organización, estos límites protegen a las personas para crear un ambiente saludable para crecer en la colaboración y el trabajo en equipo usando un entorno empírico.
En un entorno empírico se acepta la incertidumbre, se planifica pensando que las cosas pueden cambiar. Por ejemplo, cuando el equipo de desarrollo se compromete a una cantidad de Product Backlog Items (PBIs) a ser terminados en el Sprint pero durante el desarrollo del Sprint descubren nuevas dependencias o algún evento de negocio provoca que el Product Owner necesita agregar un nuevo PBI durante el Sprint puede provocar que no necesariamente todo lo comprometido al inicio del Sprint se pueda terminar.
Scrum implementa “feedback loops” predefinidos para proveer límites y gestionar un proceso empírico a través de la inspección y adaptación. Si bien estos ciclos de retro alimentación son definidos es ideal que cada equipo de desarrollo viva su auto organización hacia el objetivo creando sus propios ciclos de retro alimentación que le permitan mejorar su inspección y adaptación. Por ejemplo, estos ciclos pueden ser ampliados cuando el equipo colabora continuamente con el Product Owner y clientes recibiendo “feedback” acerca del incremento de producto durante el Sprint y no solamente al final del Sprint, otro ejemplo es cuando se realizan despliegues continuos durante el Sprint y no solamente al final del Sprint, estos despliegues permiten inspeccionar el progreso hacia el objetivo del Sprint. Estos ciclos pueden ser ampliados y potenciados por un equipo auto organizado que define la mejor manera de vivir su autoorganización y de lograr el objetivo del Sprint.
Un ejemplo de los ciclos de retro alimentación prescritos en Scrum es el Sprint Review, este evento ayudar a generar transparencia acerca del progreso hacia el objetivo de negocio y fomentar la colaboración entre el equipo Scrum y los interesados creando limites naturales para crecer en un entorno de colaboración reduciendo los enfoques de control. Cuando los interesados no asisten a este evento el riesgo de que soliciten informes de avance o reportes de actividades para controlar crece debido a su falta de involucramiento reduciendo además la actitud de colaboración y facilitación hacia el equipo. Este límite es fundamental para fomentar la colaboración y el involucramiento creando el entorno de trabajo en equipo más allá del equipo Scrum.
Los eventos de Scrum no son ceremonias que el equipo debe hacer porque Scrum lo dice, son oportunidades para fomentar la conversación y colaboración. Los eventos no deben ser tomados como imposiciones de acciones a realizar sino como momentos que dan la oportunidad inspeccionar y adaptar. El Scrum Master debería explicar el objetivo de cada evento. Si un miembro del equipo no asiste por ejemplo a un Daily Scrum, probablemente pueda ser porque no le ve valor a asistir y no entiende los beneficios de la transparencia y la sincronización del trabajo como equipo.