Una Solució pre-Scrumban

Fa uns mesos, llegint les aportacions de la comunitat espanyola que treballa amb pràctiques àgils, vaig topar per primera vegada amb el terme "Scrumban". A partir d'allà em vaig llegir el fantàstic paper de Kanban vs SCRUM, i em vaig alegrar en saber que compartia problemes amb ells i podia llegir sobre les seves solucions.

En aquest post, em centraré en un problema amb què m'he trobat en el passat i en una solució que vaig adoptar, i en següents posts estudiaré com es relacionen amb les tendències Scrumban que els meus companys d'agilisme estan explorant.

En projectes en què he implantat SCRUM, hi havia una sèrie de problemes recurrents. Un d'aquests problemes era què fer quan l'equip de desenvolupament també realitza tasques de suport. Moltes vegades, l'equip de desenvolupament no només ha de desenvolupar noves funcionalitats, sinó també arreglar bugs i realitzar suport pur i dur. En companyies grans, els equips solen estar diferenciats, però quan es tracta d'empreses petites, els desenvolupadors han de contestar el telèfon i "apagar focs".

El problema amb SCRUM és que no permet incloure tasques noves quan un Sprint ha començat. Això no és una restricció capritxosa, ja que té un bon fonament: cal delimitarel nivell de canvi dins d'un equip per poder lliurar el paquet de programari promès a final de l'Sprint. Si estem canviant contínuament l'abast d'un Sprint, els conceptes de velocitati compromís per part de l'equip a lliurar l'acordat per a aquest Sprint, es perden. No ens anirem a comprometre a lliurar una cosa que no sabem què és!

Però si l'equip de programari també ha d'oferir suport ... Com podem dir-li al client (usuari, manager ...) que ha d'esperar que el Sprint s'acabi per solucionar el problema? Encara que el problema sigui urgent, haurà d'esperar que el Sprint acabi, es prioritzi la solució a la pila de producte (pel Product Owner) i finalment, es lliuri al final de l'Sprint següent (suposo que, com el problema era urgent, el Product Owner ho prioritza). En el millor cas, si el problema passa l'últim dia d'un Sprint, el temps de resposta seria la durada del següent. I en el pitjor, si succeeix el primer dia del Sprint, dues vegades aquesta durada. I fins i tot podríem calcular un temps mitjà de resposta, fent estadístiques de quan succeeixen els problemes durant un Sprint a la nostra companyia, calculant la seva distribució temporal i obtenir un temps mitjà de finalització del Sprint en curs (al qual sumaríem després la durada del següent). Sigui com sigui, això no funciona si el problema és realment urgent i s'ha de solucionar.

En un passat, jo vaig utilitzar un mètode "híbrid": baixàvem la velocitat d'equip de forma artificial per deixar un buffer per "suport". Cal recordar que en SCRUM, els equips són multifuncionals i per tant tots els membres de l'equip podien realitzar suport. Definíem un seguit de tasques del Product backlog com "opcionals", utilitzant una versió reduïda del Moscow Method:

• Tasques M "Must": conformaven l'Sprint, el compromís de l'equip.
• Tasques S "Should": aquestes tasques es realitzarien si no hi havia tasques de suport. En cas que sorgissin dites tasques, les tasques "Should" podrien descartar-se. No formaven, a priori, part del compromís de l'equip amb el client.

Aquest mètode no és perfecte, ja que també limita la capacitat de suport de l'equip, però aquesta capacitat màxima de suport era una cosa que s'acordava amb els clients /usuaris. Per exemple, "l'equip dedicarà un màxim de 20% a suport". Llavors "Tasques Must" = Compromís = Velocitat - 20%. Si no es realitzaven tasques de suport, l'equip havia de realitzar les tasques "Must" i "Should". Les solucions de bugs es posaven en producció quan el Sprint finalitzava, de manera que el temps de resposta es reduïa.