¿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.

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.

También te puede interesar.

Las consecuencias de un Backlog interminable

Nuestro Product Backlog con el tiempo se va llenando y convirtiendo en un Backlog interminable. En este artículo te planteo las consecuencias más relevantes que tiene.

Aprendiendo en un Equipo Scrum

El conocimiento compartido potencia a tu equipo. Aquí descubrirás cómo identificar las áreas de conocimiento y favorecer su aprendizaje continuo

Como empezar como Scrum Master

Acompañar a equipos es una gran responsabilidad pero es muy gratificante. Cada persona y cada equipo tiene unas necesidades diferentes en función de su realidad. Sin embargo, bajo nuestra experiencia, estos consejos pueden servirte para iniciarte como Scrum Master en un equipo.

Plan para formar a Scrum Master propios de la empresa

En todo acompañamiento en la transformación a la agilidad con Scrum, llega un momento en que los Agile Coach y Scrum Master externos a la empresa deben dejar al Cliente que siga su camino. Y con garantías de que no se va a perder lo conseguido y se va a seguir fomentando la mejora continua y el customer centric.

El Product Owner y su relación con los Stakeholders

Como Product Owner enseguida te has dado cuenta de la gran importancia que tiene tu relación y la del Equipo Scrum con los Stakeholders.

Es importante usar Historias de Usuario

Usar Historias de Usuario es importante para los Product Owner, además de la más utilizada a la hora de escribir el Product Backlog.

Sprint Review: más allá de la demo

La Sprint Review es el evento de Scrum donde se muestra el resultado del sprint. Una buena review te ayudará en la estrategia de producto.

El uso de las Métricas para saber nuestro nivel de Incertidumbre

Scrum nos ayuda a manejar la incertidumbre. Pero ¿cómo sabemos que lo estamos consiguiendo? ¿Qué métricas pueden ayudarnos a confirmar que tenemos bajo control la incertidumbre?

Cómo mejorar tu Scrum Daily

En ocasiones nos encontramos con equipos en los que la Scrum Daily se ha convertido en un evento individualista donde cada miembro del equipo de desarrollo comenta las tareas realizadas durante el día anterior, muchas veces con cierto carácter de reporte. Sin embargo, la daily es un evento colectivo donde a través de la inspección y adaptación se traza un plan de trabajo del día para el equipo.

Definition of Ready y Definition of Done

¿Qué necesitas para poder comenzar una tarea? ¿Cuándo podemos dar una tarea por terminada? Para resolver estas dudas, en este vídeo te traemos el Definition of Ready y el Definition of Done

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies