Hace unos años, me encontraba trabajando para una consultora de desarrollo de software. Un día, una de las personas que lideraba las ventas, dio una charla sobre la misma, y explicaba lo siguiente: “yo lo vendo y, ya, con management lo arreglamos”. Esta frase venía a decir que su foco era conseguir el contrato y que la ejecución sería de los equipos y que ellos lo arreglarían. .
Los acuerdos a nivel de servicio (ANS) o los service level agreement (SLA en inglés) son contratos de servicio que se suelen fijar entre equipos y clientes, para marcar tiempos de respuesta y describir cómo debe ser el servicio. Sin embargo, en Agile siempre hemos dicho que la colaboración con el cliente debe estar por encima de la negociación contractual, ¿cómo podemos fijar ANS/SLA con nuestros clientes?
Kanban tiene la respuesta
De todas las técnicas, métodos y marcos que se asocian con Agile, quizás, Kanban sea el que más se centra en métricas y su importancia. El método Kanban para muchos se relaciona más con Lean que con Agile, pero esto da para una conversación más profunda que dejaremos apartada por el momento.
En el método Kanban se asume que no existen estimaciones, pero que podemos predecir con datos estadísticos. “Si el 90% de los trabajos que realizamos son inferiores a 10 días, podemos gestionar expectativas”. Por tanto, podemos crear un acuerdo a nivel de servicio utilizando la estrategia de Kanban, es decir, medir y después comprometer.
Conoce tu capacidad de entrega antes de firmar un ANS
El gran problema de un acuerdo de nivel de servicio es el momento de firmarlo. Si tanto cliente como proveedor no se conocen, no hay confianza y, por tanto, es complicado firmar este tipo de acuerdos. Para empezar, si nunca hemos trabajado juntos, ¿cómo sabemos que los números comprometidos son los correctos?
En el método Kanban, buscamos conocer nuestra capacidad de entrega antes de usar el control estadístico para predecir el funcionamiento de un equipo. Es decir, hasta que no sepamos cuánto somos capaces de entregar y el tiempo que necesitamos para ello, no podemos ser predecibles. De hecho, en el método Kanban, se propone que, en momentos tempranos donde no tenemos datos suficientes podemos realizar estimaciones, siempre y cuando, las estimaciones se vayan sustituyendo por predicciones basadas en datos.
Por tanto, si necesitamos firmar un ANS, deberemos usar estimaciones y actualizar estos acuerdos cuando tengamos datos fiables sobre los que dar respuesta.
Cómo hacer un acuerdo ANS
Uno de los errores habituales cuando estimamos es basarnos en la media. La media de unos datos no suele ser una buena herramienta porque, según la desviación de dicha media, podemos cometer errores de bulto. Por ejemplo, si decimos: “en esta habitación hay personas con una media de edad de 30 años”, nos imaginamos personas de entre 28 y 32 jóvenes (pero no adolescentes). Ahora bien, podría haber una señora de 60 años con su nieto recién nacido ¡fallo en la predicción!
En el método Kanban, aprendemos a usar los percentiles más elevados. Si decimos: “el 80% de las tareas urgentes se hacen en menos de dos días”, estamos usando el percentil 80. Bien, con estos percentiles podemos fijar los acuerdos a nivel de servicio, donde damos un porcentaje de confianza asociado a un dato. Es importante que no busquemos la exactitud, con frases tipo: “todas las incidencias críticas deben estar hechas en 24 horas” ¿Todas? ¿No puede ocurrir que alguna sea tan grande que requiera de más tiempo?
Por eso, los acuerdos se deben revisar cada cierto tiempo. De hecho, en el método Kanban existe la Service Delivery Review, que es un evento de revisión del servicio que prestamos donde podemos analizar nuestro cumplimiento con los ANS que tengamos fijados.
¿Y Scrum?
En Scrum, quizás sea más complejo introducir este tipo de acuerdos. Desde luego, si existen, deberemos tener una conversación en el equipo sobre cómo nos vamos a organizar para poder cumplirlos. La Sprint Review debe ser clave para transparentar si estamos cumpliendo con estos acuerdos y nuestra Sprint Retrospective debe servir para buscar la manera de poder cumplirlos.
Es más, seguramente en equipos con este tipo de acuerdos, merezca la pena realizar Sprints cortos de 1 semana, así podremos reaccionar de manera más rápida.
El punto negativo que habrá que trabajar es que tanto el Product Goal como el Sprint Goal dejarán de tener sentido, sobre todo porque nos centraremos en los acuerdos y no en el valor generado. Salvo que dichos ANS recojan el valor esperado, en cuyo caso Scrum quizás tenga más sentido que el método Kanban.
Y tú, ¿realizas ANS con Agile?
