Una de las cuestiones que, con mayor frecuencia, surge dentro de los equipos Scrum es cómo gestionar incidencias cuando se combinan con el trabajo de un Sprint. Hemos podido trabajar con muchas estrategias diferentes, aunque no todas son lo más ágiles posibles. Analizamos todas las posibilidades para gestionar incidencias.
¿Por qué tenemos incidencias?
Una incidencia / bug es un fallo en nuestro producto que, de alguna manera, produce un resultado negativo. Las incidencias han existido desde siempre e, incluso, se asume la manida frase “siempre va a haber incidencias” para justificar un trabajo mal hecho. Recordemos que un error es un fallo en el servicio que prestamos. Las incidencias en el mundo de los proyectos se han usado para vender un servicio de mantenimiento posterior, lo que hacía que se vieran como positivas para muchas consultoras, que vivían de dichos contratos.
Las incidencias en el mundo de los productos son importantes, porque un producto que falla es un producto que presta mal servicio y un mal servicio genera pérdidas en forma de clientes, de reputación o de dinero.
Tener incidencias es un indicio de que algo no hemos hecho bien. Aunque es normal que aparezcan si, tras una subida a producción muy pesada, tenemos una cantidad de incidencias elevada, es que no hemos gestionado correctamente nuestro producto. Generalmente, estas situaciones ocurren cuando aplicamos Scrum sin una cultura adecuada.
Muchos equipos esperan muchos Sprints para entregar el producto y, cuando lo hacen, descubren que tiene muchos fallos o, peor aún, no es el adecuado. Un Scrum Master profesional debe inspeccionar el origen de las incidencias, muchas veces provocadas por la cultura organizativa que habrá que ir cambiando.
Lo resolvemos con Kanban
Algunos equipos Scrum lo utilizan para “hacer el proyecto” y, una vez que entran en la “fase de mantenimiento”, cambian a método Kanban. Este planteamiento sigue siendo tradicional por varios motivos. Por un lado, cuando hablamos de Scrum “para hacer proyectos” es intentar correr para entregar, en una fecha, un alcance. En este planteamiento, no medimos el valor de nuestro producto, lo que hace que retrasemos el saber si estamos construyendo el producto adecuado.
Además, el método Kanban no es un “gestor de incidencias”, sino un método para organizar el trabajo y conseguir que fluya. Aunque nos interese que las incidencias fluyan, el hecho de usar Kanban, para corregir los defectos provocados por un mal Scrum, es una situación negativa para la entrega de valor y para el servicio que nuestro producto presta.
Otros equipos combinan ambos, usando Scrum para la gestión del trabajo nuevo y Kanban para incidencias. Usar un tablero Scrum con un carril de incidencias no es mezclar Kanban y Scrum, es solo “parchear” nuestro equipo. ¡Esto ya se hacía antes con los resultados que ya conocemos!
Estimar las incidencias detectadas
Hay equipos que deciden anotar todas las incidencias detectadas durante el Sprint en curso y esperar al siguiente para tratarlas. Las incidencias detectadas forman parte de la deuda técnica, trabajo pendiente que tiene un impacto negativo en nuestro producto.
Los equipos que siguen esta estrategia tienen una ventaja, pueden estimar las incidencias y compararlo con el resto del trabajo del Sprint. La parte negativa es obvia, esperamos mucho para resolver incidencias, lo que puede ser perjudicial para nuestro producto.
Este tipo de estrategia nos hace pensar que seguimos orientados al control y no a la generación de valor o a prestar un servicio de calidad.
Regla 80-20
Otra estrategia muy habitual es la de reservar un 20% del tiempo para resolver incidencias. Habitualmente, se reserva un porcentaje de los puntos de historia que hace de media un equipo. Por ejemplo, si un equipo hace 100 puntos por Sprint, tratan solo de “meter” 80 en el Sprint, reservando el resto para incidencias.
Este tipo de estrategias tiene varios riesgos. La velocidad es una consecuencia del equipo, no un deseo. Que hagamos 100 puntos de media no significa que hagamos siempre 100. Además, los puntos de historia son una medida muy subjetiva, por lo que genera errores. Otro problema claro es que, al tener un trabajo no planificable, es complicado saber si estamos en ese 20% o lo hemos superado.
No obstante, es normal bajar el ritmo de lo que solemos entregar si tenemos que abordar incidencias, en ese sentido esta estrategia es positiva.
Equipo dedicado
Hay organizaciones que prefieren separar el desarrollo del mantenimiento. Dentro de un mismo software, separan las personas que lo crean por primera vez de aquellas que lo mantienen en el tiempo. Incluso hay empresas que tienen sus propios departamentos de mantenimiento.
Este tipo de estrategias suelen ser negativas, porque evaden al equipo de desarrollo de la responsabilidad de hacer un buen producto. Además, por ahorrarnos costes, hacemos que se retrase la resolución de incidencias hasta que el equipo de mantenimiento se familiariza con el código. Una solución de este estilo sigue siendo tradicional y con foco claro en el ahorro de costes sobre la entrega de valor.
Además, si divides un equipo Scrum entre desarrollo y mantenimiento, se suele generar mucha tensión porque nadie quiere arreglar incidencias, lo que puede romper a un equipo.
Horas o días dedicados
Hay equipos que apuestan por reservar una franja de tiempo durante el día para incidencias. Colaboré con un equipo que tenía la regla de solucionar incidencias hasta que comenzara la Daily Scrum, que era cuando coordinaban las tareas del día.
Otros equipos deciden dedicar días a incidencias, repartidas entre los miembros del equipo. Si vas a apostar por esta técnica, es importante hablarlo en la Sprint Planning, para que no tengáis que decidirlo cada día.
Puntos de Historia e incidencias
Muchos equipos utilizan el velocity (número de puntos de historia por Sprint) como medida de trabajo para muchas gestiones: saber cuánto meter en un Sprint, estudiar la tendencia del equipo o, incluso, compararse entre equipos (esto es una mala práctica, pero ocurre). Al haber incidencias no planificables, a los equipos les cuesta unirlo a los puntos de historias del trabajo planificado.
Por ejemplo, si suelen hacerse 60 puntos de historia y, como consecuencia de atender incidencias, se baja a 40 puntos, existe el miedo a que piensen que se ha trabajado poco. Para solucionar esto, hay equipos que hacen una estimación a “posteriori”, es decir, una vez finalizada la incidencia le dan una estimación en puntos (que se suman al total completado del Sprint).
Si analizamos esta estrategia, vemos que hay más preocupación por el control y el reporting que por centrarnos en la entrega de valor. Mucho cuidado, porque acabamos invirtiendo mucho tiempo en justificar nuestro trabajo en vez de centrarnos en el impacto de nuestro negocio.
Política de trabajo de incidencias
La técnica que creo que mejor funciona para gestionar incidencias con Scrum es: decidirlo en equipo. Durante la Retrospectiva, deberíamos hablar de nuestra política de incidencias ¿Cuándo consideramos una incidencia crítica? ¿Quién la atiende? ¿Quién la revisa? ¿Por qué tenemos tantas? ¿Cuál es la tendencia?
Las incidencias reflejan la salud de nuestro producto y la retrospectiva puede ser un lugar para encontrar mejores formas de construirlo. También, podemos tratar esta gestión en la Sprint Planning, para estudiar el posible impacto con el Sprint Goal que queramos asumir ¿Podemos no cumplir con el Sprint Goal si resolvemos incidencias críticas?
Este debate debe tenerse dentro de un equipo. La autogestión consiste en asumir las incidencias como parte de la responsabilidad que tenemos al construir nuestro producto. Después, podemos usar muchas de las estrategias que hemos descrito, pero siempre que sea el propio equipo quien lo decida.
Incidencias y continuous delivery
El continuous delivery es una estrategia de entregas en la que tratamos de entregar lo antes posible, pequeños trozos del producto a nuestros usuarios. Para ello, debemos tener una cultura de entrega contínua, con la que tratemos de tener los medios necesarios para acelerar el proceso de entrega y reducir el time-to-market. Si tenemos incidencias, lo ideal es tener CD para acelerar la entrega y que la molestia que generen sea la menor posible.
No es obligatorio que exista un continuous delivery en Scrum, sin embargo, es clave si queremos mejorar la experiencia de nuestros usuarios.
Reporting de incidencias
Muchos equipos están preocupados por la manera de reportar incidencias. Scrum se centra en la entrega de valor. No obstante, a veces necesitamos explicar el trabajo realizado por el equipo. Para ello, hay algunas acciones que podemos tomar.
- Intentemos reportar el número de incidencias y su tendencia como una métrica más. Si usamos el velocity, pues que aparezcaen la misma diapositiva. De esta manera, podemos analizar la relación entre ambas métricas.
- Podemos medir el número de items completados por Sprint (incidencias u de otro tipo). Es más, podemos hacer un diagrama de sectores separando la cantidad de cada tipo que hemos resuelto. No es una métrica ponderada, pero es lo suficientemente simple para que no nos centremos en un reporte excesivo.
- También podemos estimar las incidencias y unirlas con los puntos del resto de items para reportar, pero sin que sea excesivo.
- Medir el tiempo de resolución de incidencia desde que se reporta hasta que se completa. Con esto, podemos defender dar el salto a un continuous delivery.
Conclusiones
Las incidencias son un tipo de trabajo más que debemos resolver como Scrum Team. Como casi todo en Scrum, la respuesta está en las personas que componen el Scrum Team, ya que son ellos los que tienen que enfocarse en su producto y en la generación de valor.
Y tú, ¿cómo gestionas las incidencias? º
