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

Burndown y Burnup para el Scrum Master

Como Scrum Master puedes obtener información muy valiosa analizando estos dos gráficos para entender lo que está ocurriendo en tu equipo.

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

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.

Mi estrategia de Onboarding como Scrum Master

Me incorporo a un equipo como Scrum Master, ¿¿por dónde empiezo??

Estoy seguro de que esta pregunta ha pasado por la cabeza de más de uno y de una cuando se ha enfrentado al reto de comenzar a trabajar en una nueva empresa o con un nuevo equipo. En este post quiero compartir una estrategia que yo he utilizado y me ha sido útil para abordar el proceso de onboarding.

Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

El Product Owner: el desconocido y olvidado

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

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

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.

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