Una de las características principales de Scrum es el concepto de sprint. De todas las historias pendientes (Product backlog) el equipo escoge hasta dónde va a poder desarrollar en el siguiente sprint (normalmente 2 o 3 semanas) y se compromete a tener todo eso listo para enseñarlo en una demo al final de ese tiempo. Trabajando así, el equipo sabe exactamente qué se espera de él y se auto-organizará, sin interferencias externas ni cambios de planes, para conseguir su objetivo. Lamentablemente, hay algunas tareas que no se pueden planificar, ni siquiera con tan poca antelación. ¿Qué podemos hacer al respecto?
Qué son las tareas de soporte
Todos hacemos software de gran calidad, tenemos compilaciones y testeos automatizados, ejércitos de testers, etc. 😉 Pero siempre va a haber bugs en historias finalizadas. Al menos yo no conozco a nadie que haya sido capaz de evitar este problema. Corregir bugs es un trabajo difícilmente planificable, a pesar de poder hacer estimaciones basándose en la experiencia previa: ¿Qué pasó la última vez que se implementó tanta nueva funcionalidad? ¿Hay nuevos entornos en pre o producción? Pero estas estimaciones no son fiables. Y no tienen en cuenta la inmediatez con la que muchas veces estos problemas requieren ser resueltos.
También está el soporte a usuarios. En cualquier momento a un usuario de tu aplicación, o a un programador que utiliza la fantástica librería que estáis desarrollando, le puede surgir un problema que le bloquea a él y a otros tantos. En esa situación la persona afectada no puede esperar a que tengas un rato libre para ayudarle, lo necesita YA.
Además, según la naturaleza del software desarrollado puede haber otras necesidades que, si bien son previsibles, son de naturaleza muy distinta al desarrollo de las historias del backlog y pueden romper la motivación y el flow de los miembros del equipo. Por ejemplo, dar soporte a la puesta en producción de un proyecto que se ha desarrollado con nuestro producto.
Por qué rompen las planificaciones: imprevisibilidad, invisibilidad, cambios de contexto, diferente naturaleza
Estas tareas son por definición imprevisibles. Se puede jugar a prever la carga que supondrán, pero va a ser difícil. El equipo percibe estas tareas imprevistas como obstáculos que le impiden alcanzar su compromiso para el sprint, provocando:
- Cambios de contexto
Hacen caer en picado la productividad, y precisamente Scrum trata de eliminarlos con las planificaciones y los sprints con objetivos cerrados. - Pobre dedicación a las tareas de soporte
Las incidencias, al ser percibidas como molestas interrupciones que te alejan de tu objetivo principal (acabar las historias del sprint backlog), se intentan cerrar de la forma más rápida posible, descuidando la calidad. - Pérdida de polivalencia de los miembros del equipo
En el intento de optimizar el tiempo a dedicar al soporte, se pierda la cross-funcionalidad. En mi experiencia, las personas que desarrollaron una historia, a la larga, quedan atadas a solucionar las incidencias que se deriven de ella, porque suponemos que serán más eficientes al conocer a fondo el asunto.
Cabe destacar otro problema común de estas tareas: su invisibilidad. Las tareas de soporte son invisibles salvo para quien las lleva a cabo. Estas tareas no se demuestran en la demo de fin de sprint. Se asume que lo normal es que todo vaya bien, de manera que si algo que va mal se arregla carece de importancia. Añade este aspecto a los problemas anteriores y obtienes aún más desmotivación.
Hay explicaciones muy diversas sobre qué hace subir y bajar la motivación de un equipo. Pero si en algo hay consenso es en que los objetivos confusos y cambiantes, así como las continuas interrupciones, la hacen bajar en picado. Que cualquiera en el equipo esté temiendo cuándo le va a llegar la siguiente interrupción le va a hacer sentir profundamente desmotivado. Y aún más cuando ese trabajo es aburrido e invisible para los demás.
Scrum y las tareas de soporte
Scrum es una metodología que, una vez has puesto en práctica, a menudo te proporciona más preguntas que respuestas. No en vano es uno de sus objetivos: hacer que los problemas afloren. Pero solucionarlos es trabajo del equipo. No hay un método universalmente aceptado de abordar este problema, de manera que en los últimos años no he parado de buscar y aplicar distintas formas de tratar este asunto. La primera aproximación, evidentemente, fue ignorar la existencia de estas tareas 😛 para encontrarnos al poco tiempo con los problemas que he explicado antes.
Tratar el soporte restando capacidad
Tras asumir que estas tareas existen, y ante la falta de experiencia y la resistencia a dividir el equipo, lo que hicimos fue restar de la capacidad del sprint las horas que estimábamos que iban a ser necesarias para las tareas de soporte.
La parte positiva de hacer esto es que por primera vez todos teníamos claro que las horas de soporte eran algo real, que nos ocupaba tiempo. Puede parecer una chorrada, pero hasta entonces no estaba tan claro que eso fuera un problema que debía abordarse de forma seria. De esta forma acabamos con el problema de la invisibilidad de estas tareas.
La parte negativa es que no se solucionaba ninguno de los otros problemas: cambios de contexto, prioridades cambiantes según el bug del día, etc.
Historias de soporte
Una variación que también probamos fue crear una historia de soporte, estimada en X puntos de historia por el equipo. La parte buena de esta aproximación es que damos solución a varios de los problemas que vimos antes:
- Fuera cambios de contexto. Sólo quienes están con la historia de soporte tienen que correr a apagar los incendios y peticiones imprevistas. El resto del equipo puede estar concentrado en el objetivo del sprint, sin interrupciones.
- Dedicación exclusiva a estas tareas. Las personas de soporte no han de cerrar en falso las incidencias para seguir con lo suyo. Mientras esté en soporte, eso es lo que ha de hacer, no hay otras historias.
- Ganamos en cross-funcionalidad. Sea cual sea la incidencia, la han de solucionar los encargados de la historia de soporte.
Respecto a la motivación, las tareas de soporte siguen sin ser las más agradables, pero al menos ahora sabes que ese es tu objetivo y te puedes concentrar en él. No estás dejando algo más importante para atender imprevistos. Hay un objetivo claro y te ciñes a él.
La parte mala es que hacer esto es hacer trampa. La historia de soporte no es una historia. No es más que un contenedor que permite asignar a X personas a hacer algo durante todo el sprint. La historia de soporte no es una historia porque el soporte, por definición, nunca está finalizado. Nada de cálculos de velocidad de sprints. Muy mal. La verdad es que no estuvimos mucho tiempo haciendo esto.
Otro equipo
Pues sí, otro equipo. Tuvimos que asumirlo. La solución anterior era buena desde muchos puntos de vista, salvo porque el backlog del sprint era una farsa. Tal como estábamos, lo mejor era dividir los equipos: quedarnos con un equipo que desarrollara las historias normalmente, intentando ser lo más fieles posibles a Scrum, y otro dedicado al soporte.
- El equipo de desarrollo trabajaría con Scrum, sprints, demos final de sprint, etc.
- El equipo de soporte, no. Trabajaría con una lista de tareas continuamente repriorizada. Hay quien llama a esto Kanban.
La regla principal es que al final de cada sprint rotaríamos los miembros de ambos equipos, de manera que:
- No hundimos a nadie en las tareas de soporte sine die, con la caída de moral que eso conllevaría.
- Hay un trasvase de conocimiento continuo entre ambos equipos, ya que el aprendizaje en un equipo es muy valioso para el desempeño en el otro.
La solución ¿definitiva?
Por ahora esta es la solución que mejor nos está funcionando. Nos permite que el equipo esté siempre razonablemente motivado y concentrado en su objetivo, dar un soporte adecuado a la vez que visible y medir la velocidad de Scrum sin interferencias. He visto que no estamos solos, puesto que parece que hay más gente por ahí que ha llegado a una solución similar. No sé si esta es la solución definitiva. Es la que mejor nos va a día de hoy pero posiblemente cambie en el futuro, a medida que el proyecto y nosotros mismos evolucionemos.
En mi opinión, seguramente Scrum no ofrece una solución estándar a este problema porque no la hay. Depende de factores como el tipo de proyecto o su fase de madurez, del tamaño, habilidades y motivaciones del equipo o incluso de la cultura corporativa el encontrar una solución satisfactoria. Y, de forma iterativa, intentar mejorarla cuando no nos funcione tan bien como desearíamos.
Hasta la próxima, feliz soporte! 😉
[Updated 02/12/2010] Tienes que descargar y leer Scrum vs Kanban: gratuito, en PDF y traducido al castellano gracias a la gente de Agile Spain. ¡Sencillamente imprescindible!
reThink.net 