Tomo tu idea, trataré de ir animando a la gente a que haga tareas que no son especialemente suyas, para que todos aprendan de todos.

Por cierto, tengo pendiente un post sobre el segundo grupo de scrum (el de un solo proyecto, con dos miembros “in situ” y un tercero teletrabajando) y sprints de quince días (ya hemos terminado el primero y vamos a casi a mitad del segundo). Ahí la cosa es más sencilla, aunque sigue habiendo problemas similares.

Gracias y se bueno.

Dicho esto, estoy muy de acuerdo con todo tu análisis, pero me gustaría aportarte una sugerencia por si te encajara. Se trata de esa tendencia natural de los desarrolladores a acomodarse en sus “silos” de conocimiento en los que se han ido acomodando a lo largo de los años. Creo que como scrummaster podrías “empujarlos” (sin violencia pero con firmeza) a que trabajaran por parejas casi siempre, en vez de a veces. De esta manera pagaréis a corto plazo con un posible descenso de productividad pero a medio plazo ganaréis con una mayor polivalencia de todos. Además de retar a los desarrolladores a salir de sus “círculos de confort”, pero no demasiado. Esto último es importante porque las personas crecemos profesionalmente cuando nos empujan a hacer cosas diferentes, aunque siempre puede haber reticencias a salir de nuestros entornos conocidos y el scrummaster debe tener cuidado con no exponer demasiado bruscamente a la gente más aversa a los cambios. Pero por el bien del equipo, todos deben ir adquiriendo nuevas habilidades.

Fíjate que, sin embargo, este problema no es muy grave porque justamente comentas que ellos ya van haciendo trabajo por parejas poco a poco. Yo creo que hay que tener paciencia pero también creo que hay que ayudar a que las buenas prácticas ocurran, no siempre esperar a que devengan de manera natural.

Este “romper fronteras” que te propongo serviría además para reducir ese problema que comentas en el daily scrum. Lo que sí me gustaría resaltar es que justamente el daily scrum ha servido para poner de manifiesto este problema de “aislamiento” aunque no sea expresado con palabras. Es una de las ventajas que no se tiene usando métodos tradicionales de gestión de proyectos. (Además de los que tú ya comentas, claro)

Enhorabuena porque es evidente que estáis haciendo un buen trabajo. Nunca nadie dijo que hacer Scrum sea fácil (sólo es fácil de explicar) puesto que, como cualquier metodología, requiere mucha disciplina: quizás más que el resto de metodologías puesto que delega la responsabilidad de controlar el proyecto en todo el equipo y todos los días, en vez de en una persona (el jefe de proyecto) y sólo en ciertos hitos.