He leído «Scrum y XP desde las trincheras»

Aprovechando el eBook que me han traído los reyes estoy leyendo mucho últimamente, en el tren y en las cafeterías (sí, soy el friky ese que se sienta solo en una esquina y esconde las narices en el libro, aunque no tengo muy claro si esa expresión aplica a un eBook). Ahora le ha tocado el turno a "Scrum y XP desde las trincheras", de Henrik Kniber.

El libro no cuenta Scrum, por lo que no es el adecuado si quieres aprender qué es Scrum. De XP habla más bien poco o nada (creo que menciona la programación en parejas en un par de ocasiones, poco más). Entonces, ¿de qué va el libro?

El autor trabaja con grupos de desarrolladores que aplican Scrum y como la teoría nunca es tan bonita como la pintan, aplicar Scrum tiene un montón de problemas o cosas que no están muy claras cómo resolver. El autor nos va contando los problemas que ellos han encontrado, soluciones que han probado, soluciones que han adoptado y qué problemas todavía no saben resolver. Es un libro adecuado para aquellos equipos que saben qué es Scrum y lo están aplicando desde hace poco y se van encontrando con los problemas típicos de aplicar Scrum. Este libro le ofrece un abanico de soluciones posibles y cuáles le han funcionado al autor y cuales no.

Algunos problemas típicos:

¿Qué hacer cuando alguien del equipo se queda sin tarea dentro del Sprint?. Entre las soluciones del autor está el dejarle que él mismo elija cualquier cosa que pueda hacer para ayudar al equipo (test, pruebas, documentación, scripts que automaticen tareas, lo que sea). Y si sigue sin encontrar nada para hacer, entonces convertirlo en "recadero" de los miembros del equipo, una forma de ayudar es traerles café, por ejemplo.

¿Qué hacer cuando el código o lo que sea necesita tiempo para ser arreglado y no para producir historias válidas de  un Sprint?. El autor propone varias cosas, pero parece que opta por bajar el factor de rendimiento del equipo lo suficiente como para que puedan abordar estas tareas de mejora, es decir, aceptan menos historias en el Sprint.

¿Qué hacer si el proyecto es grande y necesita muchos desarrolladores?. El autor dice haber probado con un equipo de Scrum grande y con varios más pequeños. Al final la solución buena según él es hacer equipos pequeños (de entre 3 y 10 desarrolladores).

Y si hay varios equipos Scrum en el mismo proyecto, ¿cada uno a su bola? ¿Sprint sincronizados? ¿Un sólo dueño de producto o uno por equipo?. Entre las soluciones del autor, parece que opta por un sólo dueño de producto, Sprint sincronizados de forma que la demos sean el mismo día, la planificación también pero solo par repartir las historias entre los equipos, luego cada equipo hace su planning poker. Las reuniones diarias deben hacerse a diferentes horas, de forma que el jefe de producto pueda acudir a todas reuniones de todos los equipos si quiere, etc, etc. Otra ventaja de esto es que al terminar cada Sprint se pueden intercambiar miembros entre los equipos, partir un equipo más grande en otros más pequeños o juntar dos equipos en uno.

¿Y qué hacemos con los que llegan tarde a la reunión diaria?. Elegir una hora buena para todos y si los tardones son habituales, lo típico de echar una moneda a un fondo común o traer "bollitos" para todos.

¿Y si el equipo está distribuido geográficamente?. Messenger abierto todo el día, web cams, etc, etc y todo lo posible para facilitar la comunicación. Habla incluso de poner web cams permanentes, de forma que todos puedan verse a todos en cualquier momento.

En fin, lo dicho, todo un abanico de problemas y posibles soluciones. El libro es ameno de leer y no se hace en absoluto pesado.