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.

Scrum ayuda a la mejora de la calidad en los productos

Scrum es simple e incompleto, solo define las partes necesarias para implementar la teoría de Scrum, permitiendo a las personas que lo utilizan generar sus propias instrucciones para conseguir alcanzar sus metas y crear valor. Y ahí está la dificultad para aprender a usarlo y mejorar la calidad de nuestros productos.

La historia de scrum, su primera implementación

Actualmente Scrum es el marco de trabajo más utilizado para implementar modelos Agile. Hoy os contamos como era su primera versión.

¿Quién debe priorizar el Product Backlog en Scrum?

Agile y Scrum nacen principalmente del mundo del Software, aunque en los últimos años se han llevado a otros ámbitos de las empresas. Scrum plantea al Product Owner como una única persona. La realidad de la empresa nos empuja a implementar algún tipo de escalado de Scrum, en el que aparecen, de una forma y otra, Product Owners de Product Owners. ¿Significa esto que se está haciendo una mala implementación de Scrum? ¿O nos estamos adaptando a las necesidades tal y como indica Agile? ¿Tiene que de verdad ser una única persona? ¿O hay otras posibilidades manteniendo la cultura Agile?

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

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.

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

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.

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

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.

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.

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