Llevamos aproximadamente tres sprints de una semana con el grupo de tres desarrolladores que participan en seis proyectos simultáneamente. La verdad es que scrum se aprende en diez minutos, pero me da la impresión de que se puede tardar toda una vida en aplicarlo correctamente.
Nuestro primer sprint fue más o menos bien, seguimos casi todo lo de Scrum a rajatabla y hasta donde pudimos, pero sprint tras sprint, la cosa se va convirtiendo en rutina y las prácticas de Scrum se van relajando. Aquí van los problemillas que vamos teniendo y los porqués.
Uno de los problemas gordos es la tendencia de los programadores a coger las tareas/historias de usuario de los proyectos en los que tradicionalmente están asignados, o de las funcionalidades que tradicionalmente conocen mejor. Esto no es demasiado grave, pero tiene dos pegas importantes:
- Los daily scrum son más un cotilleo que un intercambio de información útil. Cada uno trabaja en lo suyo y cuenta a los demás qué está haciendo, pero a los demás realmente no les afecta. Escuchan por cortesía o por curiosidad, pero no va más allá de eso.
- El que termina su historia de usuario de su proyecto/funcionalidad, tiende a coger otra tarea de su proyecto/funcionalidad que no está planificada. Podría coger alguna de las de los demás, pero el cambio de contexto es muy fuerte: debe actualizar de CVS el otro proyecto, ponerse al día e implementar algo que no conoce. Al ser los sprint tan cortos, de una semana, esto suele suceder el Miércoles o el Jueves, por lo que para un día no le merece la pena ese cambio de contexto.
Sí, es cierto que no deberían tener un proyecto/funcionalidad asignada (y de hecho no lo tienen, pueden coger libremente lo que quieran), pero la inercia de años de trabajo es muy grande para cambiarla en unas pocas semanas. Supongo que no se conseguirá plenamente hasta que se vayan cerrando los proyectos actuales y se comiencen los nuevos.
Otro problema gordo es la corta duración de los sprint. Elegimos esa duración para poder cambiar de semana en semana de un proyecto a otro (recordad, tres desarrolladores, seis proyectos), para poder atender sus necesidades y que ninguno se sienta desatendido mucho tiempo. Haciendo sprints de una semana, podemos decirle a un jefe de proyecto…. "¿puedes esperar a que hagamos eso que nos pides la semana que viene?" y no suele haber pegas. Si le dices, "¿puedes esperar un mes?", pondrá el grito en el cielo.
Pero los sprint tan cortos tienen la pega de organizar demos para ver muy poca funcionalidad implementada. Si para cada semana cogemos un par de proyectos y un par de historias por proyecto y no acabamos alguna de las historias… queda un demo muy pobre. Así que la demo del segundo sprint no la hicimos (había poca funcionalidad nueva que enseñar, ya que casi todo fue un paquete de corrección de bugs).
Con este grupo concreto estoy pensando en algo como Kanban. Por lo que he leido, viene a ser como Scrum, pero sin los sprint fijos cada cierto tiempo. Se hacen las historias de usuario, se sigue llevando el juego de post-it y se van acabando por prioridades, midiendo tiempos. La diferencia es que no hay sprint fijo, por lo que las historias tampoco son fijas. Se pueden ir cogiendo historias sobre la marcha y desarrollándolas, dejando la demo para cuando se considere adecuado. La única limitación es que no puede haber simultáneamente más de X historias haciéndose, más de Y tareas haciéndose, etc.
En cualquier caso, independientemente de lo bien o mal que hagamos Scrum, sí se han notado mejoras muy importantes en el trabajo y paso a enumerar algunas.
- Por un lado, yo, como responsable oficial del grupo y gracias al daily scrum, estoy muchísimo más al tanto de lo que están haciendo en cada momento. Eso hace que no me desespere tanto cuando las cosas parece que tardan, ya que vivo los problemas día a día y sé los motivos de la tardanza. Y también hace que yo curre más, ya que al ser consciente de esos problemas, intento solucionarlos lo antes posible…. ¡¡ Incluso me he puesto a codificar más en serio !!. Antes también codificaba algo, pero picoteando de aquí y de allí, en lo que más me apetecía en cada momento. Ahora lo hago centrado en ayudar a alguien con lo suyo y conseguir que una historia de usuario se termine.
- Por otro lado, aunque cada desarrollador tiende a lo suyo, es consciente de las tareas y problemas de los demás, por lo que siempre tienden más a ayudarse por iniciativa propia. Antes la ayuda se daba sólo si alguien te la pedía y según el momento de la petición, podía ser molesto. Ahora se ofrecen voluntariamente para ayudar, más que nada, porque son conscientes de que pueden ayudar si a ellos les cuesta menos realizar esa tarea.
- Los proyectos van avanzando y hay más visibilidad de ello. Todos somos conscientes de las historias que se van terminando y sabemos qué cosas están o no hechas en cada proyecto y hasta qué punto están hechas. Antes alguien cogía una funcionalidad, se ponía a implementarla y un par de meses después decía "ya tá". Y estaba o no estaba, según lo hábil que fuera ese desarrollador concreto desarrollando y probando. Ahora sabemos día a día qué cosas están y si están bien o todavía con fallos.
Resumiendo, Scrum se aprende en cinco minutos, es muy difícil de hacer correctamente, pero se obtienen importantes beneficios incluso no haciéndolo bien al 100%. Hay más sensación de equipo y la gente trabaja más centrada en unos objetivos concretos.
Hola, te sigo con mucho interés porque creo que esta experiencia de «libro de bitácora» de la introducción de Scrum en vuestro proceso de desarrollo seguro que es de mucho interés para la comunidad agilista en español. Seguro que ayuda a muchos a evitar errores gracias a tus reflexiones en público.
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.
@Beas. Gracias por los ánimos. Como comento en el post, si veo bastantes ventajas frente a cómo lo hacíamos antes (cada uno a su bola). Seguiremos haciéndolo y espero que la cosa vaya mejorando poco a poco, pero sí veo que es duro el camino.
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.
También estoy empezando con SCRUM y tu primer comentario sobre el daily scrum (el del cotilleo) le entra como anillo al dedo a nosotros. Por otro lado tus otros problemas te recomendaría que probaras con sprints de 2 semanas con un backlog ordenado por prioridad y en donde las tareas/historias de los 6 proyectos estén todas juntas y mezcladas, de esta manera le asignas trabajo a los programadores por orden de prioridad aunque signifique cambiar de un proyecto a otro.