¿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

Apoya a tu equipo entendiendo qué le ocurre

La transparencia es uno de los pilares de Scrum. Con ella conseguimos hacer visible lo que ocurre dentro del producto, equipo, personas, … para hacer inspección y adaptación. ¿Cómo podemos saber qué ocurre en el equipo para poder apoyarle?

Cómo facilito una retrospectiva si no soy Scrum Master

Una buena retrospectiva da la oportunidad al equipo de analizar su funcionamiento y establecer mejoras. Te dejamos consejos para facilitarla.

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.

Cómo convivir con las incidencias en un Equipo Scrum

En los Equipos Scrum que desarrollan nuevo software y mantienen el ya existente, es muy habitual tener que lidiar con incidencias provocadas por el software en producción. Su gestión es complicada ya que interrumpen directamente nuestro plan para el sprint, y al producto ya priorizado en el Product Backlog.

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

El Product Owner: el desconocido y olvidado

Desde hace tiempo tengo la sensación que se desconoce la función de un Product Owner.

Monta equipos Scrum de éxito

Cómo montar equipos Scrum de éxitoYa sabes lo que es un equipo Scrum. Es hora de dar un paso adelante y entender cómo montar un equipo Scrum de éxito. ¿Qué tipo de perfiles incorporas? ¿Cómo se balancean? ¿Cuándo les incorporas? Son preguntas que probablemente te...

Scrum para disipar incertidumbre

Scrum es un marco que te puede servir para hacer lo mismo de siempre a trocitos. Sin embargo, puedes utilizar Scrum de manera inteligente y sacarle toda su potencia. ¿Cómo? Orientándolo a generar certezas sobre tu producto o tu mercado.

Multiplica los resultados de tu Sprint Planning

Hoy es día de Sprint Planning. Miras hacia tu equipo y… sólo ves pacas de paja rodar de un lado a otro. ¿Qué ha pasado con tus compañeros? ¿Dónde se esconderán? ¡Te han dejado solo! Te traigo 5 consejos para multiplicar los resultados de tu Sprint Planning.

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?

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