Una de Scrum

Me encanta Scrum. Me parece elegante en su simplicidad, pero que nadie se lleve a engaños, es un framework muy poderoso siempre que se respeten a rajatabla sus reglas. En este sentido, ocurre como decía el ScrumMaster Miyagi:

Tu Scrum “sí”…Vale. Tu Scrum “no”…Vale. Tu Scrum “supongo”, tarde o temprano…¡Chof! Aplastado como uva.”

Supongo que eso fue lo que le ocurrió a Chuidiang en su fallido intento por implementar Scrum. Tal como comenta Rodrigo Corral en el más que recomendable blog sobre programación “La masa, el ladrillo, la bota, el bocadillo…“, nadie dijo que Scrum no requiriese un esfuerzo. Y es que uno lee cosas como Scrum en cinco minutos o explicando Scrum a mi abuela y parece que esto es coser y cantar, pero no se debe confundir simplicidad con inmediatez: si uno se aventura por las aguas de Scrum sin contar primero con la experiencia necesaria en gestión de proyectos se puede acabar convirtiendo en el Scrum Master Jar Jar Binks (lectura MUY recomendada a la que llegué vía Navegápolis, igualmente recomendable).

Y no quiero decir que los documentos anteriores no sean estupendos (yo los tengo guardados y los uso). Pero no es lo mismo leer un artículo sobre física cuántica que ponerse a acelerar partículas al frente del CERN. En este sentido, a los que queráis profundizar en el uso y ventajas de Scrum os recomiendo fundamentalmente dos lecturas (aunque posiblemente no descubra nada a los que ya estáis metidos en el ajo): Agile Project Management With Scrum de Microsoft Press es el clásico, y tiene una definición muy concisa de los procesos y reglas de Scrum. No obstante, la parte relativa a las anécdotas y experiencias implementando Scrum es un poco oscura para mi gusto, quedándose en la superficie del proceso y no entrando en los detalles del día a día. En ese sentido es muchísimo más revelador el documento Scrum and XP from the trenches que, además, podéis descargar grauitamente.

Este último es sin duda magnífico, ya que está imbuido de la misma simplicidad que destila Scrum pero además te muestra al detalle cómo implementaron Scrum en una organización real, justificando cada una de las decisiones. Por ejemplo, comentan que sus Sprint duran tres semanas, y explica que es la longitud óptima a la que llegaron después de hacer varias pruebas, en las que comprobaron que si los sprint eran muy cortos, como prefieren los dueños de producto, se conseguían más entregas, más ciclos de realimentación pero también un mayor costo en términos de gestión (más reuniones de sprint, más documentación). En cambio, si los sprints eran muy largos, como prefieren los desarrolladores, había más tiempo para desarrollar, documentar y probar, además de tener menor carga de gestión, pero a cambio los desarrollos eran menos ágiles. Al final, comentan, la longitud del Sprint es un compromiso entre desarrolladores y dueño del producto, y ellos llegaron al compromiso de las tres semanas. Finalmente recomienda que, una vez escogida una longitud de Sprint, esta se mantenga inalterable para todos los equipos, de forma que se vaya formando a los mismos y acostumbrándolos a trabajar en esos plazos. Así es más fácil estimar qué se puede hacer en el Sprint y qué se saldría de las capacidades reales del equipo.

Bien, eso es gestión de proyectos en estado puro. Es incluso más, entra en el ámbito de la cultura corporativa y la madurez de las organizaciones en la gestión de proyectos. Y todo ello sin complejas fórmulas, tremendas herramientas ni farragosas burocracias. Además está mucho más justificado que el “los sprints duran 30 días y uno debe mantener el plazo” del libro de Microsoft. A lo largo del libro explican desde “trucos” para gestionar las reuniones de sprint hasta los campos que debería tener una lista de tareas de sprint o de producto, pasando por cómo mantener un “cuadro de mandos” físico del proyecto y como interpretarlo a simple vista. Genial.

Otra cosa que me encanta de este último documento es el uso que hacen de los paneles en las paredes, las tarjetas adhesivas y las pizarras. A lo largo de mi experiencia como gestor de proyectos, he encontrado que una pizarra en blanco y un taco de post-its son de las herramientas más poderosas con las que uno puede contar, y no estoy exagerando. Lo que pasa es que, y de nuevo entroncamos con Scrum, su elegante simplicidad hace que muchos no se las tomen en serio y piensen que uno está jugando a los consultores y perdiendo el tiempo cuando encierra al equipo a cal y canto y entre todos se dedican a pegar post-its por todas las paredes como si quisieran cambiar la decoración del edificio.

En cualquier caso, ¿Está Scrum orientado sólo a los desarrollos de software? ¿Podría usarse Scrum como método de productividad personal, en una especie de “Scrum de a uno“? ¿Son equivalentes el perfil de ScrumMaster y el del ProjectManager? ¿Merece la pena la certificación ScrumMaster? Creo que son preguntas interesantes a las que iré dedicando algo de tiempo en el futuro.