Introducción

Vas a comenzar a usar Scrum en tu organización. O quizás has estado usando Scrum por unos meses. Conocer los principios básicos, has leído los libros, quizás incluso has conseguido tu Certificado de Scrum Master. ¡Enhorabuena!

Pero aun así te sientes confuso.

En palabras de Ken Schwaber, Scrum no es una metodología, es un marco de trabajo. Eso quiere decir que Scrum no te va a decir exactamente lo que debes hacer. Vaya.

Las buenas noticias son que te voy a decir exactamente como empleo Scrum, con una cantidad terriblemente dolorosa de detalles. Las malas noticias son que, bueno, esto es sólo como empleo Scrum yo. No significa que tú debas hacerlo exactamente de la misma forma. De hecho, probablemente yo mismo haga las cosas de una manera diferente si me encuentro en una situación diferente. La fuerza y lo duro de Scrum es que estás obligado a adaptarlo a tu situación específica.

Mi aproximación actual a Scrum es el resultado de un año de experimentación con un equipo de desarrollo de aproximadamente 40 personas. La empresa estaba en una situación dura, con muchas horas extra, problemas de calidad severos, apagando fuegos constantemente, incumplimientos de fechas… La empresa había decidido usar Scrum pero realmente no había completado la implementación, lo cual sería mi tarea. Para la mayor parte de la gente en los equipos de desarrollo, “Scrum” era simplemente un palabro de moda que se escuchaba por los pasillos de cuando en cuando, sin ninguna implicación para su trabajo diario.

A lo largo de un año, implementamos Scrum en todos los niveles de la empresa, probamos diferentes tamaños para los equipos (3 a 12 personas), diferentes duraciones de Sprint (2 a 6 semanas), diferentes maneras de definir “terminado”, diferentes formatos para las Pilas de Producto y Pilas de Sprint (Excel, Jira, tarjetas), diferentes estrategias de pruebas, diferentes maneras de hacer las demostraciones, diferentes maneras de sincronizar múltiples equipos Scrum, etcétera. También experimentamos con prácticas XP: diferentes formas de hacer construcción continua, programación por parejas, desarrollo orientado a test, etcétera, y como combinar estas prácticas con Scrum.

Este es un proceso de aprendizaje continuo, así que la historia no acaba aquí. Estoy convencido de que esta empresa seguirá aprendiendo (si se siguen haciendo las Retrospectivas de Sprint) y adoptando nuevas perspectivas sobre las mejores formas de implementar Scrum en su contexto particular.