Cada vez que entra una unplanned en el Sprint muere un gatito

Los gatitos simbolizan el compromiso de los miembros del Development Team o Equipo de Desarrollo en nuestros equipos. ¿Qué pasa si, de manera reiterada, se añade trabajo para que el equipo de desarrollo acometa? Pues fácil, si para el mismo tiempo cada vez hay más cosas por hacer tenemos dos opciones: O hay cosas que no se hacen, o la calidad del trabajo empeora en aras de mejorar la velocidad. La calidad no es negociable así que ¡Salvemos a los gatitos! ¡Mantengamos la calidad de los desarrollos y productos!

¿Qué es para mi una unplanned?

Para mi una tarea unplanned es algo que surge y que está poco o nada relacionado con el objetivo del Sprint. Y digo que no está relacionado con el objetivo del Sprint porque si sí está relacionado es un vicio oculto, estaba ahí, pero no habíamos reparado en él… En ese caso sería como al amigo que se nos olvidó invitar a la fiesta y le avisamos en el último momento. Hay que tratarlo con cariñito.

¿Y cómo podemos actuar?

Para mi la respuesta es fácil, cuando una tarea unplanned no forma parte del objetivo del Sprint, si la afrontamos nos resta foco del objetivo. Por tanto… ¿Qué hacemos con aquello que va en contra de los valores de Scrum?

Esto nos plantea otras dudas ¿Y si no tenemos objetivo en el Sprint?

En este momento, el fanático de la Guía de Scrum que llevamos dentro quiere tomar la palabra y al estilo Gandalf responder “¡No es Scrum! ¡Y no podrá pasar!”. Pero hay que estudiar cada caso detenidamente. Es cierto que el compromiso es con el Objetivo del Sprint y el valor que entrega al usuario y no con la planificación (PBIs y Spring Backlog), por tanto, si el mejor objetivo de Sprint que tienes es un implícito “terminar todas las historias del Sprint y hacerlo de manera priorizada” no lo estamos haciendo del todo correcto. Teniendo esto en cuenta y calmando a nuestro mago Istar interior volvemos más calmadamente a la pregunta ¿Y si no hay Sprint Goal? Si no hay Sprint Goal en un Sprint, para mí, cualquier trabajo oculto que surja es un unplanned.

Relación unplanned y falta de compromiso

Colaboré con un equipo Scrum que trabajaban en modo “Scrum but” (yo hago Scrum, pero…). Uno de las carencias principales que detectamos fue que había un problema con el compromiso de entrega de valor al cliente.

Debido a temas de negocio, el producto no llegaría a producción hasta pasados varios Sprints.  Además, había que pasar por un conjunto de  procedimientos establecidos en la organización. (Sé lo que estáis pensando algunos, pero no nos desviemos y centrémonos en los gatitos… 😉 )

En ocasiones no usaban el Objetivo del Sprint, o si lo usaban era una yuxtaposición de objetivos cuya potencia estaba muy diluida, con lo que se perdía los beneficios del mismo. Muy orientado a entrega en fecha y a optimización de “recursos” porque sabían que hasta dentro de varios Sprints no se desplegaría a clientes.

Durante el Sprint, si se descubría que el análisis de alguna funcionalidad había sido incorrecto, se añadía como unplanned al Sprint después de un refinamiento exprés. Un día, en uno de estos refinamientos le pregunté al equipo de desarrollo si se sentía cómodo tomando el compromiso de esa nueva funcionalidad y con resignación me respondieron: “Bueno, si no da tiempo a todo se queda una o varias historias de las de abajo sin terminar y listo”.

Ahí me di cuenta que estaban tan acostumbrados a que surjan tareas unplanned que habían perdido (o nunca tuvieron) el compromiso con el Sprint. “Da igual lo que hagamos, trabajamos lo que salga y listo”.

Una vez leí una frase que decía “vemos un marco de trabajo y queremos cambiarlo sin tener en cuenta, que estos marcos los han creado gente, probablemente más lista que nosotros y si lo han puesto ahí es por algo”. Este es un claro ejemplo de eso. El no uso o uso inadecuado de uno de los elementos del marco de trabajo Scrum, el objetivo del Sprint, nos ha debilitado, al menos uno de los valores del equipo: el compromiso. Lo importante no es que haya un objetivo, sino entender para qué se usa el objetivo.

Conclusión

Es difícil comprometerse con algo que sabes que va a cambiar antes de que puedas terminarlo. Si el escenario cambia ¿Qué valor tiene el compromiso? Ninguno. Precisamente, para evitar esto tenemos limitaciones de tiempo o timeboxes. Si el entorno es tan convulso que tienes esa urgencia de cambiar cosas tan inmediatamente que te urge agregarlas al Sprint, quizá la duración de tu Sprint sea demasiado larga. Acórtalo, ajústalo a esas necesidades, podrás inspeccionar y adaptar más rápido en base a tu contexto. Aunque esté muy extendido el uso de Sprints de dos semanas, se pueden hacer más cortos. E incluso más largos, hasta un mes de duración. Esa flexibilidad está definida porque no hay dos productos iguales, con dos entornos iguales, para equipos y arquitecturas iguales; por tanto, no se puede y no se debe generalizar. Lo que funciona para otro, no tiene por qué funcionar para ti. ¿Os habéis sentado a hablar y reflexionar sobre la duración del Sprint que necesitáis?

Y si tu entorno es menos cambiante, o simplemente tus incrementos no acaban directamente en producción (en manos del cliente), practica la calma, espera al siguiente Sprint. ¿Tanta prisa tienes en satisfacer a tus stakeholders interesados? Si no sube a producción y no llega a manos del cliente, no hay retorno de la inversión.

Keep calm & ¡Salvemos a los gatitos!