¿Es conveniente tener un Equipo Scrum en exclusiva para Incidencias?

En tus Equipos Scrum os encontráis en una situación en la que la cantidad de incidencias que hay que atender os penalizan demasiado, o la deuda técnica acumulada aumenta en exceso la complejidad de cualquier evolución en software.
equipo scrum de incidencias

En tus Equipos Scrum os encontráis en una situación en la que la cantidad de incidencias que hay que atender os penalizan demasiado, o la deuda técnica acumulada aumenta en exceso la complejidad de cualquier evolución en software.

En nuestra entrada “Cómo gestionar las incidencias en un Equipo Scrum”, os contamos una propuesta para manejar las incidencias y evitar que se conviertan en un problema mayor. Puede que llegue tarde o sea insuficiente, porque la situación en la que te encuentras ya esté en un punto crítico. Cómo hayas llegado a este punto, es importante para no repetir los errores en el futuro, pero no relevante en este momento. Lo que necesitas es revertir la situación lo antes posible.

Una de las soluciones que suele surgir en estas situaciones es crear un Equipo Scrum que se encargue en exclusiva de las incidencias y/o de la deuda técnica. Siendo puristas, no es una solución muy Agile que digamos. Pero entendiendo la realidad de la empresa, y respetando algunos límites que no deben nunca sobrepasarse, puede ser una solución temporal en el corto plazo. Ten siempre en cuenta, que estaremos en una situación crítica y por eso abrimos la posibilidad a crear un Equipo Scrum exclusivo para incidencias y deuda técnica. Si no estás en esta situación, la solución no es buena, puesto que estará ocultando problemas más importantes de tus Equipos Scrum.

Vamos a ver algunas ventajas, desventajas y los límites de esta solución.

Ventajas

Como te decía en el post sobre la gestión de las incidencias, éstas son interrupciones directas para construir producto. Provocan interrupciones, generan incertidumbre y evitan que seas predecible. La ventaja de llevarlas a un Equipo Scrum en exclusiva, es que eliminará parte de esa incertidumbre e interrupciones del resto de equipos. Dejándoles más espacio para la generación de producto y haciendo que sean más predecibles.

Cuando el problema es abordar la deuda técnica adquirida, es un indicador de que estamos priorizando la entrega de producto frente a mejorar la calidad del software. La ventaja de llevarla a un Equipo Scrum en exclusiva, es que podremos tener un plan a corto-medio plazo, que se ocupe de reducir la deuda técnica a un nivel manejable por los Equipos Scrum.

Otra ventaja es que este equipo puede dedicarse a solucionar de manera definitiva las incidencias recurrentes o históricas. No sólo desbloquear la situación cuando se produce, sino también arreglar el software para que dejen de producirse. Y paso a paso, reducir el número de incidencias a resolver, y de nuevo llevarlas a un nivel manejable por los Equipo Scrum.

Inconvenientes

El principal es tener un equipo que se dedica sólo a incidencias y deuda técnica, algo que en general termina frustrando y quemando a las personas de ese equipo.

Un efecto secundario que puede producirse, es que el resto de Equipos Scrum que construyen producto, descuiden la calidad del software al tener a un equipo “que ya arreglará las cosas cuando fallen”, o “pondrá el código en bonito”. Hay que vigilar muy de cerca este comportamiento, y cortarlo de raíz inmediatamente.

Desde un punto de vista de Scrum, es un equipo que en general no aporta valor al producto. No genera incrementos, está “arreglando” el ya existente para que haga lo que debe hacer, está solucionando, cuando ya estamos en una situación crítica, lo que no quisimos hacer en su momento para tener un software de calidad. Es decir, está aumentando el coste de nuestro producto sin aportar más beneficios.

Límites y consejos

El primero es que tiene que ser una situación temporal. Nunca debería ir más allá de 6 meses, sería indicativo de que hemos ignorado sistemáticamente todas las reglas de construcción de software. Hasta las más básicas. Lo ideal sería entre 2 y 4 meses. Si lo alargamos más en el tiempo, corremos el peligro de estandarizar y generar una sensación de falsa sensación de seguridad en nuestros equipos.

La segunda más importante, es que tenemos que mejorar (o crear) nuestras buenas prácticas de construcción del software. Serán de obligatorio cumplimiento, y estarán destinadas a que la calidad del nuevo software sea intachable. Sin esto, lo único que hacemos es poner un parche temporal, que nos volverá a explotar con el tiempo.

Crea un un Backlog de resolución de deuda técnica e incidencias recurrentes, limitado a una cantidad de deuda técnica e incidencias recurrentes determinada, priorizado, y con los beneficios bien claros y definidos: disminución de la complejidad del software, reducción de tiempo en futuros cambios, reducción de incidencias, etc..

Rotación de las personas que conforman el equipo. Muy importante para evitar el efecto “quemado”. Y además hará que todos los desarrolladores sufran la falta de compromiso con la calidad del software. La suya y la de sus compañeros. No hay nada mejor que enfrentar a alguien a las consecuencias de su propio software.

Afronta los cambios con una perspectiva iterativa e incremental. Es mejor pequeños arreglos o refactorizaciones de código, que grandes paquetes de software “arreglado”. Tendrás un menor impacto en el código que ya estén modificando el resto de equipos, y la probabilidad de generar nuevas incidencias será menor y estará más acotado dónde pueden ocurrir.

Resumen

No es la solución óptima ni deseada, ya que implica encontrarse en una situación crítica e inmanejable por los Equipos Scrum. Pero puede ser un plan de choque para el corto plazo, y devolver la situación a un punto en el que sea manejable por los Equipos Scrum. Momento en que desharemos el equipo, o lo convertiremos en un Equipo Scrum más.

Tabla de contenidos

Comparte:

Más artículos

Matriz RACI: ¿en qué nos puede ayudar?

La matriz RACI o Matriz de Asignación de Responsabilidades es una herramienta que nos permite identificar los roles y las responsabilidades de determinadas tareas en un proyecto de forma muy visual.

Sprint Reviews: ¿Cómo dominarlas?

La Sprint Review es un evento de Scrum de cierre de iteración. Supone un ejercicio de inspección, adaptación y transparencia sobre el producto que estamos construyendo.

Suscríbete y mantente al día de las novedades

¿Alguna duda?

¡Reserva 30 minutos con uno de nuestros expertos y soluciónala!