Flexibilizando el flujo Scrum con Kanban (parte 1)

Muchos equipos de desarrollo de software al implementar Scrum observan un cambio positivo en su trabajo: se aclaran y ordenan roles, aumenta la colaboración y el trabajo comienza a mostrar avance periódico. Scrum establece una relación del equipo de desarrollo con un único Product Owner, con el que se negocia al comienzo del Sprint la cantidad y prioridad de las Historias de Usuario que serán implementadas.

Durante la duración del Sprint, el objetivo de negocio acordado queda efectivamente congelado como una forma de ayudar al equipo a enfocarse, permitiéndose sólo ajustes que mantengan el objetivo acordado.  

El ámbito de autonomía del equipo Scrum

Un equipo ágil de desarrollo de software que sigue el marco de trabajo Scrum idealmente debe tener un desafío acotado de desarrollo de funcionalidades dentro del propósito global del sistema informático que se está desarrollando. Por ejemplo, un equipo ágil puede estar a cargo de la funcionalidad de búsqueda de música dentro de un sistema de streaming de música como podría ser Spotify, o del servicio de autenticación de usuarios dentro de una aplicación bancaria.

Para realmente ser ágil, debe poder tomar decisiones de forma autónoma dentro del foco que le fue asignado sin tener que requerir aprobaciones políticas o esperar por que alguna experticia técnica esté disponible. Por eso los equipos ágiles suelen estar conformados por expertos con múltiples experticias que efectivamente les permita ser autónomos en lo técnico.

Esta característica, los coloca como expertos técnicos en el dominio determinado por el foco sobre el que el equipo está a cargo.

Cuando no todo sale como está escrito en los libros

A veces, al intentar seguir el marco de trabajo Scrum nos podemos encontrar con realidades donde necesitamos herramientas adicionales.

Por ejemplo, supongamos que creamos equipos Scrum para agilizar el desarrollo de un sistema informático con cierto tiempo de antigüedad. En ellos, es muy común que se haya acumulado defectos que se expresan en fallas que afectan a la continuidad operacional, obliga al equipo a cambiar drásticamente desde el foco del Sprint a atender la emergencia y recuperar la continuidad operacional del sistema informático. Pero esto no es suficiente. Si no descubrimos las causas y las resolvemos, el problema volverá a aparecer y cada vez tendremos más tiempo perdido por lo que en Lean se denomina “Demanda por falla”, es decir, tiempo que perdemos para la creación de nuevo valor porque estamos atrapados por defectos en las funcionalidades ya entregadas. De hecho, no es raro encontrar en nuestra industria áreas de tecnología con un 60% o 70% de su tiempo dedicado a apagar incendios en vez de avanzar en nuevas funcionalidades. Así que debemos asignar tiempo a pagar esta deuda técnica.

Otras necesidades válidas para atender focos más allá del objetivo del Sprint son: el surgimiento de nuevos negocios que necesitan consultoría técnica, que otros equipos puedan requerir apoyo, etc.

En la siguiente parte explicaremos cómo es posible flexibilizar para equilibrar el foco en el objetivo del Sprint y estos pedidos ad-hoc usando el método Kanban. Pueden acceder a ella a través de este enlace

¿Quieres aprender más?

Estos contenidos se profundizan en la formación oficial de la Kanban University que estamos entregando a través de nuestra Academia Agil en las siguientes fechas:

Créditos Iconos

Iconos obtenidos de the Noun Project:

• “target” por Loudoun Design Co.
• “Workflow” creado por ic2icon,
• “Too much work” by Gan Khoon Lay,
• “Error” by Adrien Coquet,
• “Error” by Fauzan Adiima_