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.

Hay empresas que tienen parte de sus equipos dedicados al desarrollo de nuevo software y otros dedicados al mantenimiento del que ya está en producción. Para ellos es relativamente simple manejar las incidencias que se producen por el uso del software, ya sea por un defecto del software o por un uso inadecuado del mismo.

En aquellas en que los mismos equipos desarrollan y mantienen el software, cuando se convierten en Equipos Scrum, con un Product Backlog priorizado y orientado a la entrega de valor, se verán enfrentados en muy poco tiempo a la pregunta: ¿Cómo gestionamos las incidencias? ¿Van al Product Backlog? ¿Se planifican? ¿Se atienden? Hoy quiero daros un poco de luz con nuestra experiencia en clientes.

Impacto de las Incidencias

Las incidencias del software pueden suponer una interrupción que va directa contra nuestro plan del sprint.

Te has trabajado el Sprint Planning, tienes un objetivo claro, estás preparado para acometer el Sprint con garantías; y llega la primera incidencia, que obliga a revisar los acuerdos del Sprint. Y luego otra, y otra, y otra… Cada una de las cuales va menguando tu capacidad para cumplir los compromisos adquiridos al inicio del Sprint.

Puede ocurrir incluso que sea tal el volumen que te quiten todo el espacio para generar producto, y como Equipo Scrum estéis secuestrados por el día a día. No te voy a negar que si has llegado hasta ese punto, algún problema de calidad de software tienes. Tu problema no son las incidencias, es cómo estás construyendo el software, y que no estás prestando atención a la calidad del mismo.

Además las que no atiendas en el momento y dejes para más adelante, te van a impactar en los sprints futuros, restándote capacidad para generar producto que aporte valor. Van a afectar a tu Product Backlog, las incluyas o no en él. No te voy a recordar otra vez la importancia de un software de calidad, que evite una situación dolorosa (y vergonzosa).

Supongamos que tienes un número de incidencias dentro de lo normal. ¿Qué puedes hacer para minimizar el impacto en el plan del Sprint?

Atender lo importante

Si cuando vas a priorizar el Product Backlog lo haces atendiendo a lo más relevante (a lo que más valor aporta o a lo que es más necesario en cada momento para el cliente y la empresa), ¿por qué aceptas todas las incidencias según llegan? ¿De verdad hay que atender todas en el momento que se producen? La respuesta es un claro y rotundo ¡NO!. Repítelo conmigo: ¡NO!

Un sistema súper sencillo que nos está funcionando muy bien en nuestros clientes es realizar un primera catalogación rápida de las incidencias en tres niveles:

Críticas

Alguien del equipo para inmediatamente lo que esté haciendo y se pone a solucionarla.

Urgentes

El primero que acabe con lo que esté haciendo, se pone a solucionarla.

Resto de Incidencias

Van al Product Backlog y se priorizan junto con el resto de PBIs.

De esta forma, lo que estamos haciendo es decidir si la incidencia es lo suficientemente importante para la empresa en ese momento como para que dejemos todo lo demás y la resolvamos.

Una incidencia crítica significa que no hay nada más importante para la empresa en este momento que solucionarla. Así que paramos, la resolvemos y ajustamos los acuerdos del sprint.

Una incidencia urgente significa que es lo siguiente más importante para la empresa, y por lo tanto tengo que atenderla en cuanto me sea posible, dejando lo que tenía a continuación para después. En ese momento se resuelve y ajustamos los acuerdos del sprint.

El resto de incidencias no son tan importantes ahora como para poner en riesgo mis compromisos, así que las incorporo al Product Backlog y las priorizo junto con el resto de PBI.

Catalogar las incidencias

Para realizar esa catalogación inicial y rápida, es bueno que te bases en el proceso de negocio al que está afectando. Por ejemplo, en uno de nuestro clientes se ha utilizado este árbol de decisión tan sencillo:

Esto les está permitiendo de una manera rápida decidir qué tienen que atender inmediatamente y qué puede esperar.

Evidentemente esta primera clasificación es revisada y reajustada a una categorización más fina, cuando el equipo atiende  la incidencia y tiene más detalle del impacto. Es cierto que perderemos algo de tiempo en las que marquemos como críticas y urgentes y luego no lo sean, pero desde luego mucho menos que si atendemos todas sin control alguno.

Resumen

La convivencia de producto e incidencias en el Product Backlog es un dolor de cabeza para muchos equipos, y es difícil de gestionar. No hay una fórmula mágica que funcione para todos los equipo o tipologías de producto. Os hemos dejado aquí la que mejores resultados nos está dando en nuestros clientes.

Más adelante hablaremos en nuestro blog sobre si es conveniente o no tener equipos separados para el mantenimiento del software y la resolución de incidencias. ¡Atent@ a nuestras publicaciones!

Introduce tus primeros cambios

Ojalá esta solución te sirva para mejorar la gestión de las incidencias. Es un proceso simple, pero que en tu día a día puede resultar complicado implementar. Te pregunto:

¿Qué cosas encajan con tu equipo y cuáles no?

¿Qué te gustaría poner en marcha de lo que te hemos contado? Y de cada cosa, apunta:

Qué pasa si no lo intentas.

Qué pasa si lo intentas y lo consigues.

Qué pasa si lo intentas pero no lo consigues.

Quiénes son tus aliados claves para introducir ese cambio y cómo los vas a implicar.

 

Con esta información, prioriza y elige qué vas a hacer primero. ¡Ánimo!

También te puede interesar.

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.

Lo que te estás perdiendo por hacer «tu» Scrum

¿Qué ocurre si decides utilizar sólo parte de Scrum? Dejar de usar roles, eventos o artefactos tiene sus riesgos.

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.

Informar a la dirección con el Burn Up

El uso de Agile junto con Scrum u otros métodos, no elimina la necesidad de visualizar la que está ocurriendo a las capas superiores, a los clientes internos, e incluso a la dirección. El Burn Up es una herramienta sencilla que nos ayudará en esta tarea.

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.

Beneficios de la automatización en los equipo Scrum

La automatización, cada vez más, forma parte del desarrollo del software. ¿Qué beneficios tiene para los equipos Scrum?

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.

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.

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.

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada.

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

ACEPTAR
Aviso de cookies