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!

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