Scrum es el marco de trabajo ágil más utilizado en la actualidad. Es al mismo tiempo en muchos casos el punto de partida para equipos que pretenden comenzar a trabajar de forma ágil. A simple vista Scrum parece simple, la guía oficial de Scrum tiene apenas 15 páginas y un curso típico de Scrum ronda las 16 horas.

Sin embargo esta simplicidad aparente en la teoría resulta bastante distinta en la práctica. Que sea fácil de entender no implica que resulte fácil de poner en práctica.

Scrum es un marco de trabajo para gestión y colaboración que puede utilizarse tanto en proyectos de software como también en otro tipo de proyectos. El hecho de que sea un marco de trabajo es lo que permite utilizarlo en contextos muy distintos pero implica al mismo tiempo que al utilizarlo en un escenario concreto es necesario «completar alguno huecos». Algunos de esos «huecos» son muy explícitos pues son simples parámetros, por ejemplo la duración de los sprint. Pero de esos huecos son mucho menos explícitos, por ejemplo la forma en que estimaremos y que forma tendrán nuestros items de backlog. Es así que para un equipo que desarrolla software no alcanza con Scrum en abstracto, es necesario «llenar huecos» con prácticas concretas. Un complemento que ha resultado muy efectivo es utilizar Scrum con Extreme Programming(XP), o sea, «llenar los huecos» de Scrum con las prácticas de XP. XP es una propuesta de trabajo concreta para desarrollo de software y como tal contempla tanto cuestiones de gestión/colaboración como cuestiones de programación/prueba/despliegue, etc.

Pero por otro lado, para un equipo que viene de trabajar en una dinámica desordenada de «code-and-fix» meterse de lleno con Scrum puede resultar demasiado. Pasar de la nada a iteraciones time-boxed, gestionar explícitamente el backlog e incorporar todas las ceremonias de un día para otro, no me parece un apropiado. Es así que para esos escenarios yo suelo proponer una adopción gradual de Scrum y en ese sentido el mi recomendación es comenzar haciendo retrospectivas. La retrospectiva tiene la particularidad de ser una práctica sin dependencias, o sea, uno puede hacer retrospectivas sin utilizar ninguna otra práctica de Scrum. Al mismo tiempo la retrospectiva debería guiarnos en nuestro proceso de mejora. Dicha mejora podría llevarnos a incorporar otras prácticas de Scrum o no, tal vez podríamos terminar incorporando otras prácticas. O sea, tal vez arrancamos con la intención de hacer Scrum pero terminamos haciendo algo distinto. Pero esto no está mal, porque Scrum no debería ser un fin en sí mismo, sino un medio para lograr un fin de nuestro equipo/organización que en términos de Agile es agregar valor.