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.

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.

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.

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.

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

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.

El Product Owner: el desconocido y olvidado

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

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?

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.

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